Добрый день. Необходимо обновить БСП. Там измерение регистра меняется с типа "Дата" на Универсальная дата в миллисекундах, т.е. число(14,0). Регистр огромный. Десятки миллионов записей.
В голову приходят 2 варианта:
1. накатывать в 3 релиза сначала доп. реквизит и в него скопировать дату, затем поменять тип и вернуть значения, уже преобразовав, потом удалить реквизит
2. Выгрузить в файл перед апдейтом, а после загрузить. Более приоритетный, конечно, но оба варианта чудовищные на самом деле.

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

(0) а что за регистр сведений? и какие версии БСП?

(0) и да, я бы делал вторым способом.

я, как ленивый чувак, сделал бы по 1 сценарию, но немножко иначе.
а) добавить реквизит\измерение\ресурс с Универсальная дата в миллисекундах, неспешно заполнить с конвертацией из исходного.
б) удалить исходный, реквизит\измерение\ресурс переименовать в исходный.

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

(3) неплохой вариант

в юникстайм*1000

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

(4) это более производительный вариант, но тут надо кроме конфигуратора уметь открыть MSSMS, например.

Я так понимаю, весь вопрос упирается в изменение измерения регистра. Ибо преобразование даты - не вопрос ("Миллисекунды=Дата*1000;")

(9) а вот неправильная у тебя формула

(0) "накатывать в 3 релиза" - не в три, а в два релиза: добавить тип число; обработка преобразования; убрать типа дата.

(1) Замеры времени. Поднятие БСП до 2.4.4
(9) Вопрос именно в том, как наименее болезненно провести реструктиризацию. База сверхгигантская.
Вариант со скюлем понравилсся. Но, блин, я не админ их скюля. Придется договариваться.

(11) Ну так лишний реквизит тоже потом убрать надо будет.

(12) договоритесь до того, что не нужны вам эти замеры :)

в новой БСП, кстати, есть задание, удаляющее исторические данные замеров

(10) А там, кстати, не юникстайм. Там именно миллисекунды с Дата(1,1,1). текущаяуниверсальнаядатавмиллисекндах() это именно оно. Не спрашивайте меня, почему.)

(14) Скорее решат, что я не нужен.)

(10) Ага, ждите, щас, я вам тут всю функцию писать буду :) Лениво же :(

в скуле скопируй колонку таблицы, заполни, после обновления переименуй

(16) тогда правильная

(19) А при рестуктуризации же колонка слетит. Только если таблицу всю скопировать, а потом вернуть преобразованную.

Ну, короче, я понял, что неожиданно легкого пути нет, как и ожадалось. Пойду гонять на копии прода различные варианты, какой менее убоен.)

(22) и все-таки попробуй (14)

и очисти РС перед обновлением

(24) Да, я прихожу к выводу, что выгрузить все, очистить регистр, а потом постепенно подгружать то, что нужно.

(25) тут есть промежуточный, но очень важный этап - случайно потерять выгруженные данные.

при этом этап выгрузки можно даже пропустить

(13) "Ну так лишний реквизит тоже потом убрать надо будет." - ёпрст:) Добавить нужно не реквизит, а тип(!) - т.е. существующие измерение регистра нужно сделать составного типа.

Тогда можно будет читать записи; преобразовывать значение и записывать запись - редактирование в один проход всех записей регистра.

(28) Ну, не в данном случае. Составное индексное поле в этом случае может привести к не лучшим последствиям "между релизами".

Ну, как бы "да", но это мелочи - если выбирать между двумя или тремя релизами :)