interbase(проблема ввода данных)

← →
kla$ (2008-05-19 14:16) [0]

Создал бд. В ней 1 таблица. В делфе на форму кидаю IBQuery1,IBDatabase1,IBTransaction1, DataSource1 и DBGrid1. Прописываю:
IBQuery1.Database:= IBDatabase1; IBQuery1.Transaction:= IBTransaction1; IBDatabase1.DataBaseName:=прописываю путь; IBDatabase1.DefaultTransaction:=IBTransaction1; IBTransaction1.DefaultDatabase:= IBDatabase1; DataSource1.Dataset:=IBQuery1; DBGrid1.DataSource:=DataSource1; Query1.active:=true;
Компилится норм, но почему то немогу вводить данные в DBGrid. Что я делаю неправильно. Буду рад любым советам, т.к. новичок в этом деле(.

← →
kla$ (2008-05-19 14:17) [1]

> Query1.active:=true;

IBQuery1*

← →
Сергей М. © (2008-05-19 14:22) [2]

> Что я делаю неправильно

Используешь селективный запрос.
А для выполнения модификации данных следует использовать UPDATE-запрос.

Для этого существует TIBDataSet, рассмотри его в лупу внимательно, особенно в части UpdateSQL

← →
kla$ (2008-05-19 14:39) [3]

а разве с помощью IBQuery нельзя вносить данные в базу?

← →
Сергей М. © (2008-05-19 14:44) [4]

Можно. Но геморроя будет поболее, чем в случае с TIBDataSet - потребуется создавать отдельный объект для обновления и подключать его через св-во UpdateObject.

← →
kla$1 (2008-05-19 15:42) [5]

не, вспомнил, не совсем это геморно. Все решается через параметры второго IBQuery2:
var s:string; c:integer; begin IBQuery2.Params.ParamByName("STUDNAME").Value:=Edit1.text; IBQuery2.Params.ParamByName("SEMESTR").Value:=strtoint(Edit2.text); IBQuery2.Params.ParamByName("DISCIPL").Value:=Edit3.text; IBQuery2.Params.ParamByName("OTCHET").Value:=Edit4.text; IBQuery2.Params.ParamByName("OCENKA").Value:=Edit5.text; try IBQuery2.ExecSQL; except ShowMessage("Ошибка при добавлении данных!"); IBTransaction1.RollbackRetaining; exit; end; IBTransaction1.CommitRetaining; IBQuery1.Close; IBQUEry1.Open; end;

← →
kla$1 (2008-05-19 15:44) [6]

терь буду думать как можно редактировать данные которые я ввел...

← →
kla$1 (2008-05-19 16:48) [7]

ппц, и так и сяк....пробовал DBEdit"ы, но не получается отредактировать данные с БД. Когда использую DBEdit, то при одинарном клике в DBGride по записи, эта запись отображается в DBEdit(но вводить данные в него нельзя). А как сделать, что бы можно было через DBEdit(или просто Edit) редактировать записи которые отображены в DBGrid"e?

← →
Sergey13 © (2008-05-20 08:15) [8]

> [7] kla$1 (19.05.08 16:48)
> ппц, и так и сяк

Только не так как надо, см [2] последнее предложение.

← →
MsGuns © (2008-05-20 12:20) [9]

Поддержка редактирования в гриде должна реализовываться достаточно аккуратно и со знанием особенностей сервера и "движка". Новичкам не рекомендую этот способ.

← →
kla$1 (2008-05-20 14:00) [10]

> Поддержка редактирования в гриде

не обязательно в Гриде, можно и в еdit"ах.

← →
YurikGL © (2008-05-20 15:11) [11]

Кидаем IBDataset (ессественно с транзацкцией, коннекшном и датасорсом)
В selectSQL указываем select * from table
Правый клик на датасет->databse editor->жимкаем на generate sql и все применяем

Далее заходим в refreshSQL и проверяем сформировавшийся запрос. Частенько нужно указывать звездочку в select-е.
Так же не помешает пройтись по insertSQL, DeleteSQL и ModifySQL и проверить запросы там. Как правило, все нормально.
Далее привязываем грид к датасорсу и все можно легко и непринужденно редактировать.

← →
MsGuns © (2008-05-20 15:27) [12]

>Далее привязываем грид к датасорсу и все можно легко и непринужденно редактировать.

На самом деле все вовсе не так легко и непринужденно ;)

← →
YurikGL © (2008-05-20 15:30) [13]

> На самом деле все вовсе не так легко и непринужденно ;)

Седня пол дня этим занимался... легко и непринужденно! А если использовать lookup-поля и ehGrid то там вообще в гриде выпадающие списки рисуются...

з.ы. ну ессественно не забываем про то, что датасет нужно открыть, на грид дважды кликнуть, жимкнуть на кнопку, которая автоматом добавит все колонки, лишние колонки (с идентификаторами) удалить, у нужных сменить заголовок...

← →
YurikGL © (2008-05-20 15:31) [14]

и еще generatorField прописать...

← →
MsGuns © (2008-05-20 15:36) [15]

>YurikGL © (20.05.08 15:30) [13]

Да, на клиенте все выглядит именно так - легко и непринужденно ;)

Но просто предложение - напишите такую простенькую прогу, редактирующю в гриде. Потом запустите ее на своем же компе в 2-3 экземплярах. Работайте с каждым поочередно и понаблюдайте - изменения, сделанные в одном приложении, далеко не сразу появятся во втором.

Другие грабли могут случиться с вашим generatorfield, если генератор определяется на сервере и используется, к примеру в триггере.

← →
Sergey13 © (2008-05-20 15:52) [16]

> [15] MsGuns © (20.05.08 15:36)

Можно подумать на подобные грабли нельзя наступить при НЕгридовом редактировании.

← →
YurikGL © (2008-05-20 15:54) [17]

> Но просто предложение - напишите такую простенькую прогу,
> редактирующю в гриде. Потом запустите ее на своем же компе
> в 2-3 экземплярах. Работайте с каждым поочередно и понаблюдайте
> - изменения, сделанные в одном приложении, далеко не сразу
> появятся во втором.

эээ.... извещение со стороны сервера об обновлении данных всех клиентов, это - совсем другая тема...

> Другие грабли могут случиться с вашим generatorfield, если
> генератор определяется на сервере и используется, к примеру
> в триггере.

А зачем его использовать в триггере? Если первичный ключ генерируешь через generatorfield то никаких триггеров не надо.

← →
MsGuns © (2008-05-20 15:55) [18]

Несколько сложнее, ибо в технологии "одной длинной транзакцией читаем, другой, короткой, пишем" управлении транзакциями достаточно прозрачно. Ошибиться несколько сложнее.

← →
MsGuns © (2008-05-20 16:01) [19]

>эээ.... извещение со стороны сервера об обновлении данных всех >клиентов, это - совсем другая тема...

Чевой-чевой ??? Я что-то говорил о каком-то извещении ?

>А зачем его использовать в триггере? Если первичный ключ генерируешь >через generatorfield то никаких триггеров не надо.

Видите ли, существует т.н. БИЗНЕС-ЛОГИКА сервера, которая по определению более приоритетна, чем клиентская. Тот программист, который положил в тригер на сервере определение ИД записи, очевидно, что-то имел в виду этим сказать, и не ума дела проблемного прогаммиста, решающего лишь одну из ПРИКЛАДНЫХ программ, подвергать это ревизии. И тем более чего-то там изобретать, тупо используя предоставленные средой возможности. Рекомендую почитать Вострикова с Ковязиным - они весьма доходчиво и убедительно пишут.

← →
YurikGL © (2008-05-20 16:02) [20]

> Несколько сложнее, ибо в технологии "одной длинной транзакцией
> читаем, другой, короткой, пишем" управлении транзакциями
> достаточно прозрачно. Ошибиться несколько сложнее.
>

Вот как ты думаешь... такие подходы новичку нужны? с несколькими транзакциями?

← →
YurikGL © (2008-05-20 16:05) [21]

> Чевой-чевой ??? Я что-то говорил о каком-то извещении ?

Ты говоришь, что обновления в других клиентах появятся не сразу... Вот я и говорю, что что бы появлялись - надо уведомлять.

>Видите ли, существует т.н. БИЗНЕС-ЛОГИКА сервера, которая по определению
>более приоритетна, чем клиентская.

>Тот программист, который положил в тригер на сервере определение ИД записи,
>очевидно, что-то имел в виду этим сказать,
Ну если речь идет о том, что бы модифицировать ПО написанное неизвестным программистом, то может и нужно в триггере прописывать.
Я же, когда пишу новое ПО, ничего не изобретаю, иду проверенным быстрым способом и другим советую.

← →
MsGuns © (2008-05-20 16:05) [22]

>Вот как ты думаешь... такие подходы новичку нужны? с несколькими >транзакциями?

ОБЯЗАТЕЛЬНО. Нельзя программиста, разрабатывающего клиент-серверные приложения, и близко подпускать к компьютеру, пока он не усвоит азы. А транзакции - это легкие, печень и сердце любого скл-сервера.

← →
MsGuns © (2008-05-20 16:12) [23]

>YurikGL © (20.05.08 16:05) [21]
>Ты говоришь, что обновления в других клиентах появятся не сразу...

Я этого не говорил. Я говорил то, что неверное управление изменениями на сервере могут привести к такому эффекту.

>Вот я и говорю, что что бы появлялись - надо уведомлять.

Повторяю, я этого не говорил ибо это чушь ! Сервер никого и ни в чем не должен УВЕДОМЛЯТЬ. Это надо усвоить как дважды два, иначе не соит уходить с парадоксов и дибэйзов.

>Ну если речь идет о том, что бы модифицировать ПО написанное >неизвестным программистом, то может и нужно в триггере прописывать.
>Я же, когда пишу новое ПО, ничего не изобретаю, иду проверенным >быстрым способом и другим советую.

У меня такое ощущение, что вы читаете мои посты задом наперед ибо ничего из них не воспринимаете верно.
Какой ЧУЖОЙ программист ? Вот есть некая БД. На сервере. И на ней крутится десяток, а то и полсотни разных ЗАДАЧ. Писанных, вполне возможно, одними и теми же программистами, а возможно разными. Но это НЕ ИМЕЕТ НИКАКОГО ЗНАЧЕНИЯ. Просто часть логики (например, удаление или изменение сложных "документных" объектов, сложные многоступенчатые расчеты или выборки, используемые многократно в разных приложениях, и т.д.) ВЫНЕСЕНЫ на сервер как часть БИЗНЕС-ЛОГИКИ. И клиентские приложения используют эту логику явно или неявно. Я все же настоятельно советую почитать "Мир интербэйз".

← →
YurikGL © (2008-05-20 21:00) [24]

> ОБЯЗАТЕЛЬНО. Нельзя программиста, разрабатывающего клиент-
> серверные приложения, и близко подпускать к компьютеру,
> пока он не усвоит азы. А транзакции - это легкие, печень
> и сердце любого скл-сервера.

Ужс... если я бы так подходил, я бы не написал бы ни одного приложения...

> Я этого не говорил. Я говорил то, что неверное управление
> изменениями на сервере могут привести к такому эффекту.
Ну и где здесь неверное управление изменениями?

