В составе конфигурации имеется таблица, относящаяся к документам, но не имеющая отношения к метаданным (проверено методом  ПолучитьСтруктуруХраненияБазыДанных()). Она мешает накатить на изменённую конфигурацию другую (типовую, к примеру). Эта таблица, не имеющая ссылок на другие таблицы БД физически удаляется из состава БД, но конфигурация БД при этом, судя по всему, не меняется в отношении её. Как заставить конфигурацию БД, а ещё лучше основную конфигурацию, "забыть" про существование этой таблицы?

"но конфигурация БД при этом, судя по всему, не меняется в отношении её" и "не имеющая отношения к метаданным (" как то не коррелируются

(1) После удаления таблицы была выгружена конфигурация БД и загружена. После этого метод ПолучитьСтруктуруХраненияБазыДанных() говорит что она осталась.

измени конфигу, сохрани и  обнови конфиг БД

(2) а как удалялась таблица? и что за прикол с выгрузкой-загрузкой конфиги бд?

Удалите документы из метаданных. Накатите конфигурацию.

Если просто дропнуть и потом залить изменения - будет заново создана таблица.

Хотя для меня "относящаяся к документам, но не имеющая отношения к метаданным " несколько противоречиво...

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

(5) Её название начинается с "Document"

(5) Как это удалите документы? я не могу грохнуть данные.

(7) А у меня в 7шной базе есть 10 таблиц, начинающихся с SC, но никакого отношения к справочникам они не имеют...

(9) сам то не запутываешься? )

(10) А мне-то зачем путаться? С ними программы работают :-)

(7) Как это выглядит в получить структуру хранения?
P.S. кстати, _Document...

Как заставить для начала конфу БД "увидеть", что этой таблицы больше нет?

Не понятно, что значит "мешает накатить на изменённую конфигурацию другую "
Если таблицы нет в конфигурации, то при внесении изменений она не видна.

(14) При реструктуризации она восстанавливается, так как "сидит" в основной конфигурации

Чёго темнит автор? партизан или шпиён американский? Конфа, релиз и название таблицы - точно и полностью.

Тогда и разберемся что за таблица, которая никакого отношения к базе не имеет :))

(16) БП это пиленая

(16) 2.0. Document11573. 16-ая платформа

(12) В это таблице до кучи даты со смещением 2000, т.е. год в формате 4012.

Переспрошу: "Document11573" или "_Document11573" Если "_Document..." - то это обычная таблица для объекта из "Документы".

(20) Без нижнего подчёркивания.

Кстати, в каких таблицах лежит описание этой таблицы?

Убить эти строчки, отвечающие за создание это1 таблицы и всего делов?

Я чтото не догоняю: ты всё время говоришь про "таблицы БД", а надо - про основную конфигурацию говорить - она первоисточник, она "определяет" состав таблиц БД в конце концов. Не конфигурация поставщика, не конфигурация БД.

И непосредственное удаление таблицы из базы данных - ничего не изменяет. При ТиИ эта таблица вновь будет "восстановлена" по информации из основной конфигурации.

PS: на самом деле это не совсем так, как я сказал, но можно и так пояснить. В БД схема есть по которой она тестируется и восстанавливается. Но информация в неё пишится из конфигурации.

(24) Абсолютно с тобою согласен. Мысль была такая: выгрузить конфигурацию БД с целью "похоронить" эту таблицу, а затем уже с неё сформировать основную конфигурацию.

(25) Если она есть в конфигурации БД, то она должна быть в получитьструктурухранения

(26) А кто говорит что её там нет?

(26) Я сказал только что она не относится к метаданным конфигурации

(27) Тогда прошу ответить на вопрос 12

(27) В ПолучитьСтруктуруХранения она имеется со всеми полями, индексами и т.д. и т.п.

(27) Там же говорится, что НИКАКОГО отношения к метаданным она не имеет!

(0) Конфигурация -> Проверка конфигурации что говорит? Достаточно проверки с первыми 2 галочками.

(32) Миллион раз запускались различные проверки-перепроверки со всеми галочками-чекбоксами. Ничего не помогает. Надо как-то хирургическим путём устранить проблему.

(20) Был не прав. Почему-то через ПолучитьСтруктуру... имя таблицы хранения выводится без нижнего подчёркивания.

Выяснилась ещё одна подробность: кроме такого "левого" документа существует ещё и "левый" регистр сведений

Т.е. помимо "нормальных" таблиц создались некие клоны объектов метаданных, несвязанные ни с чем.

(34) О_О Вероятно "БП это пиленая"(17) больше, чем можно было ожидать :(

Чисто теоретически, я могу сделать так, чтобы в базе данных были "левые" таблицы и они воспринимались платформой как "родные"... Но это - "чисто теоретически", что-то из области финтастики - непонятно кто и зачем это сделал. Я больше верю в сбои и баги платформы, чем в прогера 1С, который это может и сделал :)

Однозначно - некорректно сработал механизм создания новых объектов. Скорее всего, виновата связка сервер 1с - сервер БД. Вопрос  Что делать? остаётся

(37) Ясно что спецом никто эти левые таблицы не создавал.

Никакие там chkdb не помогают.

Выгрузить конфу и загрузить в новую базу - эта таблица там появляется или нет? Если появляется - значит она прописана в конфигурации.

Можно попробывать через настроку поддержки сравнить основную конфигурацию с конфигурацией поставщика - смотреть откуда ноги растут у этой таблицы метаданных.

Если она из сбойной конфы поставщика - заменить конфу поставщика не проблема.

Если эта таблица в основной конфигурации видна - то разрешить удаление объектов; снять все галочки в сравнении: поставить галочки на удаление этих метаданных и выполнить сравнение, объединение.

Если не поможет - сообщи что получилось, что нет.

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

если все нормально - через xml данные перегрузи все

(41) После выгрузки конфы и создания пустой базы эти клоны исчезли, их просто нет.

(41) Но загрузка этой "хорошей" конфы, к сожалению, не убивает эти "левые" таблицы в рабочей базе.

(41) Так как у этих клонов нет привязки к метаданным, то естественно, они не видны в конфигурации

Если объёмы позволяют - выгрузи информационную базу в .dt и загрузи в копию. Имхо, должна исчезнуть эта таблица.

скорее всего левая таблица - view

(44) Может кто триггер какой повесил в SQL?

(34) В 8.1 имя базы вы получить структуру хранения без подчеркивания, это нормально. В 8.2 не помню.

Вообщем не всё так плохо в датском королевстве. Помогла распределёнка - таблички формируются заново, а "плохие" естественно пропадают.