Имя: Пароль:
1C
1С v8
Ошибка SDBL при обновлении БП 3.0.64.54 => 3.0.65.80 на платформе 8.3.12.1595
,
0 jk3
 
11.10.18
17:09
Для начала, сразу скажу, что ТИИ базы со всеми галками до обновления сделано, ошибок не выдает.
Конфа БП 3.0.64.54 полностью типовая.

cfu встает без проблем, конфа сохраняется, изменения применяются по F7 успешно.

Потом при обновлении в режиме предприятия падает вот так:

    {Справочник.ИдентификаторыОбъектовМетаданных.МодульМенеджера(1713)}: Ошибка при вызове метода контекста (Записать)
                ТаблицаОбъект.Записать();
    по причине:
    Ошибка при выполнении обработчика - 'ПередЗаписью'
    по причине:
    {ОбщийМодуль.СтандартныеПодсистемыСервер.Модуль(902)}: Ошибка при вызове метода контекста (Добавить)
                Объект.ОбменДанными.Получатели.Добавить(Получатель);
    по причине:
    Несоответствие типов (параметр номер '1')


Это Процедура ЗарегистрироватьОбъектНаВсехУзлах(Знач Объект, Знач ИмяПланаОбмена, Знач ВключаяГлавныйУзел = Истина) Экспорт

Падает при ИмяПланаОбмена = "Полный".
Если ИмяПланаОбмена = "АвтономнаяРабота", то проходит без проблем.

Код процедуры такой:

        ТекстЗапроса =
        "ВЫБРАТЬ
        |    ПланОбмена.Ссылка КАК Получатель
        |ИЗ
        |    ПланОбмена.[ИмяПланаОбмена] КАК ПланОбмена
        |ГДЕ
        |    ПланОбмена.Ссылка <> &ЭтотУзел
        |    И НЕ ПланОбмена.ПометкаУдаления";
        
        ТекстЗапроса = СтрЗаменить(ТекстЗапроса, "[ИмяПланаОбмена]", ИмяПланаОбмена);
        
        Запрос = Новый Запрос;
        Запрос.УстановитьПараметр("ЭтотУзел", ПланыОбмена[ИмяПланаОбмена].ЭтотУзел()); // возвращает Неопределено, хотя должно возвращать ссылку на предопределенный элемент плана обмена
        Запрос.Текст = ТекстЗапроса;
        
        Получатели = Запрос.Выполнить().Выгрузить().ВыгрузитьКолонку("Получатель");
        
        ГлавныйУзел = ПланыОбмена.ГлавныйУзел();
        
        Для Каждого Получатель Из Получатели Цикл
            Если Не ВключаяГлавныйУзел И Получатель = ГлавныйУзел Тогда
                Продолжить;
            КонецЕсли;
            Объект.ОбменДанными.Получатели.Добавить(Получатель); // падает здесь
        КонецЦикла;


Если в отладчике попробовать получить значение переменной Получатель, возвращает "Ошибка SDBL: Таблица или поле ID не содержится в разделе FROM".

Эту ошибку можно обойти в отладчике, заменив значение ИмяПланаОбмена = "Полный" на "АвтономнаяРабота" в начале процедуры.

Но потом после того как обновление установится, при попытке сделать ТИИ с галкой "проверка логической целостности" сразу выдается ошибка в виде предупреждения и ТИИ останавливается:

    Microsoft SQL Server Native Client 11.0: Нарушено "PK___tmpRCT__80E37C38266317B0" ограничения PRIMARY KEY.
    Не удается вставить повторяющийся ключ в объект "dbo._tmpRCT".
    Повторяющееся значение ключа: (0x0000001b).
    HRESULT=80040E2F, SQLSrvr: SQLSTATE=23000, state=1, Severity=E, native=2627, line=1


Т.е. фактически на выходе получаем битую базу.
1 МихаилМ
 
11.10.18
17:27
поняли. а что хотели? предупредть ?
2 jk3
 
11.10.18
17:32
(1) Что делать чтобы обновилось без этой ошибки?

Всё делал на тестовой базе.
Рабочую, естественно, оставил пока на релизе 3.0.64.54.
Но рано или поздно придётся обновлять, а тут такая Ж.
Может быть кто-то уже столкнулся с тем же самым и смог победить.
3 Amra
 
