| Форумы
ЧАТ |
Орешник |
|
| Форумы -» | Основная («Начинающим»)/ Базы / WinAPI / Компоненты / Сети / Media / Игры / Corba и COM / KOL / FreePascal / .Net / Прочее / RSDN.ORG |
|
| ||
|
|
Новости |
Поиск |
FAQ |
Статьи |
Книги |
Новости VCL
| | Форумы ЧАТ |
Орешник |
|
| |||
| |||
| |||
« предыдущая ветвь | форум | следующая ветвь »
interbase(проблема ввода данных) [D7, XP]
kla$ © (2008-05-19 14:16:00)Создал бд. В ней 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. Что я делаю неправильно. Буду рад любым советам, т.к. новичок в этом деле(.
ANB (2008-05-21 12:01:00) [41]
> Смотри как бы тебе что ни будь не оторвали.
Ну, если я на своей работе чего нибудь накосячу, то убытки будут такими, что мне не тока все оторвут :)
Sergey13 (2008-05-21 12:01:00) [42]> [42] Anatoly Podgoretsky © (21.05.08 11:40)
Во первых, подобных конкретных ситуаций здоровенная куча (по крайней мере в моей практике), так что это практически общая конкретная ситуация. 8-)
Во вторых, я и не настаиваю на единственности "моего" варианта. Каждой задаче - свое решение. Просто Ганз как всегда начал наезды на "гридовское редактирование", а я как всегда не стерпел. Это как споры с ИШ про естественные и суррогатные ключи. 8-)
Anatoly Podgoretsky (2008-05-21 11:41:00) [43]> ANB (21.05.2008 11:06:41) [41]
Смотри как бы тебе что ни будь не оторвали.
Anatoly Podgoretsky (2008-05-21 11:40:00) [44]> Sergey13 (21.05.2008 10:48:39) [39]
Ты начал подгонять общую задачу под конкретную ситуацию.
ANB (2008-05-21 11:06:00) [45]
> Anatoly Podgoretsky © (21.05.08 10:22) [38]
У документа статус есть.
В накладной, например, может 500 строк. И если на 450 строке компутер юзера сдохнет или еще чего случится и документ пропадет, то я на месте юзера оторвал бы вам все, что мона оторвать.
Все, что мона записать на сервер, не нарушая ссылочной целостности, надо записывать сразу после ввода юзером.
ЗЫ. Вот она, порочная практика обертки ООП над реляционной моделью. :)
ANB (2008-05-21 10:56:00) [46]
> Документ должен обрабатываться как одно целое, то есть единой
> транзакции
Зачем ? Удобства для юзера еще меньше.
> Sergey13 © (21.05.08 10:12) [37]
Присоединяюсь.
> давайте везде учить оракл ставить... зачем этот интербейз?
Дадад. Абсолютно правильная позиция. И никаких проблем с транзакциями. :)
Кстати, про уведомление других юзеров об изменении данных.
ИМХО : штука полезная, НО :
1. Лучше строить работу юзеров так, чтобы им это было не нужно
2. Это не так уж просто делается
3. Это потенциальный источник дополнительных багов и лишняя нагрузка на сеть и сервер.
Sergey13 (2008-05-21 10:48:00) [47]> [38] Anatoly Podgoretsky © (21.05.08 10:22)
> то налицо имеем нарушение целостности, не ссылочной, а более высокого порядка.
Какое? Пришла накладная, ее оприходовали по закупочным ценам ( которые в ней зафиксированы и не подлежат изменению), теперь надо определиться по какой цене будем этот товар пускать дальше. А может для этого надо провести маркетинговое исследование по ценам у конкурентов или еще что-то в этом духе. С некоторыми документами люди работают неделями, а то и месяцами. Где тогда держать промежуточные данные? У документа может быть (для такого случая) статус - его смена говорит, что документ обработан окончательно или нет. Но никто при этом не запрещает видеть другим людям (хотя бы для справки) результаты уже проделанной кем то работы.
А при восстановлении точно восстановятся (в данном случае) закупочные цены, т.е. состояние документа на зафиксированный момент приемки накладной. С текущей работой - как повезет.
Повторюсь - это напрямую зависит от реально бизнес логики на предприятии.
Anatoly Podgoretsky (2008-05-21 10:22:00) [48]> Sergey13 (21.05.2008 10:12:37) [37]
Ты взял накладную, а это единый документ, состоящий из двух частей.
А насчет нарушения целостности, это сложный вопрос, что считать нарушением в данном случае, если эта накладная будет где то использована во время данной операции и не дай бог при сбое, то налицо имеем нарушение целостности, не ссылочной, а более высокого порядка. То есть имеем и не первоначальное состояние и не конечное, а что то подвешеное в воздухе. И откатываться потом не куда, хорошо, если то кто вводит помнит, что должно получититься, а если это промежуточное, порушеное пройдет по другим документам? А это типичный случай. Конечно надо говорить об конкретной бизнес логики, но в общем случае мое замечание верное в большинстве случаев.
Sergey13 (2008-05-21 10:12:00) [49]> [36] Anatoly Podgoretsky © (21.05.08 09:58)
Документ - понятие довольно размытое, работы с ним тоже бывают разные и зависят он скорее от фактической бизнес-логики конкретного документооборота. В моем примере про заполнение цен по позициям документа по логике могут заполняться не обязательно в одной транзакции, т.к. никакая целостность данных не нарушается.
Anatoly Podgoretsky (2008-05-21 09:58:00) [50]> Sergey13 (21.05.2008 09:07:34) [34]
Документ должен обрабатываться как одно целое, то есть единой транзакции, иначе вариант один приведет ко множественным проблемам, при том не известно заранее к каким и когда.
YurikGL (2008-05-21 09:08:00) [51]
> Похоже, что Вы не воспринимаете то, что Вам говорят. Перекрывая
> убийственным аргументом "А у меня работает !".
Не поверите, воспринимаю :) я писал и относительно сложные системы и простые. А по вашему выходит - давайте везде учить оракл ставить... зачем этот интербейз? А ведь вдруг у нас будет большое предприятие с тысячами задач. И давайте сразу детей в школе "правильно" учить извлекать корни. В том числе из отрицательных чисел.
Sergey13 (2008-05-21 09:07:00) [52]> [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 записей.
Причем в первом варианте мы обновляли возможно достаточно сложный запрос со связями и т.п., во втором варианте перечитывали запись по первичному ключу.
MsGuns (2008-05-21 08:19:00) [53]Похоже, что Вы не воспринимаете то, что Вам говорят. Перекрывая убийственным аргументом "А у меня работает !".
Мне, слава Богу, не работать ни с Вами, ни с Вашими программами. Людей жалко..
Засим примите и проч.
YurikGL (2008-05-21 07:36:00) [54]
> Вам нужны цифры ? Их нет у меня.
Тогда не пиши..
> Тем, что Вы получите на клиенте НЕВЕРНОЕ значение идентификатора.
> Точнее, он будет неверным, если Вы не предпримете ряд телодвижений.
Странно... у меня нет никаких проблем.
> Дело в том, что считывает и отправляет на сервер информацию
> вовсе не грид, и знание механизма КАК это делается позволит
> разработать ПРОФЕССИОНАЛЬНОЕ приложение.
Ага... знания нужны что бы делать профессиональные приложения... зашибись.... а если работать не через грид, то знания движка не нужны наверное.
> Видите ли, уважаемый, я искренне считаю, что учить надо
> сразу ПРАВИЛЬНО.
Возвращаясь к вышесказанному... чем неправилен подход с generationfield? Тем что у кого-то он не работает? Ну что теперь... у меня замечательно работает... И не только у меня. Да и то, что учить нужно сразу правильно - тоже весьма спорно... вот в школе нас учили, что нельзя брать корни из отрицательных чисел, и что атом, это - шарик.
> Совсем недостаточно надежно. Программист, разрабатывающий
> клиентское приложение и не имеющий понятия о сервере - все
> равно, что водитель, знающий правила ДТП, но не умеющий
> водить автомобиль. Он просто опасен.
Еще раз спрашиваю, чем ненадежно? Тем, что "а вдруг на сервере есть триггер?"
> Только то, что не стОит настаивать на Вашем способе, будучи
> не уверенным в том, что он правелен или хотя бы надежен.
Он правилен, проверен и надежен.
> Ничего спорного нет. Для IB - обычная технология.
Один из возможных способов. Не более. И, кстати, не единственный способ "серверного" добавления значения первичного ключа.
> Именно это и приводит к очень трудноискомым ошибкам, которые
> к тому же носят весьма плавающий характер
Честное слово, как страшно жить...
з.ы. резюмируя. Если сомневаетесь в способе - можете сами проверить.
MsGuns (2008-05-20 22:50:00) [55]>YurikGL © (20.05.08 22:06) [29]
>Кстати, я даже особенно не понимаю, что вы пытаетесь доказать...
Только то, что не стОит настаивать на Вашем способе, будучи не уверенным в том, что он правелен или хотя бы надежен.
>Что generatorfield лучше не использовать? Тогда нужны критерии >использования или не_использования...
Можно, конечно. В том случае, если при вставке в таблице ID не определяется сервером самостоятельно, поверьте - это вовсе не так маловажно - зачастую сервер кроме вставки этой самой записи может выполнить еще кучу всякой работы, о которой Ваша прога даже не подозревает (например, регистрация в логах).
И вообще вся ваша (точнее IBX-я) технология превосходно будет работать на локальном варианте. И только.. Если Предполагается критичное к интерактивности клиентское приложение, то транзакции надо "брать в свои руки" ;)
>Что первичный ключ правильно заполнять через триггер? Весьма спорно....
Ничего спорного нет. Для IB - обычная технология. Опять же отсылаю к Ковязину. Причем триггер вполне может взять ID из записи, а не самостоятельно щелкать генератором. Но это - в простейшем случае. Для создания НАДЕЖНОЙ технологии, повторяю, максимум "серверного" функционала лучше поручать ему же, т.е. серверу
>Что редактировать в гриде - плохо? Опять же, когда плохо... в каких случаях...
Повторяю в 66 раз - грид тут вообще не при чем. А при чем здесь неполный контроль за запуском и подтверждением транзакций. Именно это и приводит к очень трудноискомым ошибкам, которые к тому же носят весьма плавающий характер
MsGuns (2008-05-20 22:40:00) [56]>YurikGL © (20.05.08 22:04) [28]
>Неужели? Есть аналитические данные? Статистика?
Вам нужны цифры ? Их нет у меня. Зато есть несколько чужих интербэйзных БД, где все добавления делаются через триггеры, которые, в свою очередь.. ну, Вы поняли.
>Главное, я так и не понял, чем плох generationfield, если человек все равно через грид работает?
Тем, что Вы получите на клиенте НЕВЕРНОЕ значение идентификатора. Точнее, он будет неверным, если Вы не предпримете ряд телодвижений.
>И зачем для работы с гридом нужно знать "особенности движка"?
Дело в том, что считывает и отправляет на сервер информацию вовсе не грид, и знание механизма КАК это делается позволит разработать ПРОФЕССИОНАЛЬНОЕ приложение.
>Неужели вы думаете, что начинающий программист вот так сразу будет >писать базу для большого предприятия? Может он всю жизнь будет писать >небольшие базы? Может даже с одним клиентом... Зачем сразу тащить >пушку, если, пока, воробей.
Видите ли, уважаемый, я искренне считаю, что учить надо сразу ПРАВИЛЬНО.
>з.ы. указанный мною способ позволяет легко быстро и достаточно надежно создать приложение без знаний о триггерах.
Совсем недостаточно надежно. Программист, разрабатывающий клиентское приложение и не имеющий понятия о сервере - все равно, что водитель, знающий правила ДТП, но не умеющий водить автомобиль. Он просто опасен.
>А фактор "изменения сделанные на одном клиенте не сразу видны на другом", никак не зависит от того "через грид добавляются записи" или "не через грид".
Он не может не зависеть, если Вы будете использовать IBX. И об этом пишет тот же Ковязин. И дело не в гриде (сколько можно повторять) а в технологии управления транзакциями по принципу "Как Бог (IBX) даст"
YurikGL (2008-05-20 22:06:00) [57]>MsGuns ©
Кстати, я даже особенно не понимаю, что вы пытаетесь доказать...
Что generatorfield лучше не использовать? Тогда нужны критерии использования или не_использования...
Что первичный ключ правильно заполнять через триггер? Весьма спорно....
Что редактировать в гриде - плохо? Опять же, когда плохо... в каких случаях...
YurikGL (2008-05-20 22:04:00) [58]
> Нет, конечно ! Но один из самых надежных и часто используемых
Неужели? Есть аналитические данные? Статистика? Главное, я так и не понял, чем плох generationfield, если человек все равно через грид работает? И зачем для работы с гридом нужно знать "особенности движка"?
> Вот-вот. ВАМ НЕ НУЖНО ! Но это не значит, что ЭТО не нужно
> другим. А учить все же пытаетесь. И в этом Ваше заблуждение.
Неужели вы думаете, что начинающий программист вот так сразу будет писать базу для большого предприятия? Может он всю жизнь будет писать небольшие базы? Может даже с одним клиентом... Зачем сразу тащить пушку, если, пока, воробей.
з.ы. указанный мною способ позволяет легко быстро и достаточно надежно создать приложение без знаний о триггерах. Единственный минус - запросы автоматически не всегда корректно формируются. Да и при относительно большом числе клиентов можно коллизии получить. А фактор "изменения сделанные на одном клиенте не сразу видны на другом", никак не зависит от того "через грид добавляются записи" или "не через грид".
MsGuns (2008-05-20 21:50:00) [59]>YurikGL © (20.05.08 21:38) [26]
>По вашему, триггер - единственный путь, для вставки значения генератора >в первичный ключ?
Нет, конечно ! Но один из самых надежных и часто используемых
>А если, это не требуется? Если у меня сидит 10 операторов, которые тупо >заносят данные в систему? И раз в месяц я делаю отчеты?
Вот-вот. ВАМ НЕ НУЖНО ! Но это не значит, что ЭТО не нужно другим. А учить все же пытаетесь. И в этом Ваше заблуждение.
YurikGL (2008-05-20 21:38:00) [60]
> А вот триггер, использующий генератор как механизм полученеия
> гарантированно уникального значения для ЭТОГО генератора,
> может использовать его именно как ИСТОЧНИК для определения
> ID добавляемой в таблицу записи.
По вашему, триггер - единственный путь, для вставки значения генератора в первичный ключ?
> т.е. будут видеть изменения, сделанные другими в нужный
> момент.
А если, это не требуется? Если у меня сидит 10 операторов, которые тупо заносят данные в систему? И раз в месяц я делаю отчеты?
| |
Страницы: 