Конфигурация базы данных и Drop таблицы SQL-сервера #640106

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Я чтото не догоняю: ты всё время говоришь про "таблицы БД", а надо - про основную конфигурацию говорить - она первоисточник, она "определяет" состав таблиц БД в конце концов. Не конфигурация поставщика, не конфигурация БД. И непосредственное удаление таблицы из базы данных - ничего не изменяет. При ТиИ эта таблица вновь будет "восстановлена" по информации из основной конфигурации. PS: на самом деле это не совсем так, как я сказал, но можно и так пояснить. В БД схема есть по которой она тестируется и восстанавливается. Но информация в неё пишится из конфигурации.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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