Toad SQL monitor зависает с Супермагом : Супермаг Плюс (Супермаг 2000)

Спасибо, про трассировку я в курсе. Я говорю именно о мониторинге, который можно назвать трассировкой с минимальным уровнем детализации - только PL/SQL, то, что видно на стороне БД во вьюхах V$...

Да, вот именно мне и хотелось бы видеть, какие процедуры и какими параметрами дергает клиентская программа. Аудит пообъектный в оракле я пользовал - типа "какие запросы к какой таблице идут". Почитаю еще про аудит PL/SQL - наверное им воспользуюсь, раз средств мониторинга на клиентской стороне с СуперМАГом не пользуют.

Если вы имеете в виду "не нужно перепроводить документы, скопированные из другой базы", возможно, вы имеете в виду, что проводка сама происходит при копировании документа?

Думаю, ответ "нет", т.к. вы советуете провести глобальную установку цен актом переоценки на все товары, несмотря на скопированные из другой БД уже существующие акты переоценки.

В таком случае, и приходные/расходные документы вы рекомендуете не перепроводить, а сделать один приход (инвентаризацию) на весь ассортимент товара, чтобы актуализировать остатки?

Даже если сообщение ORA-2XXXX приходит в ответ на некоторые действия в программе, хотелось бы понять, что она слала в базу (PL/SQL), в ответ на который пришла ошибка, чтобы ее воспроизвести и, возможно, выполнить PL/SQL пошагово, чтобы разобраться в проблеме. Но тут хотя бы можно предположить, какой пакет/процедура и с какими параметрами вызывается, исходя из бизнес-логики, и пошарить в коде.

А вот если ORA-2XXXX возникает в логе почтового модуля, то я имею еще меньше представления о том, как он общается с базой. Почему и пытаюсь делать мониторинг. Как уже написал выше, опробую штатный аудит оракла, надеюсь, этого будет достаточно.

Да, верно, но самого стека не всегда достаточно для воспроизведения проблемы.

Toad SQL monitor запускает программу как порожденный процесс. Но спасибо за совет, поищем, возможно, существуют такие средства мониторинга, которые могут подсоединиться каким-то образом к уже работающей программе.

У меня возник вопрос, а что вы понимаете под словом "Перепроводить".
У меня ощущение, что я разговариваю с 1С-ником, который при любой болячке предлагает что-нибудь "перепровести".
Вы пересылаете документы из центральной базы в подчиненную. При приеме документа в подчиненной базе данных, меняются необходимые регистры учета (остатки товара, например). Дополнительных действий с документами производить не надо.
Увы, этот способ плохо работает со старыми актами переоценки. Система понимает, что акт переоценки прислан старый, и цену не меняет.
Чтобы поменять цену товара в подчиненной базе, надо создать новый акт переоценки (даже со старыми ценами) и тогда в подчиненной базе данных цена поменяется.
Я этого не говорила.


Примеры приведите, чего вы не понимаете. Почтовик вы таким мониторингом все равно не отловите...

Я на это и надеялся. Но тем не менее регистры - как минимум остатки и цены - не изменились после копирования документов.


Невозможно записать в БД объект «CS, ПКБТ20141221@25», таблица «SMSPECCOMPINF»"
ORA-20097: Несоответствие состава артикула набора/упаковки с документом
ORA-06512: at "SUPERMAG.CORE", line 301
ORA-06512: at "SUPERMAG.SMSPECCOMPLEXART", line 20
ORA-04088: error during execution of trigger 'SUPERMAG.SMSPECCOMPLEXART'

Какая гадость эта ваша заливная рыба...

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

Цены - как уже выше писали - и не обязаны были встать. Их действительно принято копировать одним актом переоценки. Все текущие.

Остатки при получении документа супермаг пересчитывает. При трех условиях:
1) документ должен менять остатки согласно своего типа (к примеру, это приход, возврат, продажа и т.п.)
2) статус документа выше, чем черновик
3) в настройках места хранения, к которому относится документ, не установлен признак "Отключить перерасчет остатков"

Если текущие остатки в базе не соответствуют имеющемуся набору документов, то нужно пересчитать остатки в "администраторе".

Безусловно, можно и цены и остатки перелить между таблицами.
Только при этом можно получить массу забавных побочных эффектов.

Например, стандартная процедура вычисления остатков сама выбирает, откуда ей считать остаток на дату:
- от текущих остатков из smgoods назад по документам;
- от начала времен вперед по документам;
- от остатков на дату закрытого периода.
Если текущие остатки перелить - можно поймать несходимость отчетов.

Потому призываю запросы мониторить и анализировать, чтобы лучше понимать, что происходит.

Для работы же пока использовать штатные механизмы.

Как обычно, все бегом, "давай-давай", "магазин стоит", а ты с этой системой познакомился 2 дня назад. Поэтому так.

Полностью согласен.

Пока сосредоточусь на изучении структуры БД и бизнес-логики, а к этой теме мониторинга можно вернуться во время передышки.

Про наборы прочитал, спасибо. Это уже тема для отдельной темы :).

Исправляюсь. Остатки таки изменились, все в порядке. Наша ошибка была в том, что мы смотрели остатки при скопированных не до конца документах.