скрытые "лишние" поля таблицы в MS SQL и PG в документе которых нет в конфигураторе

Форум Администрирование Обновление конфигураций (UpdateCF)

1С:Бухгалтерия 3.0 Платформа 1С v8.3 Программист Вопрос Исследование

1. trupo 17.01.20 16:29 Сейчас в теме

После установки расширения в БП 3.0 на 8.3.14 (с добавлением 5 реквизитов документа) появились в SQL в структуре базы в документе "лишних" 5 полей (кроме тех, что в расширении), которых быть не должно. Как появились - не уловили момент. На тестовой копии, те же манипуляции таких полей не создали.
Эти поля не имеют синонимов и сопоставлений с конфигурацией или расширением. НО записать новый или перезаписать старый документ не дают, т.к. не допускают свойство NULL. Реструктуризация добавление/удаление других реквизитов, удаление расширений ситуацию не меняют. Выгрузка-загрузка dt ситуацию не меняют.
В итоге - есть две базы с идентичными cf (уже без расширений), но отличающиеся количеством полей в документе в базе (но не в конфигураторе)! Загрузка конфигураций из "хорошей" базы "лишние поля в SQL не убрала. Т.е. конфигурация этих "лишних" полей не видит (как кстати не видит всех полей расширения). Расширение этих "лишних" полей тоже не видит. Эти поля невидимы для Конфигуратора вообще. Но при перезаписи любого документа (этого вида) SDBL не может затолкнуть туда NULL. Интересно? мне очень.
Снижение релиза до 8.3.12 и повторения выгрузки/загрузки, тестирования с исправлением базы, загрузки конфигурации без объединения ничего не дало.
Есть мысль, что это результаты "оптимизации" и ускорения процедуры Реструктуризации базы от 1С реализованной в 11 релизе платформы.
А что "помогло"? В "плохой базе" создание узла в полном плане обмена и выгрузка всех документов. В новом узле структура нормальная и "лишних" полей нет - документы записываются. Но нам нужна текущая база с всеми текущими данными настроек сдачи отчётности и всеми данными, а в новый узел не переезжают некоторые доработанные документы, справочники и настройки.
Вопрос открыт КАК СДЕЛАТЬ ПОЛНУЮ РЕСТРУКТУРИЗАЦИЮ с удалением "лишних" колонок?
PS руками и средствами SQL их удалить можно, но при записи документа SDBL их требует (!)

Прикрепленные файлы:

Вознаграждение за ответ

Сумма: 0.04 $m

Добавили:
trupo (0.04 $m)

Показать полностью

Ответы

Подписаться на ответы Инфостарт бот

Свернуть все

12. starik-2005 3036 20.01.20 14:30 Сейчас в теме

(1)

PS руками и средствами SQL их удалить можно, но при записи документа SDBL их требует (!)

Зайти в конфигуратор, зайти в SQL, удалить в SQL эти поля, добавить реквизит в конфигураторе, применить изменения. Посмотреть, что стало с полями в SQL.

13. trupo 20.01.20 17:22 Сейчас в теме

(12) в SQL удалял эти поля, а в конфигураторе добавлял новые реквизиты. Всё отрабатывает, новые поля, добавленные в конфигураторе - появляются, удалённые в структуре пропадают. Но при записи документа опять ошибка SDBL что-то типа отсутствует поле то самое "лишнее" которое я удалил в SQL руками.

18. starik-2005 3036 20.01.20 17:40 Сейчас в теме

(13) в каких словах Ваш ответ согласуется с моим предложением? 1С при применении изменений в конфигураторе создает после удаления полей в SQL эти поля? Или что?

23. trupo 23.01.20 19:29 Сейчас в теме

(18) 1С один единственный раз (не замеченный мной) создала эти поля. Вероятно это было сразу после установки расширения. Теперь, эти поля не видятся, не удаляются из конфигуратора из основной конфигурации и из расширения и при удалении расширения и при удалении всех реквизитов документа которые можно удалить из конфигуратора. При удалении руками в SQL эти поля не восстанавливаются больше. Но при записи документа возникает ошибка SDBL в которой пишется, что невозможно найти первое из удалённых полей и запись не проходит. Уже эта ошибка, не лечится ни реструктуризациями не загрузкой конфы из базы, в которой таких полей вообще никогда не было.

22. trupo 23.01.20 19:21 Сейчас в теме

(12) Именно в такой последовательности делали. Поля лишние удалить можно. И после этого в конфигураторе добавлять, удалять, и загружать cf из хорошей базы делали. Но при записи документа SDBL требует первое из этих удалённых полей. т.е. Конфа о них уже не знает, отладчик проблем не видит. А запись не проходит из-за ошибки SDBL, - не найдено поле "_Fld..."первое из удалённых. Где записано что это поле вообще было - я не нашёл, но это точно не в cf-нике.

