1С PostgreSQL error: column “q_001_f_000_” does not exist

Как-то раз, ни с того, ни с сего, вылезло вот такое г*внище при попытке выгрузки (очередным регламентным заданием) из базы УТ (11.4.3.137) в БП (3.0.60.46) (с базой накануне ничего не делали):
Ошибка СУБД:
ERROR:  column "q_001_f_000_" does not exist
LINE 2: CASE WHEN Q_001_F_000_ IS NULL THEN ((((T1.SDBL_DECOMP_19_ |...

 
Система Debian 9 64-bit, 1С 32-bit 8.3.12.1440, Postgresql 9.6.8. 
При чем с другой такой же базой УТ обмен проходит нормально.
Обмен у нас настроен через FTP-каталог и .xml файлы.
 
Т.к. видно, что проблема заключается в каком-то косяке клиент-серверного режима (а точнее в связке 1С-postgresql) при формировании данных для обмена, то было принято решение выгрузить данные из УТ, когда она будет запущена в ФАЙЛОВОМ режиме.
 
0) Останавливаем фоновую синхронизацию (отключаем регламентное задание) в УТ и БП:
0.1) в УТ убираем галочку включено в НСИ и администрирование -> Обслуживание -> Регламентные и фоновые задания -> “Выполнение обмена по сценарию: Сценарий синхронизации для Бухгалтерия предприятия, редакция 2.0” (почему 2.0, уже давно никто не помнит, если и знали)
0.2) в БП убираем галочку включено в Администрирование -> Обслуживание -> Регламентные и фоновые задания -> “Выполнение обмена по сценарию: Сценарий синхронизации для Управление торговлей, редакция 11.1”
 
1) Выгружаем данные из УТ
1.1) выгружаем базу УТ в .dt
1.2) загружаем полученный .dt в только что созданную файловую базу
1.3) запускаем файловую базу
1.4) выбираем “Это копия информационной базы”
1.5) настраиваем синхронизацию отдельно в локальный каталог (в .xml файл) (в моем случае обмена через FTP можно оставить как есть)
1.6) запускаем синхронизацию
1.7) если все прошло успешно, будет сформирован .xml (в данном случае Message_ЦБ_БП.xml)
 
2) Подготавливаем номера сообщений
2.1) файловая УТ база уже не нужна, возвращаемся обратно в исходную
2.2) Номера принятых и отправленных сообщений должны совпадать в двух базах (перекрестно, разумеется). Но для того, чтобы УТ поняла, что накопленные данные она уже выгрузила (и они исчезли из состава отправляемых данных), и БП поняла, что новая порция данных из УТ готова к загрузке, нужно чтобы номер ОТПРАВЛЕННОГО сообщения в УТ был на 1 больше (в базе и в .xml). На дворе 21 век, и 1С уже сама заранее посчитала номер сообщения (195767+1=195768), в котором планировала (и уже пыталась) выгрузить накопившиеся данные, и показала нам (столбец № отправленного, который я выделил).
 
В УТ номера сейчас такие:
 
В БП такие же:
 
2.3) Увеличиваем номер отправленного сообщения в УТ (жмакаем на надписи и появляется волшебное окошко)
 
2.4) Убеждаемся, что в сформированном .xml стоят правильные номера:
<msg:MessageNo>195768</msg:MessageNo>
<msg:ReceivedNo>197139</msg:ReceivedNo>
 
3) Загружаем данные в БП
3.1) запускаем синхронизицию в БП. У нас при этом вываливается окошко “Нет соответствия …”. Ничего страшного, все идет по планууууу, жмем Далее.
 
4) Проверяем выгрузку из УТ в клиент-серверном режиме (не обязательно)
Т.е. можно запустить синхронизацию в УТ, чтобы проверить, что дальше она пойдет нормально.
 
5) Обратно включаем фоновую синхронизацию в 2-х базах
 
UPDATE 17.07.2018:
За 2,5 недели эта ошибка вылезла уже в 3й раз. На сайте 1С в списке публикаций ошибок для новой платформы эту ошибку я что-то не нашел (хотя нашел исправленные другие, хе-хе). Планируем обновляться на выходных, т.е. в очередной раз попытаемся вылечить найденные косяки, и конечно же получить НОВЫЕ!!!

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *