ValidTimeStateMode = NoGap. Можно ли создать запись в действующем диапазоне

[Владимир Максимов]

Ax2012

Возникла необходимость создать запись "задним числом" в уже созданной истории. Если свойство ключа ValidTimeStateMode = Gap, то все просто:

1. Создаю "дырку" в диапазоне изменяя ValidFrom и ValidTo у существующих записей
2. Создаю новую запись с диапазоном действия в этой "дырке"

А вот если ValidTimeStateMode = NoGap, то при изменении ValidFrom или ValidTo у существующих записей автоматически корректируются диапазоны действий у соседних записей с тем, чтобы исключить появление "дырки". Соответственно, новую запись создать невозможно - будет пересечение диапазонов.

Можно ли это как-то обойти? Т.е. в итоге, по окончании модификации, "дыр" по прежнему не будет, но промежуточное состояние будет с "дыркой"

[sukhanchik]

Если смочь перевести часы на компьютере, где крутится АОС, то должно сработать. Правда у меня не получилось перевести часы )

Общий подход такой - есть 3 режима правки такого рода таблиц:Correction, CreateNewTimePeriod и EffectiveBased
Все режимы запрещают правку в прошлом периоде, однако в текущем и будущем периодах ведут себя по-разному:
Correction позволяет редактировать поля ValidFrom / ValidTo с последующей автоматической корректировкой дат у записей в прошлом / будущем периоде
CreateNewTimePeriod всегда дробит период
EffectiveBased - дробит только текущий период, а будущий правит в режиме Correction

Т.е. если мы убедим систему считать дату из прошлого датой из настоящего, то тогда текущий период можно разбить таким кодом:

    ttsBegin;
    dat = today() + 5; // Тут нужно поставить правильную дату
    select forUpdate validTimeState(dat) items;
    info(strFmt('Выбрана запись %1 со сроком с %2 по %3', items.name, items.ValidFrom, items.ValidTo));
    items.validTimeStateUpdateMode(ValidTimeStateUpdate::CreateNewTimePeriod);
    items.ValidFrom = dat;
    items.write();
    info(strFmt('Изменена запись %1 со сроком с %2 по %3', items.name, items.ValidFrom, items.ValidTo));
    ttsCommit;

где items - это таблица, которая имеет поле name и поля ValidFrom / ValidTo

[Владимир Максимов]

Как-то мне категорически не нравится менять глобальные настройки (системную дату) для решения локальных задач

Пока вышел из положения "хакерским" способом. Прямой модификацией диапазонов командой Update-SQL напрямую на сервере через connection, statement, executeUpdate().

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

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