2. aka Любитель XML 17.01.20 16:38 Сейчас в теме

База сильно большая? может попробовать в идентичную выгрузить обработкой с ИТС?

5. trupo 17.01.20 16:47 Сейчас в теме

"Выгрузка и загрузка данных XML"? попробую в ночь - отпишусь

6. aka Любитель XML 17.01.20 17:34 Сейчас в теме

(5) такого опыта нет. Поэтому и задал вопрос - большая ли БД. Я бы попробовал взять конфу которая получилась обменом, и в нее догрузить этой обработкой нужные данные. Не факт что получиться все верно, но попробовать есть смысл

3. trupo 17.01.20 16:42 Сейчас в теме

около 60 Гиг Какой обработкой? просветите плиз. Она все данные переливает или есть ограничения?

4. Pacmanius 17.01.20 16:46 Сейчас в теме

(3)ВыгрузкаЗагрузкаXML... Но 60 Гигов сомнительная затея

7. aka Любитель XML 17.01.20 17:34 Сейчас в теме

Ну и в 1с еще можно задать вопрос, не факт правда что помогут.

8. aka Любитель XML 17.01.20 17:42 Сейчас в теме

Мысли вслух: Ну и почему на копии не попробовать грохнуть лишнии поля прямо в БД? Сделать проверку средствами sql, посмотреть результат.

14. trupo 20.01.20 17:25 Сейчас в теме

(8)в SQL удалял эти "лишние" поля, а в конфигураторе добавлял новые реквизиты. Всё отрабатывает, новые поля, добавленные в конфигураторе - появляются, удалённые в структуре пропадают. Но при записи документа опять ошибка SDBL что-то типа отсутствует поле то самое "лишнее" которое я удалил в SQL руками.
Т.е. с "лишними" полями SDBL ругается, что они не могут принимать NULL, а без них, что отсутствует поле первое из них. (ругается по имени поля в SQL)

16. aka Любитель XML 20.01.20 17:29 Сейчас в теме

(14) а нет возможности разрешить этим полям принимать null средствами sql?

21. trupo 23.01.20 19:14 Сейчас в теме

(16) Была такая мысль у одного нашего разработчика. Но мне показалось что это не нормально. А вдруг после выгрузки и загрузки из dt эти таблицы снова не станут принимать NULL и опять та же проблема, и так на всегда?

24. trupo 23.01.20 19:30 Сейчас в теме

(8)

Сделать проверку средствами sql

уточните плиз, какую проверку сделать средствами SQL?

9. Fuego 462 20.01.20 10:20 Сейчас в теме

Это не общие реквизиты? Не проверял, не знаю тонкости их работы, но предположил, что они непременно должны создавать поля в каждой конкретной физической таблице

11. starik-2005 3036 20.01.20 11:26 Сейчас в теме

(9) да, общие реквищиты создают в каждой таблице (в выбранных) поля с идентичным именем (флдхххх). Но они должны быть общими, и они имеют псевдоним при получении структуры базы.

15. trupo 20.01.20 17:28 Сейчас в теме

(9) Нет не общие реквизиты. Две базы с ОДИНАКОВЫМ cf т.е. с одинаковыми общими и другими реквизитами отличаются количеством полей в структуре таблиц на SQL. "Лишние" поля таблицы не имеют Синонимов.

10. starik-2005 3036 20.01.20 11:24 Сейчас в теме

Ну так грохни эти колонки через скул - че мучаешься?

17. trupo 20.01.20 17:30 Сейчас в теме

(10) в SQL удалял эти "лишние" поля. Но при записи документа опять ошибка SDBL что-то типа отсутствует поле - то самое первое "лишнее" которое я удалил в SQL руками.
Т.е. с "лишними" полями SDBL ругается, что они не могут принимать NULL, а без них - SDBL ругается что отсутствует поле первое из них. (ругается по имени поля в SQL). Отладчик и язык 1С не ругаются для них всё ок.

19. user755071 22.01.20 10:38 Сейчас в теме

(17) Кеш на локальном компьютере после удаления ручками лишних полей из SQL чистили?

20. trupo 23.01.20 19:11 Сейчас в теме

(19) Кэш чистили всеми способами. И сразу после удаления в SQL тоже.

25. Fox-trot 157 23.01.20 19:41 Сейчас в теме

(20) а реструктуризация не помогла?

26. trupo 01.03.20 21:58 Сейчас в теме

(25) Не помогла ни одна из более 10 вариантов (обычная, после добавления новых тестовых полей, после их удаления, после удаления полей в SQL и ну и т.п.).

Оставьте свое сообщение

E-mail: