В процессе администрирования базы данных возникла необходимость определить причину возникновения ошибки. Определенный объём информации импортируется в базу данных, с которым далее пользователи работают. В процессе заполнения определенного набора полей автоматически высчитывалась итоговая сумма в поле «Итого». Но в определённый промежуток времени использования продукта начали появляться ошибки, связанные с несоответствием значения поля «Итого» сумме полей из которых оно вычисляется («Сумма покупки», «Наценка», «Сбор» и т.д.). Так как ошибку не получалось явно повторить, необходимо было разработать механизм для решения данной проблемы.
Естественно самой реальной и первой причиной возникновения такой ошибки приходила идея о сбоях в работе событий полей окна редактирования (то есть значения в полях изменялись, а события данных полей(-я) не срабатывали).
В основу решения было положено создание двух таблиц в базе данных для ведения логов, что происходят с записью набора данных. Первая таблица WindowLog, а вторая TriggerLog.
Первая таблица WindowLog включает в себя поля «Дата создания»(CreatedOn), «Идентификатор записи» (RecordID), «Ответственный» (WindowsUser), «Имя поля породившего событие»(FieldName), «Итого» и поля из которых оно вычисляется («Сумма покупки», «Наценка», «Сбор» и т.д.). Для наполнения таблицы было использованы события невизуального компонента окна dlData: dlDataOnDatasetDataChange, dlDataOnDatasetBeforePost и dlDataOnDatasetAfterPost. В скрипте в событиях была создана функция, которая формировала SQL запрос к таблице WindowLog базы данных с фиксацией информации по указанным полям на момент срабатывания события.
Вторая таблица TriggerLog включает в себя поля «Дата создания»(CreatedOn), «Идентификатор записи» (RecordID), «Состояние» (до изменения записи и после), «SystemUser», «Итого» и поля из которых оно вычисляется («Сумма покупки», «Наценка», «Сбор» и т.д.). Для заполнения данной таблицы был создан триггер на инструкцию UPDATE проблемной таблицы с двумя запросами вставки значений в таблицу. В одном запросе вставлялись значения до изменений, а во втором после.
Запрос №1:
INSERTINTO TriggerLog (*набор полей*) SELECT(*набор полей*) FROM deleted
Запрос №2:
INSERTINTO TriggerLog (*набор полей*) SELECT(*набор полей*) FROM inserted
Результатом использования данного решения на основе анализа таблицы WindowLog было установлено, что срабатывают все события окна редактирования, влияющие на вычисление значения поля «Итого». В процессе использования окна редактирования и после сохранения записи значения поля «Итого» были корректны.
Проанализировав записи в таблице TriggerLog было установлено, что в результате выполнения инструкции UPDATE было внесено некорректное значение. Сопоставив даты создания записей в таблице TriggerLog и WindowLog было установлено, что инструкция UPDATE была вызвана не в результате манипуляций с окном редактирования, а иным источником. На основании поля «SystemUser» таблицы TriggerLog было установлено что изменения были внесены с помощью импортера данных.
Таблицу TriggerLog возможно расширить, добавив в нее поля, которые помогут ускорить процесс обнаружение источника изменений записи базы данных. Список дополнительных полей может выгладять следующим образом: ApplicationName, LoginName, HostName.
PS: Принимаю предложения на доработку вашей конфигурации!!! Для более детальной информации можно связаться по следующему e-mail адресу: !!!
В случае возникновения дополнительных вопрос по теме могу поделиться более детальной информацией.
Здравствуйте! Создала в новом разделе в деталях вкладку Файлы1, Файлы2. При удалении файлов из деталей раздела они исчезают с грида, но в базе остаются. Это можно просмотреть с помощью SQL Navigator'a. Проверяла со вкладками Файлы стандартных разделов. Файлы из базы удаляются тоже. Скажите, пожалуйста, почему в моем случае файлы удаляются только из грида, а в базе остаются?
Добрый день, Екатерина.
Нужно анализировать содержимое таблиц tbl_FileInMyRazdel и tbl_Files.
В Вашем случае, видимо, были успешно удалены записи из tbl_Files, но не удалены записи из tbl_FileInMyRazdel. Для исправления ошибки необходимо в таблице tbl_FileInMyRazdel для обоих внешних ключей установить признак "Каскадный", что означает каскадное удаление записи в tbl_FileInMyRazdel при удалении записи в tbl_Files, которое происходит при нажатии на кнопку "Удалить" в реестре детали.
Желаю успехов!
Здравствуйте, Дмитрий!
Спасибо за ответ! По аналогии со стандартными подобными таблицами в таблице tbl_FileInMyRazdel есть две каскадные связи. Но в том-то и дело, что из этой таблицы в итоге файлы не удаляются.
Доброго дня! Нужно проверить есть ли действительно эти ключи в структуре базы. Возможно, что имело место сохранение сервиса без обновления структуры. Если ключей нет, то необходимо пересохранить сервис таблицы.
Возможно так же, что была использована не стандартная деталь, а некоторая, созданная своими силами, тогда необходимо описание что и как было сделано.
Так же, возможно, что в качестве набора данных для детали был указан набор данных ds_FileInMyRazdel вместо стандартного ds_FileInItem и тогда записи удаляются только из таблицы связки, а сами файлы остаются. В этом случае надо привести деталь к стандартному виду.
