Владимир Максимов
...Примерно так получается. Это общая схема, чтобы показать сам принцип...

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

Вот еще один вопрос, перед изменениями в таблицы, в самом начале метода save, я выполняю tableupdate вью, с буферизацией 3. Их тоже следует в транзакцию "оборачивать" ?

DmitryKn
Вот еще один вопрос, перед изменениями в таблицы, в самом начале метода save, я выполняю tableupdate вью, с буферизацией 3. Их тоже следует в транзакцию "оборачивать" ?

Эти View какую ф-ию выполняют, просто отображают данные или через них вносятся данные?

И потом 3 буферизация подразумевает, что в 99% случае данные уже скинуты в источник при неявком TableUpdate().

Через них вносятся данные, в те самые таблицы.

И еще вопрос сразу возник.
У меня есть "служебная" процедура, в которой сканируются все записи.
ранее это было довольно быстро, до 1 минуты, после установления Relations предположительно резко затормозилось. Предположительно - потому что не дождался окончания, правда ждал не более 15 минут, но записей в таблицах не так, что бы и много - 100 К ... 500 К.
Таблицы:
ord_h — out_h (дочерняя) — out_d (дочерняя к out_h)
— ord_d(дочерняя к ord_h)

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

1. Так, не надо путать Relation с бизнес правилами определенными в триггере - это две несвязанные вещи.

2. Да, тормоза возникли именно из-за триггеров, в коде происходит replace (update) соотвественно срабатывает триггер на Update.

3. Что делать, надо это безобразие переписать, и первое, ответить на вопрос нафига эти скан в с кане нужны (вангую, это попытка выправить кривизну данных)

DmitryKn
Через них вносятся данные, в те самые таблицы.

Установить на View 5 буферизацию, затем делать TableUpdate в транзакции, как уже выше написали.





Исправлено 1 раз(а). Последнее : PaulWist, 19.12.22 21:17

PaulWist
...
2. Да, тормоза возникли именно из-за триггеров, в коде происходит replace (update) соотвественно срабатывает триггер на Update.
...

я тоже так сразу подумал, но вот репласе-то в курсоре, там никаких триггеров нет, сами таблицы никак не меняются.

Цитата:

и первое, ответить на вопрос нафига эти скан в с кане нужны (вангую, это попытка выправить кривизну данных)

данные, насколько я могу судить, в норме. Но да, это про кривизну - это был контроль, так сказать, сравнивались остатки с расчетными, упрощенно все приходные минус все расходные. И вот тогда, если был глюк, то можно было установить карточку и выяснить что к чему.
Сейчас Relations установлен, но как я могу знать, хотя бы первое время, что все работает как надо?
Так что ответ - сканы для контроля были нужны, можно ли это ускорить или в какую сторону подумать, что бы такой контроль был? Есть вообще такая практика?



Исправлено 1 раз(а). Последнее : DmitryKn, 19.12.22 21:43

DmitryKn

я тоже так сразу подумал, но вот репласе-то в курсоре, там никаких триггеров нет, сами таблицы никак не меняются.

Так что ответ - сканы для контроля были нужны, можно ли это ускорить или в какую сторону подумать, что бы такой контроль был? Есть вообще такая практика?

1. В каком курсоре, как он получается? Надо полагать перед scan просто открывается таблица use и по ней делается скан.

2. Ускорить можно, надо переписать на select (те найти кривые данные, для этого надо понимать правила покотороым определяется кривизна), добавить необходимые индексы для Rushmore, затем править кривизну.

PaulWist
1. В каком курсоре, как он получается? Надо полагать перед scan просто открывается таблица use и по ней делается скан.

прошу извинить, я код привел только самого скана, что бы пояснить, как он работает, создание курсора не привел и про него ничего не сказал. Перед сканом создается курсор create cursor ... cslip, наполняется из таблицы с помощью insert. Никаких таблиц с помощью use тут не открывается. После заполнения курсора выполняется скан по таблицам, а изменения - replace - выполняются только в курсоре. Еще раз извините, это нужно было, конечно, указать.

Цитата:

2. Ускорить можно, надо переписать на select (те найти кривые данные, для этого надо понимать правила покотороым определяется кривизна), добавить необходимые индексы для Rushmore, затем править кривизну.

просто тупо select * from table into cursor ctable , index on table_id tag table_id - и будет быстрее scan ?

DmitryKn
Перед сканом создается курсор create cursor ... cslip, наполняется из таблицы с помощью insert. Никаких таблиц с помощью use тут не открывается. После заполнения курсора выполняется скан по таблицам, а изменения - replace - выполняются только в курсоре. Еще раз извините, это нужно было, конечно, указать.

У таблиц убрать буферизацию, либо переоткрыть их под другими алиасами без буферизациии.

Давай DDL таблиц с индексами.

DmitryKn
просто тупо select * from table into cursor ctable , index on table_id tag table_id - и будет быстрее scan ?

Ну не совсем "тупо", а выбрать только те записи у которых есть кривизна, что бы не лазить 100500 раз по всем таблицам.

курсор



Таблицы, теперь уже с RI, это с чего началось )




Исправлено 1 раз(а). Последнее : DmitryKn, 20.12.22 14:15

Доброго дня!

Подскажите, будут ли как-то отличаться индексы в таблицах tab1 и tab2 после того, как между ними (таблицами) установили постоянные отношения и restrict в RI (сами индексы, например, в дизайнере таблиц, не меняли) ?

DmitryKn
Доброго дня!
Подскажите, будут ли как-то отличаться индексы в таблицах tab1 и tab2 после того, как между ними (таблицами) установили постоянные отношения и restrict в RI (сами индексы, например, в дизайнере таблиц, не меняли) ?

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

SSA прав

Похоже, под словом "индексы" ТС подразумевает не содержимое индексных файлов, а индексные выражения:

Цитата:

сами индексы, например, в дизайнере таблиц, не меняли

Хотя ответ в любом случае тот же.

Но, конечно, фраза:

Цитата:

будут ли как-то отличаться индексы в таблицах tab1 и tab2

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



Исправлено 1 раз(а). Последнее : akvvohinc, 24.12.22 18:46

Спасибо, ответ SSA исчерпывающий

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

В индексных файлах CDX просто списки номеров строк, удовлетворяющих возможным значениям заданного индексного выражения. Примерно как в SQL-запросе сделать группировку (по заданному индексному выражению), и перечислить для каждого возможного значения выражения в группе)ах) номера записей, RECNO()

Цитата:

Например, если скопировать индексный файл куда-то, потом в таблице установить отношения (выражения индексов не меняем), потом скопировать этот файл обратно, повлияет ли.

Видимо, имеется в виду не скопировать куда-то, а переместить.

Если структурный индексный файл переместить (удалить), то при первом открытии таблицы, к которой он относился, будет выдана ошибка 1707 - Structural .CDX file is not found.
При этом в заголовке таблицы признак того, что таблица имеет структурный индекс, будет сброшен, и повторное открытие таблицы пройдёт без ошибок.
Фокс будет считать, что таблица не имеет индексов, поэтому простой возврат индексного файла "на место" ни к чему не приведёт - таблица его не "признает" (можно, правда, сброшенный признак восстановить с помощью файловых функций низкого уровня).

Если же между перемещением индексного файла туда/сюда таблицу не открывать, то ничего плохого не случится.

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