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, если человек все равно через грид работает? И зачем для работы с гридом нужно знать "особенности движка"?

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

> [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 записей.

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

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

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

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

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

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

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

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

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

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

> [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. Это потенциальный источник дополнительных багов и лишняя нагрузка на сеть и сервер.

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