Мне необходимо создать объект в Creatio - адресообразующую таблицу ФИАС, которая не имеет нормализованной структуры. В данной таблице хранятся регионы/районы/города/населённые пункты/улицы - очевидно, что данная таблица должна ссылаться на саму себя.
Можно создать дополнительную таблицу развязки, в которой одно поле будет ссылаться на дочернюю запись, а другое - на родительскую. Такое решение позволит хранить в одной таблице повторяющиеся Id.
Ирина Кузина пишет:
При создании объекта в Creatio 7.18 на уровне БД в таблице все поля имеют constraint NOT NULL - как создавать поля, которые могут быть NULL? Поскольку при создании объекта в Creatio на поле есть Основной параметр - Обязательное (Нет или На уровне приложения). При выборе обязательности на уровне приложения - внутри самой платформы производится валидация поля, но если указать обязательность Нет, то всё равно на уровне БД NOT NULL. Зависит ли это как-то от типов полей, которые выбираются?
Да, зависит от типа данных. Например, для поля справочного типа (с типом уникальный идентификатор), возможно хранение значения NULL. Для строковых будет пустая строка (даже пустых), для целочисленных и дробных 0. А обязательность для строковых и цифровых значений означает, что пользователь должен ввести значение отличное от пустой строки или 0.
Ирина Кузина пишет:
тут подскажите, пожалуйста, стоит ли новый пост завести (или может багу/доработку) или в рамках данного вопроса сойдёт?
Это скорее особенность этой срм, а не ошибка. Вы можете написать в службу поддержки (support@terrasoft.ru), они зафиксируют Ваше пожелание.
Сначала создаете саму таблицу сохраняете её и публикуете, а потом уже добавляете в неё справочное поле ParentId, для которого в качестве справочника указываете созданную Вами таблицу.
Но возник новый вопрос, при создании такой связи поле по дефолту ссылается на PK таблицы, но если нужное родительское поле НЕ является PK, то как можно организовать такую связь?
Но возник новый вопрос, при создании такой связи поле по дефолту ссылается на PK таблицы, но если нужное родительское поле НЕ является PK, то как можно организовать такую связь?
Опишите подробнее какую задачу нужно реализовать, возможно, в Вашем случае лучше применить другое решение.
Мне необходимо создать объект в Creatio - адресообразующую таблицу ФИАС, которая не имеет нормализованной структуры. В данной таблице хранятся регионы/районы/города/населённые пункты/улицы - очевидно, что данная таблица должна ссылаться на саму себя.
В данной таблице есть поле AOID - является первичным ключом и содержит всегда уникальное значение. Также есть поля AOGUID и ParentGUID
AOGUID - может иметь повторяющиеся значения. ParentGUID на записи должен ссылаться именно на AOGUID, поскольку AOID является идентификатор именно записи в таблице, а AOGUID - глобальный уникальный идентификатор адресного объекта (хоть здесь и указано, что уникальный, но в ФИАС есть повторяющиеся записи адресного объекта, но с разным статусом актуальности).
И доп. вопрос - тут подскажите, пожалуйста, стоит ли новый пост завести (или может багу/доработку) или в рамках данного вопроса сойдёт?
При создании объекта в Creatio 7.18 на уровне БД в таблице все поля имеют constraint NOT NULL - как создавать поля, которые могут быть NULL? Поскольку при создании объекта в Creatio на поле есть Основной параметр - Обязательное (Нет или На уровне приложения). При выборе обязательности на уровне приложения - внутри самой платформы производится валидация поля, но если указать обязательность Нет, то всё равно на уровне БД NOT NULL.
Зависит ли это как-то от типов полей, которые выбираются?
Мне необходимо создать объект в Creatio - адресообразующую таблицу ФИАС, которая не имеет нормализованной структуры. В данной таблице хранятся регионы/районы/города/населённые пункты/улицы - очевидно, что данная таблица должна ссылаться на саму себя.
Можно создать дополнительную таблицу развязки, в которой одно поле будет ссылаться на дочернюю запись, а другое - на родительскую. Такое решение позволит хранить в одной таблице повторяющиеся Id.
Ирина Кузина пишет:
При создании объекта в Creatio 7.18 на уровне БД в таблице все поля имеют constraint NOT NULL - как создавать поля, которые могут быть NULL? Поскольку при создании объекта в Creatio на поле есть Основной параметр - Обязательное (Нет или На уровне приложения). При выборе обязательности на уровне приложения - внутри самой платформы производится валидация поля, но если указать обязательность Нет, то всё равно на уровне БД NOT NULL. Зависит ли это как-то от типов полей, которые выбираются?
Да, зависит от типа данных. Например, для поля справочного типа (с типом уникальный идентификатор), возможно хранение значения NULL. Для строковых будет пустая строка (даже пустых), для целочисленных и дробных 0. А обязательность для строковых и цифровых значений означает, что пользователь должен ввести значение отличное от пустой строки или 0.
Ирина Кузина пишет:
тут подскажите, пожалуйста, стоит ли новый пост завести (или может багу/доработку) или в рамках данного вопроса сойдёт?
Это скорее особенность этой срм, а не ошибка. Вы можете написать в службу поддержки (support@terrasoft.ru), они зафиксируют Ваше пожелание.
В процессе администрирования базы данных возникла необходимость определить причину возникновения ошибки. Определенный объём информации импортируется в базу данных, с которым далее пользователи работают. В процессе заполнения определенного набора полей автоматически высчитывалась итоговая сумма в поле «Итого». Но в определённый промежуток времени использования продукта начали появляться ошибки, связанные с несоответствием значения поля «Итого» сумме полей из которых оно вычисляется («Сумма покупки», «Наценка», «Сбор» и т.д.). Так как ошибку не получалось явно повторить, необходимо было разработать механизм для решения данной проблемы.
Естественно самой реальной и первой причиной возникновения такой ошибки приходила идея о сбоях в работе событий полей окна редактирования (то есть значения в полях изменялись, а события данных полей(-я) не срабатывали).
В основу решения было положено создание двух таблиц в базе данных для ведения логов, что происходят с записью набора данных. Первая таблица 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 адресу: !!!
В случае возникновения дополнительных вопрос по теме могу поделиться более детальной информацией.
Добрый день. Подскажите где находится сервис отвечающий за продажи, интересует вопрос по Детали продаж - Стадии. Собираюсь импортировать данные в раздел продаж, и соответственно хочу привязать деталь Стадии при импорте.
В компании работал сотрудник, создавший группу сервисов.
На этих сервисах висит блокировка, снять которую без сотрудника не представляется возможным.
Есть ли способы разблокировать сервисы, заблокированные другим пользователем?