> Вот есть некая БД. На сервере. И на ней крутится десяток,
> а то и полсотни разных ЗАДАЧ.
Есть задачи, есть базы... Причем здесь задачи?

> (например, удаление или изменение сложных "документных"
> объектов, сложные многоступенчатые расчеты или выборки,
> используемые многократно в разных приложениях, и т.д.) ВЫНЕСЕНЫ
> на сервер как часть БИЗНЕС-ЛОГИКИ.
И причем здесь генераторы, как источник значений для первичного ключа?

> Я все же настоятельно советую почитать "Мир интербэйз".
Читал в двух редакциях... Дальше что?

з.ы. давай конкретный пример, когда предложенный способ не подходит.

← →
MsGuns © (2008-05-20 21:27) [25]

>YurikGL © (20.05.08 21:00) [24]
>Ужс... если я бы так подходил, я бы не написал бы ни одного приложения...

Это говорит не в Вашу пользу. Я не знаю Ваших работ, но думается, они не отличаются ни скоростью, ни удобством, ни особой надежностью.

>Ну и где здесь неверное управление изменениями?

Неверное управление заключается, например, в отдаче "на откуп" IBX подтверждение изменений, выполняющихся типа автоматически (то есть, согласно insertSQL, DeleteSQL и ModifySQL, "походя", как Вы изволили выразиться, вставленным в ИБдатасет). Само по себе это "неверное" управление ничего плохого не представляет. До тех пор, пока Ваше приложение не станет критичным по "интерактивности"

>Есть задачи, есть базы... Причем здесь задачи?

Представьте, таки да ! Например, БД крупного предприятия. А на ней реализовано куча "задач"- подготовка производства, оперативное управление, управление качеством продукции, управление сбытом и т.д. Т.е. "База" - ОДНА, а "Задач" - куча.
"Есть в мире много, друг Горацио, что и не снилось нашим мудрецам" (c) ;)

>И причем здесь генераторы, как источник значений для первичного ключа?

Я Вам щас скажу страшную крамолу. Генератор вообще-то не есть источник значений ни для какого ключа. Он вообще не знает ни о каких ключах. А вот триггер, использующий генератор как механизм полученеия гарантированно уникального значения для ЭТОГО генератора, может использовать его именно как ИСТОЧНИК для определения ID добавляемой в таблицу записи.

>Читал в двух редакциях... Дальше что?

Не верится, ох, не верится.

>з.ы. давай конкретный пример, когда предложенный способ не подходит.

Вы все про редактирование в Гриде ? Я же Вам выше предложил сделать простой эксперимент. Если Вы реализуете его простым и привычным для Вас "батонокидательским" способом, то получите "слепых" клиентов. Если переделаете приложение таким образом, как это написано в вышеупомянутой книжице (только чур !, FIB не использовать), то клиенты буквально сразу "прозреют", т.е. будут видеть изменения, сделанные другими в нужный момент.

← →
YurikGL © (2008-05-20 21:38) [26]

> А вот триггер, использующий генератор как механизм полученеия
> гарантированно уникального значения для ЭТОГО генератора,
> может использовать его именно как ИСТОЧНИК для определения
> ID добавляемой в таблицу записи.

По вашему, триггер - единственный путь, для вставки значения генератора в первичный ключ?

> т.е. будут видеть изменения, сделанные другими в нужный
> момент.
А если, это не требуется? Если у меня сидит 10 операторов, которые тупо заносят данные в систему? И раз в месяц я делаю отчеты?

← →
MsGuns © (2008-05-20 21:50) [27]

>YurikGL © (20.05.08 21:38) [26]
>По вашему, триггер - единственный путь, для вставки значения генератора >в первичный ключ?

Нет, конечно ! Но один из самых надежных и часто используемых

>А если, это не требуется? Если у меня сидит 10 операторов, которые тупо >заносят данные в систему? И раз в месяц я делаю отчеты?

Вот-вот. ВАМ НЕ НУЖНО ! Но это не значит, что ЭТО не нужно другим. А учить все же пытаетесь. И в этом Ваше заблуждение.

← →
YurikGL © (2008-05-20 22:04) [28]

> Нет, конечно ! Но один из самых надежных и часто используемых
Неужели? Есть аналитические данные? Статистика? Главное, я так и не понял, чем плох generationfield, если человек все равно через грид работает? И зачем для работы с гридом нужно знать "особенности движка"?

> Вот-вот. ВАМ НЕ НУЖНО ! Но это не значит, что ЭТО не нужно
> другим. А учить все же пытаетесь. И в этом Ваше заблуждение.
Неужели вы думаете, что начинающий программист вот так сразу будет писать базу для большого предприятия? Может он всю жизнь будет писать небольшие базы? Может даже с одним клиентом... Зачем сразу тащить пушку, если, пока, воробей.

з.ы. указанный мною способ позволяет легко быстро и достаточно надежно создать приложение без знаний о триггерах. Единственный минус - запросы автоматически не всегда корректно формируются. Да и при относительно большом числе клиентов можно коллизии получить. А фактор "изменения сделанные на одном клиенте не сразу видны на другом", никак не зависит от того "через грид добавляются записи" или "не через грид".

← →
YurikGL © (2008-05-20 22:06) [29]

>MsGuns ©
Кстати, я даже особенно не понимаю, что вы пытаетесь доказать...
Что generatorfield лучше не использовать? Тогда нужны критерии использования или не_использования...
Что первичный ключ правильно заполнять через триггер? Весьма спорно....
Что редактировать в гриде - плохо? Опять же, когда плохо... в каких случаях...

← →
MsGuns © (2008-05-20 22:40) [30]

>YurikGL © (20.05.08 22:04) [28]
>Неужели? Есть аналитические данные? Статистика?

Вам нужны цифры ? Их нет у меня. Зато есть несколько чужих интербэйзных БД, где все добавления делаются через триггеры, которые, в свою очередь.. ну, Вы поняли.

>Главное, я так и не понял, чем плох generationfield, если человек все равно через грид работает?

Тем, что Вы получите на клиенте НЕВЕРНОЕ значение идентификатора. Точнее, он будет неверным, если Вы не предпримете ряд телодвижений.

>И зачем для работы с гридом нужно знать "особенности движка"?

Дело в том, что считывает и отправляет на сервер информацию вовсе не грид, и знание механизма КАК это делается позволит разработать ПРОФЕССИОНАЛЬНОЕ приложение.

>Неужели вы думаете, что начинающий программист вот так сразу будет >писать базу для большого предприятия? Может он всю жизнь будет писать >небольшие базы? Может даже с одним клиентом... Зачем сразу тащить >пушку, если, пока, воробей.

Видите ли, уважаемый, я искренне считаю, что учить надо сразу ПРАВИЛЬНО.

>з.ы. указанный мною способ позволяет легко быстро и достаточно надежно создать приложение без знаний о триггерах.

Совсем недостаточно надежно. Программист, разрабатывающий клиентское приложение и не имеющий понятия о сервере - все равно, что водитель, знающий правила ДТП, но не умеющий водить автомобиль. Он просто опасен.

>А фактор "изменения сделанные на одном клиенте не сразу видны на другом", никак не зависит от того "через грид добавляются записи" или "не через грид".

Он не может не зависеть, если Вы будете использовать IBX. И об этом пишет тот же Ковязин. И дело не в гриде (сколько можно повторять) а в технологии управления транзакциями по принципу "Как Бог (IBX) даст"

← →
MsGuns © (2008-05-20 22:50) [31]

>YurikGL © (20.05.08 22:06) [29]
>Кстати, я даже особенно не понимаю, что вы пытаетесь доказать...

Только то, что не стОит настаивать на Вашем способе, будучи не уверенным в том, что он правелен или хотя бы надежен.

>Что generatorfield лучше не использовать? Тогда нужны критерии >использования или не_использования...

Можно, конечно. В том случае, если при вставке в таблице ID не определяется сервером самостоятельно, поверьте - это вовсе не так маловажно - зачастую сервер кроме вставки этой самой записи может выполнить еще кучу всякой работы, о которой Ваша прога даже не подозревает (например, регистрация в логах).
И вообще вся ваша (точнее IBX-я) технология превосходно будет работать на локальном варианте. И только.. Если Предполагается критичное к интерактивности клиентское приложение, то транзакции надо "брать в свои руки" ;)

>Что первичный ключ правильно заполнять через триггер? Весьма спорно....

Ничего спорного нет. Для IB - обычная технология. Опять же отсылаю к Ковязину. Причем триггер вполне может взять ID из записи, а не самостоятельно щелкать генератором. Но это - в простейшем случае. Для создания НАДЕЖНОЙ технологии, повторяю, максимум "серверного" функционала лучше поручать ему же, т.е. серверу

>Что редактировать в гриде - плохо? Опять же, когда плохо... в каких случаях...

Повторяю в 66 раз - грид тут вообще не при чем. А при чем здесь неполный контроль за запуском и подтверждением транзакций. Именно это и приводит к очень трудноискомым ошибкам, которые к тому же носят весьма плавающий характер

← →
YurikGL © (2008-05-21 07:36) [32]

> Вам нужны цифры ? Их нет у меня.
Тогда не пиши..

> Тем, что Вы получите на клиенте НЕВЕРНОЕ значение идентификатора.
> Точнее, он будет неверным, если Вы не предпримете ряд телодвижений.
Странно... у меня нет никаких проблем.

> Дело в том, что считывает и отправляет на сервер информацию
> вовсе не грид, и знание механизма КАК это делается позволит
> разработать ПРОФЕССИОНАЛЬНОЕ приложение.
Ага... знания нужны что бы делать профессиональные приложения... зашибись.... а если работать не через грид, то знания движка не нужны наверное.

> Видите ли, уважаемый, я искренне считаю, что учить надо
> сразу ПРАВИЛЬНО.
Возвращаясь к вышесказанному... чем неправилен подход с generationfield? Тем что у кого-то он не работает? Ну что теперь... у меня замечательно работает... И не только у меня. Да и то, что учить нужно сразу правильно - тоже весьма спорно... вот в школе нас учили, что нельзя брать корни из отрицательных чисел, и что атом, это - шарик.

> Совсем недостаточно надежно. Программист, разрабатывающий
> клиентское приложение и не имеющий понятия о сервере - все
> равно, что водитель, знающий правила ДТП, но не умеющий
> водить автомобиль. Он просто опасен.
Еще раз спрашиваю, чем ненадежно? Тем, что "а вдруг на сервере есть триггер?"

> Только то, что не стОит настаивать на Вашем способе, будучи
> не уверенным в том, что он правелен или хотя бы надежен.
Он правилен, проверен и надежен.

> Ничего спорного нет. Для IB - обычная технология.
Один из возможных способов. Не более. И, кстати, не единственный способ "серверного" добавления значения первичного ключа.

> Именно это и приводит к очень трудноискомым ошибкам, которые
> к тому же носят весьма плавающий характер
Честное слово, как страшно жить...

з.ы. резюмируя. Если сомневаетесь в способе - можете сами проверить.

← →
MsGuns © (2008-05-21 08:19) [33]

