|
Ошибка 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 успешно. Потом при обновлении в режиме предприятия падает вот так:
Это Процедура ЗарегистрироватьОбъектНаВсехУзлах(Знач Объект, Знач ИмяПланаОбмена, Знач ВключаяГлавныйУзел = Истина) Экспорт Падает при ИмяПланаОбмена = "Полный". Если ИмяПланаОбмена = "АвтономнаяРабота", то проходит без проблем. Код процедуры такой:
Если в отладчике попробовать получить значение переменной Получатель, возвращает "Ошибка SDBL: Таблица или поле ID не содержится в разделе FROM". Эту ошибку можно обойти в отладчике, заменив значение ИмяПланаОбмена = "Полный" на "АвтономнаяРабота" в начале процедуры. Но потом после того как обновление установится, при попытке сделать ТИИ с галкой "проверка логической целостности" сразу выдается ошибка в виде предупреждения и ТИИ останавливается:
Т.е. фактически на выходе получаем битую базу. |
|||
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. В описании исправленных багов нечто отдаленно похожее нашёл, но не совсем оно:
Исправлена: "Технологическая платформа", версия 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 обычных элементов.
|
|||
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.
Т.е. до обновления ТИИ проходит без ошибок, после обновления в конфигураторе -- база поломанная. Релиз платформы последний. Фирма 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](
И даже данные в ней есть, 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
Т.е. какой-то внутренний 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.
При этом реструктуризации подвергаются объекты:
Как раз в следующем за релизом 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С, цитата:
Помогите перевести этот ответ на русский. Что надо сделать? 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 или может быть какая-то особенная обработка нужна? |
Форум | Правила | Описание | Объявления | Секции | Поиск | Книга знаний | Вики-миста |