Божья_коровка
И что значит при полном их отключении? В двух словах объясни, что ты имеешь в виду...

Надо полагать, of63 предлагает перейти с Oracle на древний MySQL.

Еще один "детский" вопрос: А по каким полям ты проверяешь, что данные до/после изменения?

У тебя в псевдокоде


А остальные поля? Т.е., может с одним единственным полем все хорошо, но остальные вообще не изменялись?

Ну, и проверять все-таки надо из одного места. Если вставка через VFP, то и проверку надо делать в VFP


Кстати, а вставка записей в новую таблицу вообще была? Если триггер сам меняет id, то, может, просто вообще ничего не было вставлено в tab2 и ты тупо смотришь на старые данные. Хотя бы количество записей сравнить можно до и после вставки?

Есть еще предположение по автоконвертации типов данных, если структура полей новой и старой таблиц отличаются. Ну, например, длинная строка автоматически обрезается. Не знаю, какое правило действует в Oracle в случае, если типы данных не могут быть автоматически приведены к нужному типу. Что чисто внешне, может быть принято за запись "старых" данных. Но это на знать структуру таблиц и какие именно значения "старые" и какие "новые" и по каким правилам в Oracle выполняется приведение типов

leonid

Божья_коровка
И что значит при полном их отключении? В двух словах объясни, что ты имеешь в виду...

Надо полагать, of63 предлагает перейти с Oracle на древний MySQL.

() Предложил убрать в коде все упоминания о транзакциях, оставить только сами селекты и инсерты, Оракел сам, "автоматически", что-то там автопотранзактирует. Этим мы проверим код коровкиных собственно селектов и инсертов!



Исправлено: of63, 10.01.21 19:56

Владимир Максимов
Еще один "детский" вопрос: А по каким полям ты проверяешь, что данные до/после изменения?
У тебя в псевдокоде

IF  curTest.pole1 = 'обновленное значение'

А остальные поля? Т.е., может с одним единственным полем все хорошо, но остальные вообще не изменялись?

Ну я делаю через интерфейс изменение нескольких полей, загоняю данные, например 'test1', 'test2' в несколько полей, плюс проверяю айдишник изменений. Т.е. при апдейте MyTable, формируется каждый раз новый айдишник.

Владимир Максимов
Ну, и проверять все-таки надо из одного места. Если вставка через VFP, то и проверку надо делать в VFP

Да итак тоже проверяла.

Владимир Максимов
Кстати, а вставка записей в новую таблицу вообще была? Если триггер сам меняет id, то, может, просто вообще ничего не было вставлено в tab2 и ты тупо смотришь на старые данные. Хотя бы количество записей сравнить можно до и после вставки?

Запись всегда одна. Одна запись в таблице MyTable меняется и она же одна и добавляется в Table2. Триггер меняет только "айдишник изменения записи", у записи несколько айдишников.В таблицу table2 запись вставляется, но с предыдущими данными, т.е. не с 'test1', 'test2'. Т.е. система такая, изменила проца данные в записи с айди=1, значения полей, и эта же запись обновленная с айди=1 вставляется в table2. Т.е. одно изменение (один апдейт) одной записи в MyTable = одна вставка одной записи в table2.

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

Они отличаются, только одним полем. В table2 есть поле, которого нет в MyTable. Но в транзакции я специально делаю перечисление полей, которые нужно вставить и типы данных и наименование перечисленных полей идентичны в обоих таблицах.


------------------




Исправлено: Божья_коровка, 10.01.21 20:16

Igor Korolyov
Без вот этого

Божья_коровка
MyProc

вот этого

Божья_коровка
Висит один триггер, который при апдейте записи формирует айдишник изменения.

и вот этого

Божья_коровка
where id = тут айдишник записи

А так же понимания того что такое

Божья_коровка
данные предыдущие, а не только что обновленные

Нереально что либо понять.

Ну можно лишь посоветовать сделать тест - БЕЗ всего этого, без триггера, без условия в insert ... select, без ХП - чисто какой update или insert напрямую послать - и если и тогда будут "чудеса" - ну это значит системная проблема (остаётся лишь серверную трассировку включать и смотреть что происходит). Пока же есть шанс что дело таки в коде.

Если делать без всего без этого будет чистый лист. Если не рождаться, то и не умирать, т.е. если не жить, то и проблем и странностей не будет. Если послать простой инсерт напрямую, на основе переменных, то всё прекрасно, такой странности не наблюдается. Я же писала выше, что прописала как раз такой вариант, когда тяну на клиента простым селектом эту запись из MyTable, обрабатываю типы, загоняю в переменные и делаю прямой инсерт с values(перечисление переменных) и всё отлично работает. Т.е. подобная странность происходит только с инсертом на основе селекта, а не простым инсертом.


Вот, я писала выше -

Цитата:

В итоге пришлось отказаться от транзакции -

=SQLExec(m.ch, 'insert into tabl2 (перечисление полей) select (перечисление полей) from MyTab where id = тут айдишник записи')

и делать селект

=SQLExec(m.ch, 'select (перечисление полей) from MyTab where id = тут айдишник записи', 'curTest')

обрабатывать типы данных, загонять их в переменные и делать инсерт на основе этих переменных

=SQLExec(m.ch, 'insert into tabl2 (перечисление полей) values (перечисление переменных)')

------------------




Исправлено: Божья_коровка, 10.01.21 20:19

Я и предлагаю сделать тест вида

update tbl1 ... / insert into tbl1 ... не суть важно, абы данные "до и после" чётко различались.

commit

insert into tbl2 ... select ... from tbl1 без дополнительных условий - ВСЕ записи перегнать.

commit

смотреть tbl2 - и из фокса и из сторонней утилиты.

если это сработает как положено - вот тогда изучать код ХП, триггера, собственно фоксовый код вокруг этого самого "id записи". Заодно строку подключения проверить - если драйвер оракловский, там целая куча самых разных параметров имеется. А если MS - то искать по форумам на предмет проблем с оным - с разными типами данных в частности (может он твой id передаваемый из фокса в условии округляет/обрезает/перекодирует - ты даже не упомянула какого типа это поле).


------------------