1с в схеме базы данных нет таблицы с именем
Добрый день. При обновлении конфигурации ошибка "В схеме базы данных отсутствует таблица DocumentChngR35788". 1. Клиент-серверный вариант 2. Выгрузка-загрузка dt не помогла 3. При тестировании и исправлении вылетает, ругаясь на другую таблицу. Тоже DocumentChng, но тестирование завершает. 4. С помощью ПолучитьСтруктуруХраненияБазыДанных.ВыбратьСтроку найти таблицы не удается. Подскажите, что можно сделать?
найти копию, где есть такая таблица и через SQL перенести эту таблицу в свою базу. Только про обновление придется забыть. В крайнем случае сделать обмен через Выгрузку - Загрузку XML
то, что будет взята схема из прошлой базы, где нет изменений. Сейчас задача восстановить именно схему конфигурации
найдите метаданное документ и добавьте в него поле . это приведет к реструктуризации и пересозданию таблицы.
Эээ. о чём вы? Если мне память не изменяет, это таблица регистрации изменений данных - туда нечего и нечем что-либо вставлять и удалять. Имхо, не тестирование данных, а тестирование конфигурации нужно сделать. Я бы выгрузил конфигурацию в чистую базу и там убедился бы в наличии/отсутствии ошибки.
Поднимай копию из архива,ищи там таблицу :( в рабочей искать таблицу бесполезно - платформа уже искала и не нашла :)
В принципе, из найденной работоспособной конфигурации, можно выгрузить таблицу и загрузить в рабочую базу. А я бы, в случае автора, на конфигурацию базы из архива изменения из рабочей базы накатил бы, а саму конфигурацию загрузил бы в рабочую базу.
Нет такой таблице в копии при обновлении. Накатывалось сразу три релиза. Копия делалась только исходной базы. Возможно в какой-то промежуточной версии эта таблица и была. Ее можно вручную добавить?
Накатывались как? Попробовать накатывать на копии по 1 релизу с обязательным залитием конфы в конфигурацию БД и однократным входом в базу
Так и накатывались по одному релизу и однократным входом в базу. В копии нет данных за последние 2 недели.
Ну а после повторного, последовательного обновления старой копии базы, эта конфигурация ошибок не содержит? Если "Да" - то вот эту конфигурацию и надо выгрузить и загрузить в рабочую базу! Да уж. если тормозим, то тормозим до полного ступора :)
похоже этот документ DocumentChngR35788 удалили из плана обмена. Добавьте его обратно в состав плана обмена, может всё и выровняется. Хотя. Может и не выровняется, создастся новая таблица с другим именем.
Не ясно, что за документ. Такой таблицы нет ни в SQL, ни через ПолучитьСтруктуруХраненияБазыДанных.ВыбратьСтроку
"Не ясно, что за документ" - я знаю в чём причина. В тебе :( Не внимательность - твой враг. Смотри - в типовых конфигурациях это таблица регистрации изменений. В плане обмена есть документ, у которого нет этой служебной таблицы. Имхо всё, разумеется. PS: Если озвучить конфигурацию, то возможно, что кто-то по своей базе проверит наличие этой таблицы.
+ После этого если пройдет обновление, то через ПолучитьСтруктуруХраненияБазыДанных скорее всего можно будет найти, что это за таблица.
Имхо, эта таблица должна была быть, но её нет в схеме. Ок? Что мешает платформе при ТиИ добавить эту таблицу? Да ничего, она это может сделать :) Но делает :(Что же ей мешает? Это риторический вопрос (платформа уже об этом сообщила)
PS: "При тестировании и исправлении вылетает, ругаясь на другую таблицу. Тоже DocumentChng" - у автора не только в озвученной таблице проблема.
В текущей схеме таблицы нет. А в схеме после обновления - есть. Но нет действия по созданию. Вообще, демонами попахивает. я бы кеши почистил еще.
Вообще-то, поправьте меня если не прав, автор ни разу не сообщил, что у него хоть где-то есть эта таблица. Имхо, не исключено, что в конфигурации план обмена глюкнул (первопричина). А автор и платформа героически борются с последствиями, когда безуспешны все попытки сгенерировать таблицы по кривому плану обмена.
Создали такую таблицу в SQL - не помогло. Там много однотипных таблиц типа documentchnrR. Все они пустые и имеют 4 поля. Сделали по аналогии с "нужным" номером - не помогло.
А у вас в базах есть обмен данными? он используется? Может там кто-то чего-то решил почистить или починить под свое видение и вот теперь такие последствия?
День добрый. Есть Комплексная автоматизация 1.1.105.1. Платформа 8.2.19.130
PostgreeSQL.
Две базы, из одной в другую делается выгрузка данных.
Ошибка SDBL: В схеме базы данных нет таблицы с именем q_000_t_001 (яндекс и гугл, ни чего путного не выдают, хотя фразу поисковую выдают сразу )
Программно так же нельзя ни очистить план обмена ни зарегистрировать. Выбивает с ошибкой и Программа вылетает.
В файловой версии - такого глюка нет. Все отлично заходится и чистится. Тестирование и исправление, а так же стандартная утилита для тестирования структуры базы данных(chdbfl.exe) - ошибок не находят.
(23)т.е. ошибка снова возникает при следующем обмене.
А удалить полностью БД в постгри - пересоздать и уже в новую БД загрузить дт? или так и делал?)
Или рядом создать вторую базу и там проверить.
Первое, что приходит в голову: структура баз изменилась после обновления, а правила обмена остались прежними.
(4) правила своевременно обновляются под релизы.
ошибка именно при попытке просмотреть что зарегистировано в плане обмена к обмену
ИМХО, тут-то собака и порылась, надо начинать с решения этой ошибки.
Кстати, а в файловом варианте эта ошибка тоже возникает?
Ну, тогда это какие-то косяки Postgre, тут я пас.
Разве что попробовать платформу обновить?
(11) Ох уж эти одноэсники. Вам бы только обновлять, да и то мифический страх перед нечетными релизами.
Почему регистр - потому что на сколько я помню, в узле плана обмена хранятся данные не во временной таблице, поэтому отпадает
(21) В них можкт храниться что угодно. В том числе временные метаданные при реструктуризации.
Но сами изменения конфы хранятся в таблице ConfigSave. Если Конфигуратор падает при запуске, надо дропнуть эту таблицу.
Я специально экспериментировал - в запросе помещал выборку во временную таблицу и её содержимое попадало в темповую таблицу скуля.
Когда в запросе написал ПОМЕСТИТЬ вт а потом УНИЧТОЖИТЬ вт, то квосты подчищалист и на сервре.
Просто однажды после разных падений и дисконнектов клиентов эта временная база забивалась и Конфигуратор падал при реорганизации.
Лечил перезапуском службы скуля.
(28) Я слегка термины перепутал и ввел в заблуждение. Не временная таблица, а виртуальная.
В вашем случае не понимаю, как временная таблица может влиять на конфигуратор, если только вы не о ConfigSave (она не временная), но если о ней, то не понимаю как вы ее
В случае ТС, идет какой-то запрос к бд, создается некая временная таблица q_000_t_001, и она падает. Это моё предположение.
Хотя скуль работал без сбоев. Просто 1С решила, что "и так много поработали, хватит".
На маленьких базах сойдет.
(22) это как временное решение, так и делаю..
Но всё завязывается тогда на меня.. А нужно чтобы пользователи это делали
(23)т.е. ошибка снова возникает при следующем обмене.
А удалить полностью БД в постгри - пересоздать и уже в новую БД загрузить дт? или так и делал?)
Или рядом создать вторую базу и там проверить.
(26)
в принципе только на этих выходных удалось получить в доступ сервер с 1С..
Помогло вот что..
1. Выгрузил базу в файловую и еще раз прогнал тестирование и исправление - особо ни чего не найдено
2. на всякий случай проверил внешней утилитой от 1С - ошибок нет
3. Удалил базу нафиг с сервера
4. заново создал в SQL базу и загрузил туда выгрузку
При этом как советовали ранее, пробовали и КЭШ чистить и у пользователе я и на сервере, и Остановку служб делать, это не помогало.
Только пересоздание базы..
Ошибка SDBL: В схеме базы данных нет таблицы с именем q_000_t_001 (яндекс и гугл, ни чего путного не выдают, хотя фразу поисковую выдают сразу )
Ну, это смотря что искать.
Волшебного заклинания типа "сим-салабим-ахалай-махалай" - да, нету, а вот пищи для размышлений - навалом:
То есть, причина проблемы - в точечной несовместимости 1С и имеющейся СУБД. Подтверждается это и тем, что в файловом варианте ошибка не воспроизводится.
Выводы? Лично я сделал следующий: поскольку работа платформы 1С оптимизируется под MS SQL (там такая проблема вроде бы тоже случается, но это - только со слов знатока из (19), то есть смысл подумать о переходе на эту СУБД. Затратно, поэтому лучше сначала потренироваться на кошках копии базы.
Или, как более дешевый вариант - ковырять отладчиком код, вызывающий ошибку и переписывать его, пытаясь угадать - какие нужно внести изменения для того, чтобы Postgree отработал корректно?
А потом, в случае успеха, повторять эти телодвижения после каждого обновления. и молиться, чтобы больше ничего подобного не вылезло в других местах.
(1) Как раз проблема в том, что стояла совместимость 8.3.12, которая не поддерживает расширения. Но почему то при входе в конфигураторе в список пользователей писало о каком то расширении и предлагало убрать совместимость.
Проблема в другом, эта ошибка возникает и при попытке удалить помеченные объекты, так ее собственно и нашли. Так что проблема не в расширениях, а как убрать эту ошибку.
(2) расширения поддерживаются начиная с 8.3.6. Поэтому 8.3.12 уж точно поддерживает. То, что вы полностью похерили все расширения - это не очень хорошо.
(0) Есть вещи, которые программист 1С просто обязан знать. Например то, что при режиме совместимости 8.2.13 и ниже, все константы хранятся в одной таблице СУБД, а начиная с версии 8.2.14 и выше - для каждой константы создается своя таблица СУБД.
(9) ну в файловой, посмотри, есть ли ConstChngR24285 в данных и в dbnames и добавь руками описалово в схему
Проще то, проще это. Проще не валять дурака, играя с совместимостью - это вам не гармошка туда/сюда :(
Короче: повышать совместимость - можно, а вот "понижать". Попробуйте через выгрузить/загрузить DT. Выгружаете при "не использовать", загружаете при "8.2.13".
(6) "В базе есть планы обмена, может в них глюки?" - специалисту это и так понятно: ConstChngR24285 - "Chng" - таблица регистрации изменений.
Ошибка ConstChngR24285 - связано с планами обмена, но пока не ясно это глюк платформы или базы, пока разбираюсь.
(17) Выгрузи базу в DT под старой платформой и загрузи из DT на новой платформе. Сделай это чисто ради спортивного интереса - интересно же :)
Если удалить план обмена - ошибка "Ошибка SDBL: В схеме базы данных нет таблицы с именем ConstChngR24285" исчезает.
Начат обмен данными по настройке "Обмен с "Авто нац. стандарты"" (12:59:50).
Обмен данными по настройке "Обмен с "Авто нац. стандарты"" завершен (13:00:16).
(22) ну неверная схема же. В данных, в конфиге и в dbnames есть ссылка на табличку, а в dbschema отсутствует запись об этом.
(23) Спасибо за подсказку. Подскажите, где в gtool1cd.exe находиться dbnames? А конфигурация, я так понял это CONFIG, но где в ней найти мою таблицу? Я так понимаю что возможно есть описание где-то этих таблицы и что в них храниться?
Я не пессимист, но уверен что ТС удалением одной таблицы так легко не отделается. ТС не пытается восстановить БД - он продолжает калечить уже разрушенную базу.
(28) Мы восстановили из архива базу и юзеры успешно работают. А делее спортивный интерес, почему эта база выдает сбой при увеличении совместимости. Потому что в будущем возможно придется поднять совместимость и надо быть готовым к этому. Так что все отвечающим большое спасибо, пока что ошибку не исправил, но уже в пути.
Если база открывается то выгрузить для перехода в сервис, во фреше загрузить, потом выгрузить уже в обновленной версии - круто? При тестировании выбери только реструктуризация как варик. Если не чего не поможет WinHex и погнал )))
(9) там нет. если отменить все изм, и реструктуризация не катит, загрузка CF со структурой до обновления не помогает. тогда только hex
(3) выгрузить конфу в файлы, в руте будет файло с идентификатором, по идентификатору находишь в тул1сд че за константа
Если база открывается в режиме предприятия то создаешь пустую базу и выгружаешь все данные через XML.
На битых данных будет падение выгрузки - их пропускаешь
(31) Спасибо, не сомневаюсь. Вопрос только в том чтобы найти нужную. Да ищу, параллельно пробую спрашивать.
(32) Тебе нужно попробовать с помощью Tool_1CD удалить таблицу CONFIGSAVE
По всей видимости твоя база упала в момент реструктуризации.
То есть таблица CONFIG должна быть живая.
(29) >Изначально думал поднять из сф новую базу и воспользоваться ПолучитьСтруктуруХраненияБазыДанных()
В базах даже с одинаковой конфигурацией будут разные идентификаторы.
То есть ПолучитьСтруктуруХраненияБазыДанных() даст разные данные.
это та самая схема в которой нет моей константы? как понять формат этого чтобы корректно внести данные?
таблица _CONST30015 в файле присутвует
(39) таблица CONFIGSAVE пуста, это как я понимаю копия конфигурации которую надо будет применить
(47) Пример как такое делать есть ?
У меня пару месяцев назад был подобный вопрос с базой.
Тоже ругалось на отсутствие в схеме базы данных.
Я не нашел способ редактировать DBSCHEMA и решил задачу выгрузкой данных через XML.
(51) Если нужно и не найдешь стукнись на мыло. Мыло в профиле. Сброшу.
Я не помню уже где скачивал.
(57) это обычный текст, не надо его разбирать
При желании, можно в json конвертнуть или в xml.. только, не за чем
(68) да. не восстанавливает.проверил на 1с8.2. но как-то мне удалось восстановить DBSchema без моего участия. может подменой похожего или пустого и реструктуризацией.
Коллеги, а почему автор не хочет очистить таблицу CONFIGSAVE и просто вернуться к той конфигурации которая была ?
(71)архива с конфой-донором нет.но если типовая то конфу-донора можно сгенерировать.возвожно- это самое простое решение. очистка CONFIGSAVE не поможет. произошло рассогласование метаданных и структуры бд или таблицы проекции метаданных в структуру бд
,кот. хранится в записи dbnames из таблицы params
пока не совсем понимаю в чем различие, правильно ли я понимаю что сами метаданные это то что хранится в таблице CONFIG
структура бд это то что храниться в DBSCHEMA а проекция это то что в храниться в dbnames и dbnames должно соответвовать DBSCHEMA ?
нет. не правильно понимаете . в DBSCHEMA хранятся соответствия типов 1с и бд . и естественно DBSCHEMA должна соответствовать dbnames .но все , о чем я питсал относится к 1с8.2 . в 1с8.3 может быть по-другому.
(72) >если типовая то конфу-донора можно сгенерировать
А разве это не приведет к тому же что и создание новой базы с такой же конфой но при этом у объектов будут другие индентиффикаторы ?
(0) А как ты с этой базой столкнулся ? Может все таки есть какие то бэкапы.
Это какое то реальное безумие обновлять базу при полном отсутствии бэкапов.
(75) структура бд в новой базе может быть другой. задача - привести в соответствие метаданные , dbnames и структуру бд. поскольку тулсиди умеет выгружать-загружать конфигурацию замена конфигурации- более простая операция для файловой базы чем редактирование dbnames или изменение структуры бд.
+(75) а для серверной бд проще изменить структуру бд. и на последнем месте - правка dbnames и DBSCHEMA
Немного разобрался как свзяаны талицы. нашел свою константу в DBNames. Может ктото подскажет как ее отредактировать?
(81 )тулсиди вроде умеет выгружать- загружать таблицы. выгрузите парамс отредактируйте запись DBNames. загрузите обратно. если в DBNames будет абракадебра - то разожмите-сожмите ее c помощью v8unpack
Мне как то попадалась база с такими симптомами, у меня сложилось впечатление что при обновлении базы записалась новая dbNames? а новая dbschema не записалась, поэтому и ругается и даже если если исправите проблему с этой конкретной константой, потом будет другая и еще другая константа, и а потом потом справочник итак далее. ДЛя исправления этого надо ручками прописать dbschema для новых и измененных объектов, а задача эта достатчно муторная. Либо проверить соответствие DBShema - dbNames? и все записи которых нет в DBShema удалить из dbNames. Затем что нибудь изменить в конфе чтобы пошел процесс реструктуризации.
Все это возможно сделать если перевести базу в SQL (у меня сработала выгрузка в dt/загрузка из dt), у меня сложилось мнение что на файловой сделать это нельзя. Хотя я уже не помню, но в SQL легче переписывать эти файлы.
:(
(94) ДЛя исправления этого надо ручками прописать dbschema для новых и измененных объектов, а задача эта достатчно муторная. как сформировать правильную схему?
Либо проверить соответствие DBShema - dbNames? да я пока вижу неторое количество новых констант. Как сопоставить пока не поинмаю только начинаю узучать
сди толс умеет вроде следующее, только как пока я не могу применить, по сути надо номер сопоставить с названиями с одной базе и другой и получить соответвие номеров вот как и поулчить я бы тоже хотел понять.
Поле ввода «Файл соответствия номеров» и кнопка «Замена TREF»
Иногда в процессе восстановления возникает необходимость переноса таблиц из одной базы в другую базу с такой же конфигурацией, но с несовпадающей нумерацией в DBNames. Например, разрушена таблица в центральной базе, но нужная таблица есть в периферийной базе. Кроме того, что в таких базах не совпадают имена таблиц и полей, которую можно решить правкой файла описания таблицы, есть еще проблема несовпадения типов ссылок, которые хранятся в полях с окончанием "TREF". Подробности описаны в разделе "Структура информационной базы 1С". Данный инструмент позволяет произвести замену всех значений во всех таблицах базы в полях с окончанием TREF. Список замен должен содержаться в файле, выбираемом в поле ввода. Файл представляет собой текстовый файл. В каждой строке файла содержатся два числа, разделенных табуляцией. Второе число - заменяемое. Все поля, содержащие такое значение, заменяются на первое число строки.
Все замены производятся без изменения индексов в базе!
Самый простой путь, удаляйте все из DBNames на что ругается (напишите сравнение dbnames и dbshema). Так вы по сути вернетесь к базе до обновления. ТОлько для этого надо еще все конфиги вернуть к релизу до обновления (если это типовая база), то это легко. Если все сделаете верно, то с вероятностью 95 % база снова запустится, и будет как до обновления.
я не знаю с какого релиза обновлялись.
мне вот удаление конкреной константы не помогло. хотя не исключаю что к я уже чет напутал. ладно, завтра со свежей головой
Обычно ошибка SDBL происходит при сохранении и обновлении конфигураций в момент реструктуризации базы данных, а также во время работы обменов данными.
- Ожидается выражение (pos = ).
- Выход за пределы размерности.
- Поле таблицы не может принимать значение NULL.
- Ошибка при полнотекстовом индексировании.
- Попытка вставки значения недопустимого типа.
- Поле определено неоднозначно.
- Пропущена точка с запятой.
- В схеме базы данных нет таблицы с именем…
Исправление ошибки SDBL
Большая часть способов исправления связана с восстановлением нормальной работы Информационной Базы. Но иногда описанными способами решить проблему не получается, поэтому помните о самом лучшем, универсальном способе — регулярном резервном копировании.
Перезагрузка сервера 1С и SQL-сервера
Самый простой способ, при условии, что на текущий момент в базе никто не работает.
Зайдите на сервер и выключите следующие службы:
- «Агент сервера 1С»,
- «SQL Server»,
- «Агент SQL Сервера».
А затем запустите их обратно.
Очистка кэша на сервере и клиента, где проявилась ошибка
Как правило кэш расположен по адресу:
- «%userprofile%\Local Settings\Application Data\1C\1Cv8» и «%userprofile%\Application Data\1C\1Cv8» для Windows XP,
- «%userprofile%\AppData\Roaming\1C\1Cv8» и «%userprofile%\AppData\Local\1C\1Cv8» для Windows 7 и выше.
Перейдите в данный каталог и удалить все папки с генерированными именами вида « dg7c8re4-b89r…». При удалении будьте внимательны — в этой директории может присутствовать индекс полнотекстового поиска 1С, а также журналы регистрации, их удалять не нужно.
Перезаливка базы из DT-файла
Иногда помогает, казалось бы, парадоксальный способ — выгрузка базы данных в файл формата DT, а затем загрузка его обратно.
Войдите в режим «Конфигуратор», выберите пункт меню «Администрирование» > «Выгрузить информационную базу» и выберите каталог для сохранения файла.
Затем через аналогично через меню «Администрирование» > «Загрузить информационную базу» загрузите его обратно.
Тестирование и исправление Информационной базы
Для тестирование и исправление Информационной базы: войдите в «Конфигуратор», выберите пункт меню «Администрирование» > «Тестирование и исправление».
В случаях, когда невозможно запустить конфигуратор, воспользуйтесь утилитой chdbfl.exe. Это упрощенная программа-аналог тестирования базы, функции, которая запускается в режиме конфигуратора. Расположена она в папке «bin» установленной технологической платформы, например, C:\Program Files (x86)\1cv8\8.3…\bin\chdbfl.exe.
Пользоваться ей просто — указываете путь к файлу базы данных и ставите опцию, нужно ли сразу исправлять обнаруженные ошибки. Если нет — утилита только продиагностирует ИБ.
Обновление платформы до новой версии
В данном случае всё достаточно просто. Скачивает с сайта поддержки 1С дистрибутив свежей версии платформы, распаковываем и запускаем инсталятор setup.exe.
Очистка таблиц базы данных
В крайнем случае можно попробовать удалить таблицы БД, связанные с ошибкой — «dbo._ConfigChngR» и «dbo._ConfigChngR_ExtProps».
Производится это через менеджер SQL-скриптом вида:
use имя_базы_данных
delete from dbo ._ ConfigChngR
delete from dbo ._ ConfigChngR _ ExtProps
Помните, прямые SQL-запросы лучше доверить профессионалу, умеющему работать с SQL.
12 статей про обновление 1С
Типовую программу 1С легко обновить самостоятельно через конфигуратор или интернет. Ещё один способ — использовать cfu-файл. Если пропущено много релизов, вам сэкономят время промежуточные конфигурации.
После обновления не забывайте запустить особые процедуры.
Бывает выгоднее отдать обновление нетиповой 1С на аутсорсинг.
Что нового для вашей 1С?
Рассылка осуществляется в день выхода обновления. Никакой рекламы, только полезная информация. Посмотрите пример →
Читайте также: