:: Visual Foxpro, Foxpro for DOS
и, все таки КурсорАдаптер
shmsoft
Хочется иметь мнения оследующих свойствах, и их взаимодействиях
KeyFieldList, Updatenamalist, UpdatableFieldList, WhereType
(имеется ввиду, конечно, КурсорАдаптер for SQL)
Ratings: 0 negative/0 positive
Re: и, все таки КурсорАдаптер
JS

Сообщений: 12264
Откуда: Эстония
Дата регистрации: 04.09.2000
Частично здесь - внизу www.hot.ee




------------------
Knowledge is better than ignorance!
Website: juri.foxhelp.eu
Ratings: 0 negative/0 positive
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
Ratings: 0 negative/0 positive
Re: и, все таки КурсорАдаптер
Диченко
Автор
Я отказался от использования CA обратно в пользу SQLEXEC. У меня вся бизнес логика основана на ХП, прямые обращения к таблицам я не использую. А CA не позволяет возвращать из ХП output параметры, что страшно неудобно.
Ratings: 0 negative/0 positive


Извините, только зарегистрированные пользователи могут оставлять сообщения в этом форуме.

On-line: 23 (Гостей: 23)

© 2000-2024 Fox Club 
Яндекс.Метрика