11.10.18
17:33
Более свежий релиз платформы попробуй, из 12ых
4 dka80
 
11.10.18
17:34
(2) вы не первый, кто жалуется на ошибки при переходе на этот релиз. Поэтому лучше переждать
5 jk3
 
11.10.18
17:39
Да, забыл уточнить, что никакого РИБ в помине нет. Это одиночная база.
6 jk3
 
11.10.18
17:41
(3) Я понимаю, что это баг платформы, а не конфы.

Из более свежих только 2 версии 8.3.12.1616 и 8.3.12.1685.
В описании исправленных багов нечто отдаленно похожее нашёл, но не совсем оно:

При выполнении тестирования и исправления информационной базы, в которой определены разделители, при тестировании служебных таблиц некоторых объектов может происходить ошибка вида Ошибка SDBL: таблица или поле Fld2683 не содержится в разделе FROM (pos=7)

Исправлена: "Технологическая платформа", версия 8.3.12.1685
7 VladZ
 
11.10.18
17:41
(0) Последнюю платформу (8.3.13) не пробовал ставить?
8 jk3
 
11.10.18
17:46
(7) Я таким экстримом не занимаюсь))
Обновляю платформу только по надобности и не на самый последний релиз.
9 elCust
 
11.10.18
17:54
Файловая без ошибок обновилась на 3.0.65.80.
Правда пустая.

Платформа 8.3.12.1616.
10 jk3
 
11.10.18
17:57
(9) Демо-база БП у меня без ошибок обновилась до 3.0.65.80 на платформе 8.3.12.1595.
А вот копия реальной базы -- фиг.
11 МихаилМ
 
11.10.18
21:13
(10) значит ТЖ в руки и исправляйте ошибку.
12 jk3
 
14.10.18
23:26
Та же самая ошибка на последней платформе 8.3.13.1513.

(11) Как надо настроить тех.журнал, чтобы попытаться самостоятельно отловить ошибку?
13 hhhh
 
14.10.18
23:40
(12) всё ж таки проверьте планы обмена. наверняка левый узел там кто-то создал.
14 MSOliver
 
15.10.18
04:32
Ошибка зарегистрирована?
15 jk3
 
15.10.18
10:21
(13) Это я первым делом проверил.
В плане обмена "Полный" только один предопределенный элемент без кода, наименования, т.е. который не использовался никогда.
По остальным планам обмена на всякий случай тоже посмотрел.
У всех остальных, кроме 3-х (ниже), точно такая же картина с одним предопределенным элементом.
"Обновление информационной базы" -- кроме предопределенного еще 5 обычных элементов.
"Синхронизация данных через универсальный формат" -- 2 элемента: один предопределенный и еще один обычный элемент.
"Управление торговлей, редакция 11" -- 2 элемента: один предопределенный, а второй помечен на удаление.
16 jk3
 
15.10.18
10:21
(14) Еще в субботу написал на v8, но, такое ощущение, что по выходным они почту не обрабатывают.
17 jk3
 
15.10.18
10:44
Только вот сейчас ответили "Ваше письмо будет рассмотрено в ближайшее время".
18 hhhh
 
15.10.18
10:55
(15) ну вот, тот что помечен на удаление, удалите нахрен. Бывших узлов не бывает.
19 MSOliver
 
16.10.18
07:25
Я обновился без проблем.
20 jk3
 
16.10.18
10:06
(18) Его невозможно удалить, на него куча ссылок, т.к. раньше до EnterpriseData этот обмен использовался.
Да и я думаю он никак не влияет, какой-то косяк с планом обмена Полный, а не с ним.
21 jk3
 
16.10.18
10:06
(19) Поздравляю!
А мне даже еще не ответили в какую сторону хотя бы копать.
22 hhhh
 
16.10.18
10:08
(20) вот именно он и влияет. Так что тянуть с удалением нет смысла.
23 vladko
 
16.10.18
10:46
Обновил в выходные типовую рабочая базу. Без проблем обновилась и работает на рекомендованной платформе 8.3.12.1529 (правда в базе не используются синхронизации)
24 Naumov
 
16.10.18
12:12
(23) У пользователей с ограниченными правами при поиске в динамическом списке (например в документах реализации) ошибок не возникает?
25 El_Duke
 
гуру
16.10.18
12:45
(21) Ответили, ты не захотел увидеть
В (3) этот ответ прозвучал. Я на платформе 8.3.12.1685 обновился успешно, только долго адски
26 crotnn
 
16.10.18
12:47
(21) У меня при запуске самописки на 8.3.12 в планах обмена самопроизвольно очистились значения реквизита "ЭтотУзел" у всех узлов всех планов обмена, и тоже посыпались ошибки. После "ручной" установки значений все заработало. Проверь на всякий случай.
27 jk3
 
16.10.18
14:22
(25) Пробовал на платформах 8.3.12.1595, 8.3.12.1685, 8.3.13.1513 -- результат одинаковый как в (0)
28 jk3
 
16.10.18
14:23
Попробовал выгрузить базу в dt-файл и загрузить обратно. Не помогло.
29 jk3
 
16.10.18
14:25
(26) А как это сделать?
После наката обновления по F7 и старта базы как-то можно отказаться от запуска обновления в предприятии?
30 1c_asadi
 
16.10.18
14:29
(0) Попробуй запустить тестирование(без исправления) с 4я первыми галками сразу после завершения обновления в конфигураторе, была такая беда с типовой - помогло.
31 jk3
 
16.10.18
14:43
(26) В окне "Не удалось выполнить обновление" есть кнопка Еще - Открыть внешнюю обработку.
Запустил внешнюю обработку с таким кодом:
Сообщить(ПланыОбмена.Полный.ЭтотУзел().ЭтотУзел);
Выдает "Да".
Т.е. значение реквизита не слетело.
32 Naumov
 
16.10.18
14:45
(29) Нет, после наката только из архивной копии
33 crotnn
 
16.10.18
14:51
(31) я бы и остальные планы обмена так проверил, не только полный. Ведь в (0) явно ошибка в каком-то узле обмена. В крайнем случае попробовать на копии удалить все узлы обмена с отключенным контролем целостности и попробовать обновиться.
34 jk3
 
16.10.18
15:25
(30) Попробовал.
Если сразу после завершения обновления в конфигураторе запустить ТИИ (т.е. даже без запуска предприятия), то вываливается с сообщением, описанным в (0)
Microsoft SQL Server Native Client 11.0: Нарушено "PK___tmpRCT__80E37C38266317B0" ограничения PRIMARY KEY.
    Не удается вставить повторяющийся ключ в объект "dbo._tmpRCT".
    Повторяющееся значение ключа: (0x0000001b).
    HRESULT=80040E2F, SQLSrvr: SQLSTATE=23000, state=1, Severity=E, native=2627, line=1

Т.е. до обновления ТИИ проходит без ошибок, после обновления в конфигураторе -- база поломанная. Релиз платформы последний. Фирма 1С молчит как партизан.
35 Bony-andrey
 
16.10.18
15:44
У меня было слегка похожая ситуация при переходе БП 2.0 -> 3.0

Таблица была "dbo._AccRgAT2486", SQL ругался на неуникальность конкретного индекса. В Management Studio я временно разрешил этому конкретного индекса пропускать повторяющиеся значения,а после выполнения всех процедур обратно запретил.

Но что за таблица "dbo._tmpRCT"?
36 1c_asadi
 
16.10.18
15:57
(34) вышел еще 84 релиз БП мож там поправили,как вариант попробуй в файловый вариант сконвертить и там обновить
37 jk3
 
16.10.18
17:40
(35) При ТИИ создается такая таблица в скулевской базе:
CREATE TABLE [dbo].[_tmpRCT](
    [TabID] [binary](4) NOT NULL,
PRIMARY KEY CLUSTERED
(
    [TabID] ASC
)WITH (PAD_INDEX = OFF, STATISTICS_NORECOMPUTE = OFF, IGNORE_DUP_KEY = OFF, ALLOW_ROW_LOCKS = ON, ALLOW_PAGE_LOCKS = ON) ON [PRIMARY]
) ON [PRIMARY]

И даже данные в ней есть, 1189 строк.
0x0000001B -- строка с таким значением есть.
Хз почему пытается вставить в эту таблицу еще одно такое значение. Естественно, скуль не даёт это сделать.
38 jk3
 
16.10.18
17:42
(36) Попробовал накатить 3.0.65.84 релиз. Ошибка та же.
39 jk3
 
16.10.18
17:56
При ТИИ базы до обновления в таблице _tmpRCT это значение 0x0000001B так же есть, но количество строк в таблице 1268 (больше).
Т.е. получается на базе после обновления спотыкается на дублирующимся ключе и недозаполняет таблицу.

Где хранится обратная связь ID таблиц с человеческим наименованием?
Чтобы хотя бы попытаться понять что где задублировалось при обновлении.
40 1c_asadi
 
17.10.18
07:49
(39)для таких целей писал обработку, если нужна напиши почту - скину
https://cloud.mail.ru/public/DTQ1/B9ZWfDtnW типо так умеет
41 jk3
 
17.10.18
14:44
(40) Спасибо, кончено, но это немного не то.
Значения в таблице _tmpRCT:
0x00000008
0x0000000A
0x0000000B
...
0x0000001A
0x0000001B
0x0000001C
..
0x000078B4
0x000078B5

Т.е. какой-то внутренний ID таблицы, а не её имя.
Но количество строк странное.
Чуть больше 1 тыс. даже в нормальной базе, хотя таблиц в базе больше 5 тыс.
42 МихаилМ
 
17.10.18
15:10
с помощью ddl триггера отключите  индекс
43 jk3
 
17.10.18
23:30
(33) >я бы и остальные планы обмена так проверил, не только полный
Вот такой код выдает "Да" и в битой базе после обновления, и в нормальной до обновления:
    Для Каждого ТекПланОбмена Из Метаданные.ПланыОбмена Цикл
        Сообщить(ТекПланОбмена.Имя + " = " + ПланыОбмена[ТекПланОбмена.Имя].ЭтотУзел().ЭтотУзел);
    КонецЦикла;
44 jk3
 
19.10.18
11:07
Выяснил, то ошибка с PRIMARY KEY воспроизводится даже на релизе 3.0.64.54, если включить возможность изменений и поменять режим совместимости 8.3.10 => 8.3.12.
При этом реструктуризации подвергаются объекты:

    Новый объект: Хранилище расширений конфигурации (новое поколение данных)
    Новый объект: Хранилище информации о применении расширений конфигурации к базе данных
    Новый объект: Хранилище информации о применении расширений конфигурации к базе данных (новое поколение данных)
    Объект изменен: Хранилище расширений конфигурации
    Объект изменен: ПланОбмена.АвтономнаяРабота
    Объект изменен: ПланОбмена.МиграцияПриложений
    Объект изменен: ПланОбмена.МобильнаяБухгалтерия
    Объект изменен: ПланОбмена.МобильноеПриложениеПредприниматель
    Объект изменен: ПланОбмена.Обмен1С_КАМИН_ЗарплатаБухгалтерия30
    Объект изменен: ПланОбмена.ОбменЗарплата3Бухгалтерия3
    Объект изменен: ПланОбмена.ОбменРозница1Бухгалтерия3
    Объект изменен: ПланОбмена.ОбменРозницаБухгалтерияПредприятия30
    Объект изменен: ПланОбмена.ОбменСообщениями
    Объект изменен: ПланОбмена.ОбменСПодключаемымОборудованиемOffline
    Объект изменен: ПланОбмена.ОбменУправлениеНебольшойФирмойБухгалтерия30
    Объект изменен: ПланОбмена.ОбменУправлениеТорговлей103БухгалтерияПредприятия30
    Объект изменен: ПланОбмена.ОбменУправлениеТорговлейБухгалтерияПредприятия30
    Объект изменен: ПланОбмена.ОбновлениеИнформационнойБазы
    Объект изменен: ПланОбмена.Полный
    Объект изменен: ПланОбмена.ПоОрганизации
    Объект изменен: ПланОбмена.СинхронизацияДанныхЧерезУниверсальныйФормат
    Объект изменен: ПланОбмена.УдалитьОбменРозницаБухгалтерия20
    Объект изменен: ПланОбмена.УдалитьОбменРозницаБухгалтерияПредприятия
    Объект изменен: ПланОбмена.УдалитьОбменУправлениеНебольшойФирмойБухгалтерия20
    Объект изменен: ПланОбмена.УдалитьОбменУправлениеТорговлейБухгалтерияКОРП
    Объект изменен: ПланОбмена.УдалитьОбменУправлениеТорговлейБухгалтерияКОРПФоновый
    Объект изменен: ПланОбмена.УдалитьОбменУправлениеТорговлейБухгалтерияПредприятия
    Объект изменен: ПланОбмена.УдалитьПолный
    Объект изменен: ПланОбмена.УдалитьПоОрганизации
    Изменена версия структуры информационной базы

Как раз в следующем за релизом 3.0.64.54 в релизе 3.0.65.69 и меняется режим совместимости.

Но так пока что и не ясно как починить базу до обновления, чтобы изменение режима совместимости при накатывании следующего релиза не ломало базу.
45 jk3
 
19.10.18
11:43
При возврате режима совместимости 8.3.12 => 8.3.10 ТИИ ошибок не выдает... хм.
46 МихаилМ
 
19.10.18
12:14
(44)
"как починить базу.."
либо исправить исходные данные, приводящие к ошибке.

либо созданные.

первое решается путем расследования тж либо трасс ms sql profiler на предмет , откуда 1с8 берет данные для таблицы с последующим исправлением.
второе - отключением индекса при создании таблицы, удаления дублей, создание индекса.
47 jk3
 
21.10.18
18:42
Выяснил, что планы обмена изменяются при включении режима совместимости 8.3.11.
Т.е. если включить возможность изменений и просто изменить режим совместимости конфигурации с 8.3.10 на 8.3.11 то баг с ТИИ воспроизводится.
При откате обратно на 8.3.10 бага при ТИИ нет.

Методом последовательного удаления планов обмена из конфигурации выяснил, при снятии с поддержки и удалении только 1 плана обмена УдалитьОбменРозницаБухгалтерия20 баг с ТИИ пропадает.
Т.е. после последующего обновления без этого плана обмена до версии 3.0.65.69 ТИИ базы проходит успешно.

Но проблема обновления в предприятии, описанная в (0), всё еще остается.
48 jk3
 
23.10.18
23:39
(33) >В крайнем случае попробовать на копии удалить все узлы обмена с отключенным контролем целостности и попробовать обновиться.

Удалил обработкой все непредопределенные элементы всех планов обмена (у которых свойство ЭтотУзел = Ложь) перед обновлением.
Та же ошибка после обновления при обработке данных в предприятии.
49 jk3
 
25.10.18
16:31
(36) >как вариант попробуй в файловый вариант сконвертить и там обновить

На файловой базе та же ошибка.
ТИИ и chdbfl и до, и после(!) обновления рапортуют, что проблем нет.

При этом, если при появлении ошибки обновления в предприятии открыть обработкой элемент плана обмена Полный и попробовать записать -- вываливается в ошибку SDBL.
50 jk3
 
31.10.18
23:41
Ответ поддержки 1С, цитата:

Проблема возникает, если загрузить dt сформированной более новой версией (в более новом режиме совместимости). Теперь при попытке загрузить такой dt возникает ошибка. Базы, сформированные такой загрузкой ранее некоректны и с ним работать не получится. Исправление на них не влияет.

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

Если это не так, то следует прислать dt вашей базы, сделанные до обновления и на платформе 8.3.10

Помогите перевести этот ответ на русский.
Что надо сделать?

P.S. Я им отправлял .bak-файл MSSQL-бэкапа текущей базы до обновления.
51 jk3
 
09.11.18
11:44
Новости с полей: "Ваше сообщение зарегистрировано для расследования в отделе разработки <номер>".
52 Mankubus
 
21.11.18
11:26
(51) не удалось решить проблему?
53 jk3
 
30.11.18
16:20
(52) Прошло 3 недели, ответа от отдела разработки 1С нет.
Напомнил им сегодня о себе.
Посмотрим на следующей неделе что ответят.
54 jk3
 
19.12.18
22:39
Обновляю статус.
Ошибка зарегана 09.11.2018, но в ближайшее время исправлять её никто не собирается.
https://bugboard.v8.1c.ru/error/000048134.html
Как сдавать 4-й квартал без обновлений, хз.
Пока ждал, вышли релизы платформы:
8.3.13.1644   28.11.18    
8.3.12.1790   27.11.18  
Надо будет попробовать еще на них обновиться.
Имхо, какой-то косяк в платформе, я в этом уверен на 99,9%.
55 ЧессМастер
 
25.12.18
14:58
(50) "Вам необходимо загрузить базу на том релизе платформы, на котором она была сделана. После этого уже выполнять обновление платформы и обновление."

Писец. Просто нет слов.

"Я им отправлял .bak-файл MSSQL-бэкапа текущей базы до обновления."

То есть по факту слить базу. На такое никто в здравом уме разрешения не даст.
56 ЧессМастер
 
25.12.18
15:00
(51) А вариант создать пустую базу из шаблона конфигурации и перелить туда все данные через выгрузку-загрузку через XML не рассматривали ? И на новой базе уже проводить обновление.
57 shuhard
 
25.12.18
15:08
(55)[То есть по факту слить базу. На такое никто в здравом уме разрешения не даст.]
ты бредишь и тяжело, не запуская болезнь
58 ЧессМастер
 
25.12.18
15:13
(57) Если ты один айтишник который обслуживает организацию и о твоей идее слить базу куда-то (пусть и с целью починить) никто не узнает то можешь делать что угодно.

Я при приеме на работу подписывал бумаги за сохранность коммерческой тайны. И без письменного разрешения начальника отдела ИТ сливать базу куда-то рискуя уголовкой не собираюсь. И начальник отдела тоже в таком случае захочет прикрыть свой зад бумажкой.
59 jk3
 
04.01.19
10:12
В общем, исправления бага я так и не дождался, решил проблему обновления в предприятии правкой кода:
ОбщийМодуль.СтандартныеПодсистемыСервер
Процедура ЗарегистрироватьОбъектНаВсехУзлах()
            Если ПланыОбмена[ИмяПланаОбмена].ЭтотУзел() = Неопределено Тогда
                Возврат;
            КонецЕсли;

И благополучно обновился до последнего релиза.
ТИИ с исправлением ссылок так и не запускается с ошибкой PRIMARY KEY, но, я думаю, что это ошибка в платформе и когда-нибудь она сама пропадет.
60 jk3
 
05.01.19
22:23
У этой истории неожиданно появилось продолжение.
При попытке загрузки данных из УТ:
Ошибка SDBL:
Ссылочная константа содержит недопустимый ссылочный номер таблицы
61 jk3
 
05.01.19
22:25
(56) Видимо, придётся воспользоваться вашим советом.
Никогда таким не занимался, чтобы перенести все данные из базы в пустую базу.
Подскажите, как это сделать?
62 sergey yevsenya
 
05.01.19
22:36
столкнулся с похожей ошибкой при обновлении УТ11. Помог откат на 8.3.10, ТИИ (вроде можно только реструктуризацию, но сделал полностью) и обновление на этой платформе
63 ЧессМастер
 
09.01.19
09:17
(61) Создаете пустую базу из шаблона релиза такого же что и ваша база. Если такого шаблона нет то берете ближайший до этого шаблон и накатываете на него обновления пока не получите базу того же релиза. Если у вас есть изменения в метаданных (как у меня например в справочник контрагентов и договоров добавлены несколько реквизитов) то включаете возможность изменения и добавляете.

Обязательное условие - конфигурация по метаданным должна совпадать. Иначе выгрузка - загрузка через XML не пройдет.

После этого обработкой ВыгрузкаЗагрузкаДанныхXML выгружаете все данные из баз источника. Я делаю "все контатанты, все справочники, все документы с движениями". Плюс надо будет дополнительно перенести независимые регистры сведений (по которым движения без регистраторов).


Если во время выгрузки будет происходить ошибка на каких то объектах то просто снимаете галочку на объектах этого вида.
64 ЧессМастер
 
09.01.19
09:21
(60) (62)
Какую у вас ошибку выдавало ТИИ с реструктуризацией ?

У меня возникали ошибки типа

"В процессе обновления информационной базы произошла критическая ошибка
по причине:
В схеме базы данных отсутствует таблица "Reference39".

В процессе обновления информационной базы произошла критическая ошибка
по причине:
Ошибка SDBL:
Ссылка на таблицу Reference39 недопустима. Нет таблицы или отсутствует RefSelf."

По структуре БД я определил что Reference39 это Справочник.ДолжностиОрганизаций.

Соответственно выгрузка этого справочника через XML тоже падала и приходилось ее пропускать.

После отката на релиз 8.3.10 эти ошибки ТИИ при реструктуризации ушли ?
65 sergey yevsenya
 
