и, все таки КурсорАдаптер | |
---|---|
shmsoft Автор |
Хочется иметь мнения оследующих свойствах, и их взаимодействиях
KeyFieldList, Updatenamalist, UpdatableFieldList, WhereType (имеется ввиду, конечно, КурсорАдаптер for SQL) |
Re: и, все таки КурсорАдаптер | |
---|---|
JS Сообщений: 12264 Откуда: Эстония Дата регистрации: 04.09.2000 |
Частично здесь - внизу www.hot.ee
------------------ Knowledge is better than ignorance! Website: juri.foxhelp.eu |
Re: и, все таки КурсорАдаптер | |
---|---|
Igor Korolyov Сообщений: 34580 Дата регистрации: 28.05.2002 |
Hi, shmsoft!
Все эти свойства служат для автоматического формирования SQL команд "обновления" данных (INSERT/UPDATE/DELETE - далее для простоты по первой букве их буду называть). Правила довольно простые, и ПРОЩЕ всего поиграться с этими свойствами, написав в BeforeUpdate/BeforeInsert/BeforeDelete команды, которые выведут на экран или в файл сформированные автоматически SQL команды. Если кратко то: KeyFieldList - служит исключительно для формирования WHERE части U/D запросов во всех режимах WhereType. UpdatableFieldList - служит для формирования WHERE части U/D запросов лишь в режимах 2 и 3 WhereType - при этом в режиме 2 в WHERE включаются ВСЕ поля, а в 3 - только те что были изменены. Такое добавление "лишних" полей (они не нужны чтобы найти собственно ту запись, которую требуется обновить - для этого достаточно ключевых полей!) позволяет отследить конфликты совместного доступа - т.е. когда кто-то "извне" поменял какие-то поля в той записи, которую мы и хотим изменить. Кроме того UpdatableFieldList определяет какие поля будут включены в список обновляемых в команде U (в часть SET поле = новое_значение) и в список "устанавливаемых" в команде I. В общем те поля что не являются ключевыми и не являются обновляемыми ВООБЩЕ не участвуют в процессе обновления. Кстати второй параметр функции TableUpdate как раз позволяет не переключая WhereType перейти к режиму 1 - т.е. "игнорировать" все изменения, которые были внесены в исходную запись в промежутке времени между тем как мы её получили, и тем когда её сохраняем. Естественно что игнорируется всё КРОМЕ изменений ключевого поля (полей) - т.к. после изменения ключевого поля нету никакой возможности найти "старую" запись (RECNO в SQL отсутствует как таковой). Ну да это маловероятный сценарий (ключевые поля обычно НЕ меняются в ходе изменения записей, максимум что реально применимо - это их первоначальное присвоение - т.е. задание их значений для новой записи ДО её сохранения). Вот что более возможно - так это ситуация "внешнего удаления" - т.е. мы работали, работали - а кто-то другой нашу запись и почикал Тут обычная логика не сработает (U не может "создать" запись), а вот логика "D + I вместо U" - как раз и позволяет решить проблему (однако она имеет массу других недостатков). Tables и UpdateNameList служат для однозначного отображения полей курсора и полей базовой таблицы (или таблиц!) - т.е. именно по UpdateNameList определяется какое же слово подставлять в качестве имени поля, для соответствующего поля локального курсора. Tables также позволяет организовать "многотабличное" обновление - однако IMHO такого следует по возможности избегать - единственное исключение пожалуй это связи типа один_к_одному - во всех прочих случаях просто получается большая куча проблем, из-за "прямолинейности" алгоритма формирования SQL команд. P.S. В общем и целом работа CA в режиме авто-формирования команд (когда соответствующие *Cmd не заданы и в соответствующих Before* обработчиках мы ничего не меняем) практически ничем не отличается от работы RemoteView! (ну мы не говорим про ConversionFunc и прочие тонкости). ------------------ WBR, Igor |
Re: и, все таки КурсорАдаптер | |
---|---|
Диченко |
Я отказался от использования CA обратно в пользу SQLEXEC. У меня вся бизнес логика основана на ХП, прямые обращения к таблицам я не использую. А CA не позволяет возвращать из ХП output параметры, что страшно неудобно.
|
© 2000-2024 Fox Club  |