Hi men dea!

> 4. Или же ведется пошаговая обработка всех измененных записей?

Да пошаговая, причём в 2 прохода (кроме самого верхнего уровня).

Сначала проводим сохранение "удалённых" записей, от самых "глубоких" наружу,
потом сохранение ВСЕХ в курсоре первого уровня, и наконец сохранение
добавленных и изменённых записей - но уже от "наружных" вглубь.

Т.е. если имеется схема вида

A->B->C

1) Циклом по GetNextModified() пропуская все где !DELETED() надо сохранить
С, B
2) Сохраняем все из A
3) Циклом по GetNextModified() - там уже естественно остались только новые и
изменённые записи - в порядке B,C

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

Posted via ActualForum NNTP Server 1.3

Hi men dea!

> 1. Что означает в вашем понимании "в курсоре первого уровня"

это А - тот к которому всё привязано. "Шапка документа" в сложных
документах.

> и "от самых глубоких наружу"?

Если есть "шапка" и "строки", то строки это и есть внутренние, глубокие
уровни. В нарисованной схема B это второй уровень (записи подчинённые A), а
C в свою очередь это 3-й уровень, они подчинены записям из B.

> Курсор 1 уровня - это самый простой справочник или самый составной?

Речь тут не про справочники обычно идёт (я не считаю разумным править в
одной и той-же форме несколько справочников) - а про составные документы -
типа накладных. Там "шапка" и "строки" чётко между собой связаны, и не имеют
смысла сами по себе - т.е. вводятся они вместе, и отображать их тоже имеет
смысл одновременно.

> В моем случае - это filial или kadr ? "Наружу" это от filial к kadr или
> наоборот?

Я не вникал глубоко в твою схему данных, но в общем случае направление
задаётся имеющимися постоянными связями (те что прописаны в самой БД, с
которыми связаны ограничения целостности aka RI - не те временные связи что
устанавливаются для формы).
Т.е. если из A (шапки) нельзя удалить запись, пока в B (строках) есть
ссылающиеся на неё записи (RI ограничение типа Restrict) - то я считаю что А
это "наружняя" таблица, а B соответственно "внутренняя". Заодно опишем
словами и второе Restrict ограничение - на вставку - в B нельзя вставить
записи, ссылающиеся на отсутствующие в A записи.
Из этого и вытекают все мои рассуждения - удалять необходимо сначала из B и
лишь затем из А - а вот вставлять наоборот - сначала в A, а потом в B (т.е.
надо чтобы запись в A уже существовала на момент вставки в B). Также
уточним, что здесь под вставкой/удалением подразумевается работа с самой
таблицей, а не с буфером, или там LocalView - т.е. реально действия
иницииуюся по TableUpdate() а не по командам Delete/Insert/Update - которые
лишь меняют данные в буфере, и как-бы "запоминаются" до момента
tableupdate() чтобы потом выполнить те-же самые изменения но уже в реальных
таблицах.

>> 2. 1) Циклом по GetNextModified() пропуская все где !DELETED() надо
>> сохранить С, B
> Это:
> а) один цикл, в котором обрабатываются сразу C и B?
> б) два идущих вслед друг за другом цикла: сначала по C, потом по B?

Именно так.

> в) два вложенных цикла: внешний по C, внутренний по B?

Нет, вот наоборот в приниципе можно - т.е. крутить цикл по В, внутри него по
C, НО "сохранять" (т.е. реально это будет удаление) сначала записи из С, а
потом из B (ту самую на которую и ссылались только что удалённые из С). Но
это IMHO излишняя сложность - в варианте б) мы получим точно такой-же
результат но заметно проще (псевдо-конфликтов не будет, т.к. сначала мы
удаляем всё из C, и это позволит провести удаление из B). Правда у тебя
(теоретически) могут быть более сложные триггеры, которые потребуют
абсолютно точного соблюдения последовательности операций сохранения, но это
маловероятно, да и других проблем с сильно наворочеными триггерами будет
масса :)
Конечно возможны реальные конфликты - т.е. мы попытались удалить запись из
B, не удалив при этом хотя-бы одну запись из C - это отловится во время
попытки "сохранения" (удаления) этой самой записи из B.

> 3) если имеется схема вида A->B->C
> В моем случае A - это filial или kadr?

Видимо filial - т.к. именно в kadr имеется внешний ключ ссылающийся на
filial... Но тут уж тебе виднее схема.

>> 4) Циклом по GetNextModified() - там уже естественно остались только
>> новые и
>> изменённые записи - в порядке B,C
> А разве нельзя сделать двумя командами
> TableUpdated(.T., B)
> TableUpdated(.T., С)
> без цикла по GetNextModified() ? Ведь там уже не осталось необработанных
> "удаленных" ...

Можно (но конечно и тут 2-х строк не хватит :) ), но тогда сложее "поймать"
на какой из записей произошла ошибка сохранения - а так она уже "под
руками". Впрочем это больше вопрос написания кода - и так можно и этак :)

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

Да вполне возможно :)

> PS Мне кажется, что непринципиально начинать с удаленных

Принципиально. Если в C были добавлены записи, а из B соответствующий
родитель был удалён, то мы получим ошибку при попытке сохранения B, тогда
как IMHO более логично говорить об ошибке в C. Есть и другие моменты -
например если сначала заниматься удалёнными, то для курсора самого верхнего
уровня (A) можно проводить сохранение упрощённо - в один проход - т.к. к
тому времени уже все потенциальные "нарушители" RI правила на удаление
фактически удалены из B.

> Можно и наоборот, только нужно сменить направление обработки.

Направление обработки, если под ним понимать последовательность обработки
таблиц (а не записей) зависит лишь от типа операции. Для удаления необходим
сначала удалить дочерние, а потом родительскую - для вставки наоборот.

Ещё один важный момент - такая схема подразумевает что всё сохранение
проводится в рамках одной транзакции (и если на каком-то этапе возникает
ошибка, то транзакция откатывается - и более того производится RECALL
удалённых записей в буфере - иначе просто невозможно будет исправить ряд
ошибок). Я не вижу такой тесной логической связи между твоими данными, чтобы
требовалась единая транзакция для их сохранения - поэтому скорее всего тебе
необходимо разбить форму на несколько более простых, но логически "цельных".
Т.е. говоря проще при вводе накладной не следует в той-же самой форме
вводить/править товары, клиентов/организации, банки и т.п. Так и тут - при
вводе сумм поощрений не следует в той-же форме править филиалы, организации,
сотрудников и т.п. Тогда форма у тебя получится скорее всего
"однотабличная" - в том смысле что изменения будут вносится в одну таблицу,
а прочие таблицы лишь будут служить для фильтрации и навигации (и не будут
изменяться в данной форме).

Posted via ActualForum NNTP Server 1.3