09.01.19
09:28
(64) У меня была похожая ошибка типа
Ошибка SDBL:
Ссылка на таблицу недопустима. Нет таблицы или отсутствует RefSelf.
Но ругалось вроде на перечисление. На 8.3.10 прошло без ошибок
66 ЧессМастер
 
09.01.19
12:27
(65) Смотри что получается.

У меня релиз бухгалтерии 2.0.66.65.

Когда запускаю ТИИ под релизом 8.3.13.1513 получаю ошибку

"В процессе обновления информационной базы произошла критическая ошибка
по причине:
Ошибка SDBL:
Ссылочная константа содержит недопустимый ссылочный номер таблицы"

Пробуем запустить ТИИ под релизом 8.3.10.2561.
ТИИ прекрасно проходит.

Обновляем релиз 2.0.66.65 на 2.0.66.67.
Все прекрасно проходит.

Дальше пробую под релизом 8.3.10.2561 перейти на версию 3.0 (обновиться на релиз 3.0.67.54).

Получаю сообщение что для этого нужен релиз не менее 8.3.12
Ставлю его (8.3.12.1714).
Запускаю ТИИ и получаю опять ошибку.

Что можно придумать в этом случае ?
Есть какой-то релиз из линейки 8.3.12 под которым можно провести обновление без ошибок в реструктуризации ?
67 ЧессМастер
 
09.01.19
12:28
(62) Попробуй понижение релиза до 8.3.10.
Реально помогает до какого-то момента.
68 ЧессМастер
 
09.01.19
12:33
(65) Вообще конечно подход 1С что под релизом 8.3.10.2561 ТИИ проходит без ошибок, а под релизом 8.3.13.1513 ТИИ заканчивается ошибкой удивляет.

Данные же одни и те же.
69 ЧессМастер
 
09.01.19
14:16
(65) Попробовал на релизе 8.3.12.1685 который рекомендуется для обновления.

При обновлении в процессе реструктуризации выдает ошибку

"В процессе обновления информационной базы произошла критическая ошибка
по причине:
Ошибка SDBL:
Таблица или поле Fld32229 не содержится в разделе FROM (pos=59)"

При простом ТИИ выдает ошибку

"В процессе обновления информационной базы произошла критическая ошибка
по причине:
Ошибка SDBL:
Ссылочная константа содержит недопустимый ссылочный номер таблицы"

При этом под релизом 8.3.10.2561 ТИИ проходит без ошибок.
70 jk3
 
17.01.19
12:37
Продолжение истории (0), ответ поддержки:
"Приаттаченная база 3.0.64.54 уже содержит проблему, но внешне она не проявлялась. Проблема в том, что в базе 2-е таблицы Const24 и Node24 с одинаковым постфиксом."
71 ЧессМастер
 
24.01.19
13:50
(70) Вам проблему с базой удалось решить ?

Я у себя решил проблему созданием новой базы из шаблона и переливанием в базу данных.
72 jk3
 
30.01.19
12:35
(71) В общем, поддержка исправила отосланную базу, но инструмент по исправлению (или хотя бы инструкцию) давать отказалась.
Цитирую:
"Восстановить базу пользователь самостоятельно не может, т.к. нужно обновлять также служебные структуры. Мы можем восстановить конкретную проблему, при этом, повторюсь, мы не можем гарантировать что других проблем не будет."

С учетом того, что они решали проблему 3 месяца, база, которую я им отсылал, стала неактуальной и мне уже нафиг не нужна, тем более, что это не гарантия, что в дальнейшем проблем с ней не будет.

Я решил проблему взятием бэкапа полугодовой давности, в котором точно всё хорошо, и перезаливом данных за полгода из УТ.
Да, возможно бухам придется заново что-то руками подправлять в базе, но это лучше, чем подобный баг вылезет в дальнейшем в исправленной каким-то неведомым способом базе.

Кстати, у меня не взлетели автосгенерированные правила конвертации БП => БП. Справочники еще норм переносило, а на документах вываливалось в ошибку
"Объект =  Выдача наличных
ОписаниеОшибки = Ошибка при вызове метода контекста (Записать): Запись не верна! Вид субконто "Статьи движения денежных средств" не доступен для данной записи!"

Не подскажите на будущее как правильно эти правила создавать в конвертации 2.0 или может быть какая-то особенная обработка нужна?
AdBlock убивает бесплатный контент. 1Сергей