Похоже, что Вы не воспринимаете то, что Вам говорят. Перекрывая убийственным аргументом "А у меня работает !".
Мне, слава Богу, не работать ни с Вами, ни с Вашими программами. Людей жалко..

Засим примите и проч.

← →
Sergey13 © (2008-05-21 09:07) [34]

> [18] MsGuns © (20.05.08 15:55)
> ибо в технологии "одной длинной транзакцией читаем, другой,
> короткой, пишем" управлении транзакциями достаточно прозрачно.

Что непрозрачного в работе с одной транзакцией и комитом после каждого изменения? Как тогда работают люди на серверах неподдерживающих множественные транзакции?

Тригер может разрешать использование данного генератора для генерации ключа этой самой таблицы и вне пределов этого тригера. Я например это всегда делал практически на автомате - проверку IF NEW.ID is NULL .

Посчитай трафик и затраты сервера на постоянное перечитывание данных по твоей схеме при например такой задаче:
Пришла накладная на 100 позиций и какому-то манагеру надо тупо вбить туда продажные цены.

Прочитали 100 записей
Цикл от 1 до 100 делаем
изменили одну, зафиксировали, перечитали 100 записей.
Конец цикла.

В результате мы прочитали (и вытянули на клиента) 100+100*100=10100 записей. При этом 9900 записей при этом были закачаны просто заодно с нужной (измененной на этом этапе).

При работе с одной транзакцией

Прочитали 100 записей
Цикл от 1 до 100 делаем
изменили одну, зафиксировали, перечитали 1 запись.
Конец цикла.

В результате мы прочитали (и вытянули на клиента) 100+100=200 записей.

Причем в первом варианте мы обновляли возможно достаточно сложный запрос со связями и т.п., во втором варианте перечитывали запись по первичному ключу.

← →
YurikGL © (2008-05-21 09:08) [35]

> Похоже, что Вы не воспринимаете то, что Вам говорят. Перекрывая
> убийственным аргументом "А у меня работает !".

Не поверите, воспринимаю :) я писал и относительно сложные системы и простые. А по вашему выходит - давайте везде учить оракл ставить... зачем этот интербейз? А ведь вдруг у нас будет большое предприятие с тысячами задач. И давайте сразу детей в школе "правильно" учить извлекать корни. В том числе из отрицательных чисел.

← →
Anatoly Podgoretsky © (2008-05-21 09:58) [36]

> Sergey13 (21.05.2008 09:07:34) [34]

Документ должен обрабатываться как одно целое, то есть единой транзакции, иначе вариант один приведет ко множественным проблемам, при том не известно заранее к каким и когда.

← →
Sergey13 © (2008-05-21 10:12) [37]

> [36] Anatoly Podgoretsky © (21.05.08 09:58)

Документ - понятие довольно размытое, работы с ним тоже бывают разные и зависят он скорее от фактической бизнес-логики конкретного документооборота. В моем примере про заполнение цен по позициям документа по логике могут заполняться не обязательно в одной транзакции, т.к. никакая целостность данных не нарушается.

← →
Anatoly Podgoretsky © (2008-05-21 10:22) [38]

> Sergey13 (21.05.2008 10:12:37) [37]

Ты взял накладную, а это единый документ, состоящий из двух частей.

А насчет нарушения целостности, это сложный вопрос, что считать нарушением в данном случае, если эта накладная будет где то использована во время данной операции и не дай бог при сбое, то налицо имеем нарушение целостности, не ссылочной, а более высокого порядка. То есть имеем и не первоначальное состояние и не конечное, а что то подвешеное в воздухе. И откатываться потом не куда, хорошо, если то кто вводит помнит, что должно получититься, а если это промежуточное, порушеное пройдет по другим документам? А это типичный случай. Конечно надо говорить об конкретной бизнес логики, но в общем случае мое замечание верное в большинстве случаев.

← →
Sergey13 © (2008-05-21 10:48) [39]

> [38] Anatoly Podgoretsky © (21.05.08 10:22)
> то налицо имеем нарушение целостности, не ссылочной, а более высокого порядка.

Какое? Пришла накладная, ее оприходовали по закупочным ценам (которые в ней зафиксированы и не подлежат изменению), теперь надо определиться по какой цене будем этот товар пускать дальше. А может для этого надо провести маркетинговое исследование по ценам у конкурентов или еще что-то в этом духе. С некоторыми документами люди работают неделями, а то и месяцами. Где тогда держать промежуточные данные? У документа может быть (для такого случая) статус - его смена говорит, что документ обработан окончательно или нет. Но никто при этом не запрещает видеть другим людям (хотя бы для справки) результаты уже проделанной кем то работы.
А при восстановлении точно восстановятся (в данном случае) закупочные цены, т.е. состояние документа на зафиксированный момент приемки накладной. С текущей работой - как повезет.

Повторюсь - это напрямую зависит от реально бизнес логики на предприятии.

← →
ANB (2008-05-21 10:56) [40]

> Документ должен обрабатываться как одно целое, то есть единой
> транзакции

Зачем ? Удобства для юзера еще меньше.

> Sergey13 © (21.05.08 10:12) [37]

Присоединяюсь.

> давайте везде учить оракл ставить... зачем этот интербейз?

Дадад. Абсолютно правильная позиция. И никаких проблем с транзакциями. :)

Кстати, про уведомление других юзеров об изменении данных.
ИМХО : штука полезная, НО :
1. Лучше строить работу юзеров так, чтобы им это было не нужно
2. Это не так уж просто делается
3. Это потенциальный источник дополнительных багов и лишняя нагрузка на сеть и сервер.

← →
ANB (2008-05-21 11:06) [41]

> Anatoly Podgoretsky © (21.05.08 10:22) [38]

У документа статус есть.
В накладной, например, может 500 строк. И если на 450 строке компутер юзера сдохнет или еще чего случится и документ пропадет, то я на месте юзера оторвал бы вам все, что мона оторвать.

Все, что мона записать на сервер, не нарушая ссылочной целостности, надо записывать сразу после ввода юзером.

ЗЫ. Вот она, порочная практика обертки ООП над реляционной моделью. :)

← →
Anatoly Podgoretsky © (2008-05-21 11:40) [42]

> Sergey13 (21.05.2008 10:48:39) [39]

Ты начал подгонять общую задачу под конкретную ситуацию.

← →
Anatoly Podgoretsky © (2008-05-21 11:41) [43]

> ANB (21.05.2008 11:06:41) [41]

Смотри как бы тебе что ни будь не оторвали.

← →
Sergey13 © (2008-05-21 12:01) [44]

> [42] Anatoly Podgoretsky © (21.05.08 11:40)

Во первых, подобных конкретных ситуаций здоровенная куча (по крайней мере в моей практике), так что это практически общая конкретная ситуация. 8-)

Во вторых, я и не настаиваю на единственности "моего" варианта. Каждой задаче - свое решение. Просто Ганз как всегда начал наезды на "гридовское редактирование", а я как всегда не стерпел. Это как споры с ИШ про естественные и суррогатные ключи. 8-)

← →
ANB (2008-05-21 12:01) [45]

> Смотри как бы тебе что ни будь не оторвали.

Ну, если я на своей работе чего нибудь накосячу, то убытки будут такими, что мне не тока все оторвут :)

← →
Anatoly Podgoretsky © (2008-05-21 13:35) [46]

> ANB (21.05.2008 12:01:45) [45]

Ну считай легко отделаешься, а у нас без головы сразу останешься, поскольку убытки тоже ой ой ой, не менее 1 мегабакса в сутки, а с современными ценами наверно уже три.
И работа как раз подобная, набивают накладные, в гриде, но в транзакции и потом распечатывают толстую пачку сопроводительных документов.
Если по задаче, не соответствие реальных данных фактическим (например отвалился сервер) не приводит к страшным последствиям, то можно по одной транзакции на строку, но это как то страшновато и не по людски, тразакции для того и придумали, чтобы данные были консистентными.

← →
Sergey13 © (2008-05-21 14:15) [47]

> [46] Anatoly Podgoretsky © (21.05.08 13:35)
> но это как то страшновато и не по людски

Почему же? Все люди разные. 8-)
Стакан консистентен и полный и пустой и наполненный на 33% и пустой на четверть. 8-)

← →
ANB (2008-05-21 14:38) [48]

> то можно по одной транзакции на строку, но это как то страшновато
> и не по людски, тразакции для того и придумали, чтобы данные
> были консистентными

ИМХА :
Если документ импортится из электронного вида, то ясный пень - транзакция на весь документ. В случае сбоя мона повторить.
Пример - письмо со вложениями. Его нет смысла сохранять вообще, если не записалось в базу хотя бы одно из вложений.

А вот если документ вносится оператором ручками, то писать лучше так, чтобы было удобно оператору. Обычно ему удобнее транзакцию на строку, а документ лучше держать на статусе, который не мешает другим документам.
Пример - большая накладная. Кстати, для расходных накладных частенько еще производится резервирование под нее. Мона, конечно, тупо блокировать всю строку остатков, но, опять таки имха - это нехорошая идея с точки зрения производительности.

ЗЫ. Похоже, у нас схожая ситуация по части отрывания :)

← →
Anatoly Podgoretsky © (2008-05-21 14:46) [49]

> ANB (21.05.2008 14:38:48) [48]

Видимо деньги теже.
Кстати когда я выбивал деньги на сервера, то именно этот аргумент и подействовал, просто сказал директору представь, что с тобой сделают акционеры, если сервер не будет работать несколько дней. А у меня они как раз начали разваливаться от старости.

← →
Anatoly Podgoretsky © (2008-05-21 14:48) [50]

> Anatoly Podgoretsky (21.05.2008 14:46:49) [49]

Ему понравилась идея, что то мне оторвать, но очень не понравилась, что ему больше оторвут, а сумма там смешная была всего то около 100 килобаксов, два часа работы завода.

← →
ANB (2008-05-21 15:23) [51]

> а сумма там смешная была всего то около 100 килобаксов,

Не, эт наш тестовый сервак стока стоит. Боевой, подороже, скорее всего.

Но масштаб денег сходен. :)

← →
Anatoly Podgoretsky © (2008-05-21 15:31) [52]

> ANB (21.05.2008 15:23:51) [51]

Так разница, что вы покупаете нормальные сервера, а у нас Entry Level - но знал бы ты, что ранее там стояло, а сейчас пять стоек. Да что говорить, если экономят на рабсиле, всего один специалист на все компьютерное и это Я. Зато это позволило избавиться от несвойственных системному администратору функций, а то предыдущий и бумагу менял и картриджи с тонеров, все что угодно, только не администрировал. Бумагу конечно легче менять, чем строить качественную инфраструктуру.
Тяжело было выбить первые четыре сервера, зато следующие три, через 1.5 месяца выбил за 30 секунд, а дальше опять абзац, хотя бы не помешали еще четыре.

Зато сейчас ни компьютеры, ни принтеры не ремонтируются. Ремонт принтера (замена ленты переноса стоит столько же сколько новый принтер, а лично я менять все равно не буду), вот и покупают новое, но не всегда то, что оптимально.

Эх, менталитет.

← →
Sergey13 © (2008-05-21 15:33) [53]

> [52] Anatoly Podgoretsky © (21.05.08 15:31)
> всего один специалист на все компьютерное и это Я.

Безобразие! Срочно надо заменить на 10 студентов ! 8-)))))))))))

← →
Anatoly Podgoretsky © (2008-05-21 15:46) [54]

> Sergey13 (21.05.2008 15:33:53) [53]

Никогда не пойдут на это, и по менталитету и по ожидаемому результату, не дураки все таки.

← →
MsGuns © (2008-05-21 17:07) [55]

>Sergey13 © (21.05.08 12:01) [44]
>Просто Ганз как всегда начал наезды на "гридовское редактирование", а я как >всегда не стерпел.

Глупости. Ганз никогда не был противником редактирования в гриде ибо как не экстравертен, но не полный идиот (по крайней мере, мне так кааээться) ;)

Но я ярый противник тупого батонокидательства и юзания компонент, понятия о принципах работы которых нет и в помине. При этом, как правило, находится море разливанное советчиков и "помощничков" с одним, но смертельным аргументом "У меня все работает"

← →
MsGuns © (2008-05-21 17:11) [56]

И еще просто советик - по поводу контекстности и целостности вы оба к Анатолию прислушайтесь, - он глупостев обычно не говорит, и почти никогда не НАСТАИВАЕТ, вот если настаивает, то уж можно просто довериться. Опыт у него чувствуется.

ЗЫ. Это я типа подхалимничаю - на штаны, конечно, маловато, дак хоть на ширинку мабудь хватит ;))

← →
ANB (2008-05-21 17:56) [57]

> И еще просто советик - по поводу контекстности и целостности
> вы оба к Анатолию прислушайтесь

В этой части - ни хрена не буду прислушиваться. Т.к. имел уже раз глупость добавлять целиком документ одной транзакцией (строки забивал в буфер на клиенте). Оборвать все мне юзеры не успели - быстро все переделал после первой же жалобы.

Целостность документа - зависит от типа документа. Соответственно и решение.

Кистате, за написание триггера с подстановкой ID из генератора без учета, что ID может приехать извне надо тоже отрывать нафиг руки.

Вот FB/IB returning поддерживают ?

← →
Reindeer Moss Eater © (2008-05-21 18:07) [58]

Документ должен обрабатываться как одно целое, то есть единой транзакции, иначе вариант один приведет ко множественным проблемам, при том не известно заранее к каким и когда.

Это просто не юношеский максимализм.
Документ может вводится днями и валидный статус получать в четверг, в то время как начали его сочинять (вводить) в пятницу вечером.

Просто не надо думать, что все что закоммичено само по себе валидно.
Разработчику так канешна удобно. Потому что он как правило со своими поделками не имеет дела.

← →
Anatoly Podgoretsky © (2008-05-21 18:32) [59]

> MsGuns (21.05.2008 17:11:56) [56]

Шиш тебе, а не цветные штаны.

> ANB (21.05.2008 17:56:57) [57]

Ну мы опять призодим от общего к частному.
В форумах, если не оговорены особые условия, обсуждаются общие случае, а частные случае всегда имеют быть место.
Я не против частных случаев.

> Reindeer Moss Eater (21.05.2008 18:07:58) [58]

Ну вот тут опять частный случай, для поддержания целостности введен статус. И сам процесс уже совсем другой.
Речь уже не идет об одной операции редактирования, а о продолжненом процессе, а это совсем другая ситуация.
О тразакции речь шла от момента начала редактирования, до конца, до отправки данных на сервер.
Потом наступает другое редактирование и так далее.

> Но я ярый противник тупого батонокидательства и юзания компонент,
> понятия о принципах работы которых нет и в помине. При
> этом, как правило, находится море разливанное советчиков
> и "помощничков" с одним, но смертельным аргументом "У меня
> все работает"

А у тебя не работает, потому что кто-то сделал триггер и тебе об этом не сказал :)))

Что же до тупого баттонокидательства.... многие люди на аксессе такие чудные вещи творят... вообще без транзакций. И без генераторов... И формы создают. И получается у них зачастую быстрее, чем у меня. И достаточно качественно.

>Reindeer Moss Eater © (21.05.08 18:07) [58]
>Документ может вводится днями и валидный статус получать в четверг, в то время как начали его сочинять (вводить) в пятницу вечером.

Дяенька, а может слышали, что есть такая мантра - "проводка" называется. И еще отводка от нее - антимантра - "откат" ? Или в Вашем чуме шаман только бубном пользуются ?

И еще в довесок, - давайте взаимно уважать другу дружка и не лепить заведомо глюкавых агрументов с такими же примерами, а ?

>Anatoly Podgoretsky © (21.05.08 18:32) [59]
>Шиш тебе, а не цветные штаны.

Вот так всегда - гениев признают только после смерти !
Пойду отравлюсь.. стаканом "На березовых бруньках"

>YurikGL © (21.05.08 20:28) [62]
>А у тебя не работает, потому что кто-то сделал триггер и тебе об этом не >сказал :)))

У меня вообще ничего не работает, кроме горла и пуза.
Один обзывается, другой штаны зажал - пошли вы все..

> Пойду отравлюсь.. стаканом "На березовых бруньках"

Посередь рабочей недели? Везет же некоторым :)

> Пойду отравлюсь.. стаканом "На березовых бруньках"

Меняю штаны на бруньки.

> Дяенька, а может слышали, что есть такая мантра - "проводка"
> называется. И еще отводка от нее - антимантра - "откат"
> ? Или в Вашем чуме шаман только бубном пользуются ?

В окружающем мире кроме проводок еще еще масса интересных предметных областей :)
Ох уж эта бухгалтерия - как придет со своими проводками, так никакого спасу :)

>Игорь Шевченко © (22.05.08 00:05) [67]

Магическое слово "проводка" - любимое слово не только шаманов от бухгалтерии, знаешь ли ;)

> [69] Игорь Шевченко © (22.05.08 10:06)
> А чье еще ?

Любой системы, позволяющей распечать документы, котрые затем станут входными для системы.
Например, приказы отдела кадров.
Пока приказ не подписан  это бумажка, а не документ. Так что же клиентский компьютер не выключать все ио время, пока приказ не вернется с подписью руководителя?

ЮЮ © (22.05.08 10:46) [70]

> Любой системы, позволяющей распечать документы, котрые затем
> станут входными для системы.

По
http://slovari.yandex.ru/search.xml?text=%D0%9F%D1%80%D0%BE%D0%B2%D0%BE%D0%B4%D0%BA%D0%B0

не нашел твоего определения.

Странно, с системами, позволяющими вводить, хранить и распечатывать документы знаком довольно долго, термин "проводка" слышал только от бухгалтеров.

> По
> http://slovari.yandex.ru/search.xml?text=%D0%9F%D1%80%D0%BE%D0%B2%D0%BE%D
> 0%B4%D0%BA%D0%B0
>
> не нашел твоего определения.

Страноо, по первой же ссылке

Проводка Ушаков
ПРОВО"ДКА, и, мн. нет, ж. 1. Действие по глаг. провести в 1, 4, 5 и 6 знач.  проводить1 в 1 знач. П. судов. П. счетов по кассовой книге. П. электричества. П. весла по воде (спорт.)

ЮЮ © (22.05.08 11:00) [72]

И какое из определений подходит к системе с документами - электричества, весла по воде или судов ? :)
или все-таки "счетов по кассовой книге" ? Так это чистая бухгалтерия...

«провести документ», «провести приказ»
проводить можно что угодно, что само ходить не хочет :)

проводить девушку до дома  тоже проводка :)

ЮЮ © (22.05.08 11:16) [74]

Э...как бы терминологический спор начался во вполне определенном контексте, начиная с поста [63]

А девушку - это провожание, а не проводка.

> проводить можно что угодно, что само ходить не хочет :)

Но не всегда это называется термином "проводка", верно ? Провести можно и решения съезда КПСС в жизнь, однако существительным будет "проведение решений" :)

> Э&#133как бы терминологический спор начался во вполне определенном
> контексте, начиная с поста [63]

там упоминалась мантры «проводка» и «откат», т.е., как я понял, манипуляции, изменяющие состояние документа
А не «проводка счетов по кассовой книге», ибо как-ио сомневаюсь, что «откаты» тоже отражают в кассовой книге :)

← →
ANB (2008-05-22 11:29) [77]

> Потому что он как правило со своими поделками не имеет дела.

Мне как то пришлось поработать бухгалтером на своей бухгалтерии 2 месяца. Программа в результате сильно улучшила юзабилити :)

ЮЮ © (22.05.08 11:28) [70]

> Пока приказ не подписан — это бумажка, а не документ. Так
> что же клиентский компьютер не выключать все ио время, пока
> приказ не вернется с подписью руководителя?

Пока приказ не подписан, к клиентскому компьютеру он не имеет отношения, нет ? Ну разве что к компьютеру секретарши, на котором она его в Ворде набивает.

← →
ANB (2008-05-22 11:34) [79]

> И какое из определений подходит к системе с документами

В системе с документами это можно назвать "Регистрация".

В АБС например (бухгалтерия для банков), вообще до того, пока документ будет проведен (т.е. изменятся остатки по счетам и его можно будет учитывать в отчетности), он может пройти через 5 статусов. Причем для межбанковских документов статус меняет РКЦ центробанка.

ANB (22.05.08 11:29) [77]

А программтсов вообще надо в принудительном порядке отправлять на объект автоматизации, на полгодика так. Может, лажи поменьше писать будут.

> Пока приказ не подписан, к клиентскому компьютеру он не
> имеет отношения, нет ? Ну разве что к компьютеру секретарши,
> на котором она его в Ворде набивает.

Зачем его набивать в Ворде? Чтобы другая машинистка затем «преносила» их базу, но уже со своими ошибками?

В случае же, когда приказ генерирует система на основании данных в базе, есиь гарантия, что и на бумаге и БД окажутся одни и те же данные.

З.Ы. Тем более, что эти занимается не cекретарща босса, а отдел/управление/департамент кадролв.

← →
ANB (2008-05-22 11:45) [82]

> А программтсов вообще надо в принудительном порядке отправлять
> на объект автоматизации, на полгодика так. Может, лажи поменьше
> писать будут.

+1.

Надо писать программы так, чтобы потом самому было удобно пользоваться.

ЮЮ © (22.05.08 11:41) [81]

> Зачем его набивать в Ворде?

А где его еще набивать ?

> В случае же, когда приказ генерирует система на основании
> данных в базе, есиь гарантия, что и на бумаге и БД окажутся
> одни и те же данные.

Я наверное сильно в другой предметной области области работаю, так как не слышал, чтобы система генерировала приказы.
Можно пример ? :)

← →
ANB (2008-05-22 12:43) [84]

> так как не слышал, чтобы система генерировала приказы.

У меня программа для отдела кадров генерила сама все приказы.
(О назначении северных надбавок, выслуги лет, на отпуск и прочее. Короче, все, что мона сгенерить на автомате).

> ANB (22.05.2008 11:45:22) [82]

Чтобы не побили и не прокляли до седьмого колена.

interbase(проблема ввода данных) Найти похожие ветки