Удаление объекта метаданных средствами SQL #393749

Возможно ли такое... Мне необходимо удалить ДОКУМЕНТ_А средствами SQL, причем так же удалить все ссылки на это ДОКУМЕНТ_А в других документах на него. Ознакомился с докой на ИТС "Размещение данных 1С:Предприятия 8.1", особо не помогла, смог только вяснить в таблице с каим именем на sql храниться документ и соотвественно выцепить его табличные части. Как я понимаю необходимо произвести манипуляции еще и с таблицей config... Друзья, кто сталкивался с такой проблемой - расскажите как и возможно ли это.

Возможно ли такое... Мне необходимо удалить ДОКУМЕНТ_А средствами SQL, причем так же удалить все ссылки на это ДОКУМЕНТ_А в других документах на него. Ознакомился с докой на ИТС "Размещение данных 1С:Предприятия 8.1", особо не помогла, смог только вяснить в таблице с каим именем на sql храниться документ и соотвественно выцепить его табличные части. Как я понимаю необходимо произвести манипуляции еще и с таблицей config... Друзья, кто сталкивался с такой проблемой - расскажите как и возможно ли это.

ничего не трогай

А стандартными средствами удалить нельзя чтоли?

Я не спрашивал разрешения потрогать. Давайте обойдемся без делинтанских постов - проще говоря флуда.

Любитель нетрадиционного секса? Так это на других форумах...

DELETE FROM WHERE Возможно все, но надо не забывать про ссылки в журналах и кое-где еще. Лучше ИМХО поставить пометку на удаление ср-вами sql, а удалять уже 1ской.

При реструктуризации возникает ошибка. Каким-то образом при получении конифгурации из Хранилища, завелись некорректные таблицы. Которые при реструктуризации не позволяют выполнить её...

Так удали некорректные таблицы из базы и из таблицы конфигурации.

Вы меня не поняли ДОКУМЕНТ - это объект метаданных. А не запись в таблице, как вы посчитали

Если сделать простой delete валятся ошибки при реиндексации на удаленные объекты. Нужно глубже копнуть удалить все ссылки на эти объекты.

Через SQL md можно править? О_о

тогда тебе еще и в master таблицы лезть нада будет, syscolumns или systables где то там перечисление полей всех таблиц всех БД...

Ну вот ссылка к примеру в Роли, должна быть удалена, ссылка в измерении регистра на объект тоже должна быть удалена.

может проще найти "правильную" конфигу, обновить хранилище и вытянуть по новой? может прокатить такой вариант?

Самый не плохой вариант был использовать стандартную обработку ИТС, которая позволяет выгрузить конфу в XML И залить ей в новую НОРМАЛЬНУЮ конфу - но по непнятным причинам обработка при выгрузке зависает.

Как еще можно выгрузить данные из конфигурации? не выгружая саму конфу?

А где эти таблицы находятся? Про них так же ничего не сказано в доке по размещению данных...

ну так запусти ТИИ или chdbfl

что такое ТИИ ?

Конфигурация - Администрирование - Тестирование и исправление...

chdbfl - для файлового варианта

Не помогает Конфигурация - Администрирование - Тестирование и исправление...

Чисто средствами SQL вы объект МЕТАДАННЫХ удалить не сможете. Потому как сама конфа хранится в SQL в виде бинарных данных, а не набора связанных таблиц (таблицы config, поле BinaryData). Задача решаемая, но её адекватность вызывает громадные сомнения. Прийдется анализировать и использовать очень большой объем недокументированной информации, со всеми вытекающими.

Если честно, задавая вопрос в , думал, что кто-нибудь поможет расшифровать именно поле binarydata . Если я правильно понял, весь корень зла именно в нем.

Корень зла в том, что недокументированные способы работы с данными и метаданными чреваты своей непредсказуемостью. Не отследив все взаимосвязи (а так оно и будет), вы рискуете заложить в свою базу ряд мин замедленного действия. Может, вы снизойдете до объяснения конечной цели своих манипуляций? ЗАЧЕМ это делать и почему делать это ИМЕННО ТАК? Может, коллективный разум сможет предложить разумную альтернативу?

Имхо, такой глюк надо в несколько "этапов" вычищать. Сначало удалить ссылки на документ в тех объектах, которые не "валят" реструктуризацию. Потом (средствами SQL) удалить данные в тех таблицах, которые "валятся". И повторить первый пункт...

+1 С "разбегу" проблему не получилось решить - автор, колись подробностями :)

Поясню ситуацию: Работаем мы вот так: РАБОЧАЯ БАЗА - хранилище конфигурации - ПРОГРАММИСТЫ При добавлении в РАБОЧУЮ БАЗУ документов - произошел глюк какой-то глюк - на следующий день работы вываливалось сообщение relation _document4990 does not exist... Выяснилось что document4990 - это документ ЗаданиеНаПриозводство, который делает обороты по регистру ПартииТоваров. И это ошибка вылетала, потому, что не было проставлено право доступа на чтение документа ЗаданиеНаПриозводство у всех ролей, которым необходимо работать с регистром. Далее все было нормально БАЗА работала, но 3-мя документами никто не пользовался. Когда начала захотели полпользощваться, началаи вылетать сообщения типа relation ТАКОЙ-ТО does not exist и т.п. Решили, что эти документы надо удалить из рабочей базы, обойдя хранилище, удалить объекты в хранилище и заоить из по новой...  Вообщем теперь при попытке удаления в РАБОЧЕЙ базе этих документов выдается сообщение: В процессе обновления информационной базы произошла критическая ошибка. по причине: Ошибка СУБД: ERROR:  relation "_docume4990_vt5206_intkeyind" does not exist

В посте не точно описал: При добавлении в При добавлении в РАБОЧУЮ БАЗУ трёх документов Во время выполнения ТИИ (Тестирование и исправление ИБ) вылетает ошибка : Ошибка СУБД: ERROR: relation "_document4990_vt5206" does not exist

На наверно все обед ушли?

uppp.

Сложно что-то посоветовать. Никогда с подобной ошибкой не сталкивался... Если я правильно понял смысл ругательств 1С - структура метаданных не совпадает со структурой данных БД. Причем в БД нет кой-чего, чего там быть должно в соответствии с текущей версией метаданных. Чтобы попробовал сделать я в подобной ситуации (ессно, на копии): Выгрузил из рабочей базы cf и поднял под ним пустую базу. Потом очень внимательно сравнил структуры пустой базы и рабочей (или можно отталкиваться от ругательств). Т.е. чего не хватает (полей, таблиц, индексов и т.д.) - создать в рабочей 1:1 как в пустой. Когда ругаться перестанет, лучше всего штатно удалить из рабочей эти объекты метаданных и потом штатно создать их по новой (чтобы 1С корректно разобралась со всеми хвостами).

На наверно. Делинтанты, мля. С ЗаданиеНаПрИОзводство справиться не могут.

Вы абсолютно верно вникли в проблему.... Проблема в том - что Ваш совет я уже пробовал. НО при загрузке CF файла имена документов , реквизитов, заводятся в БД каждый раз с другими именами... -) Есть еще один вариант, если получится отпишусь...

Проверка орфографии выполнена ? -)) Ваши предложения?

Вы хотите сказать, что при загрузке одного и того же cf в пустую базу несколько раз подряд, каждый раз генерятся разные имена таблиц и полей??

ну не каждый раз, но что разные могут быть это да

Я хотел сказать, что при выгрузке CF файл-бэкапа с нормально работающей БД, т.е. вчерашщнего бэкапа - при заведении в новой БД и загрузки CF в новую БД - имена таблиц и полей - заводятся по-новому т.е. имеют другие имена. Я не пробовал в пустую БД заливать насколько раз один и тот же CF файл.

Интересно бы было узнать как связаны записи в таблицу config с названиями таблиц документов. Фактически проблема: в таблицу config попали записи на таблицы _documentXXXX_vtXXXX которые не существую, но как их удалить из config - неизвестно...  Пока неизвестно.... Как расшифровать поле binarydata

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

Контакты достойного спеца подскажите ?

Блин, хреново... Можно попробовать создавать таблицы/поля методом научного тыка - на что ругается, то и создавать. Изначально стараясь придерживаться структуры схожих объектов конфигурации, чтоб уменьшить количество итераций...

пробовал пробема с типами

и долго

Сорри, на работе озадачили проблемой - не могу Вам уделить и грамма внимания :( Обсудите без меня варианты: - выгрузить конфу БД (Конфигурация - Конфигурация базы данных - Сохранить конфигурация БД в файл) и сравнить с рабочей конфой - нужно уточнить расхождения; - вернуться к конфе БД (Конфигурация - Конфигурация базы данных - Вернуться к конфигурации БД) - если рабочая конфа и конфа БД различны.

Пробовал не катит... -)

Варианты починки базы пр  всяких сбоях вроде такие 1) Выгрузка cf и загрузка в чистую (это уже было тут) 2) Выгрузка dt и загрузка обратно 3)Выгрузка XML и загрузка в чистую созданную с помощью CF 4)Создание образа узла и установка для него что он центральный. Больше я не знаю.

Понял. Погодь. Кажись, была программка, умеющая выдавать физическую структуру БД по метаданным. Счас повспоминаю/пороюсь...

3) Выгрузка в XML - подвисает... -((((

У меня есть... Это внешняя обработка

Что именно не катит? Конфа БД выгружается или это тоже глючит? StrBaseSQL.epf

+ Наверно можно еще извратиться поставить чистую БД из cf. Установить конвертацию данных. Создать правила все возможные. И с помощью этого выгружать /загружать.

Выгружается в CF, но в DT не выгружается...

На крайний случай попробуем

Сейчас родилась сумасшедшая идея... Попробуем...

Озвуч

Конфа БД выгружается в CF и загружается в рабочую (Конфигурация - Загрузить конфигурацию из файла) - можно сделать ТиИ и начинать удалять... Вернусь через пол-часа - час, - сорри

Пробовал - Х/УЙ! 1С:Предприятие вылетает, с ошибкой отправить сообщение в майкрасофт - даже ругнуться не успевает! -))

Попробуй 4 из .Должно.

Я вот не понял как это можно сделать?

Я вот не понял как это можно сделать?

В планах обмена Полный создаешь узел распределенной БД. Потом входишь в эту созданную базу конфигуратором и запускаешь внешнюю обработку УстановитьГлавныйУзел(Неопределено). В итоге новая копия твоей базы. Ее можно в dt

Ок... Сейчас закончу свой эксперимент - если не по прет тогда - по-вашему сделаю...

А свой то озвуч. Мне интересно.

Сейчас у нас физически нет этих таблиц, но есть бэкап, который имеет имена таблиц в SQL, но они (имена таблиц) не верные на конце имеют дописку ng. Пример: _document4990_vt5206ng а 1С:Предприятие при выгрузке .dt файла ругается что не может найти таблицу _document4990_vt5206 (т.е. без ng) и так порядок действий таков: 1) из бэкапа создаю в SQL таблицы - CREATE table - и понеслась - благо с скуэль много работал 2) далее убираю а них дописку ng и пробую выгрузить в файл 1CD всю конфу 3) прохожу выгруженную конфу утилитой chdbfl 4) Загружаю обратно на сервак

Сильно. Получилось?

пробую - обязательно отпишусь -)))

Хорошо что в асемблере не работал:)

Кто сказал ???? =))))

Вот только не могу найти как выгрузить конфигурацию в файл формата 1CD ??

Так в чем проблема? Смотрим, какая должна быть структура недостающей хни и создаем её.

в явном виде ссылка на документ может и отсутствовать - попробуй заменить тип ДокументСсылка на конкретные типы без вирусного документа

для этого надо выгрузить в 1см8.dt, создать ситую в файле и залить дтшник

я так понимаю ты обновился и у тебя началась такая фигня?

нее.. Жто произошло после залития новых доков из хранилища... или что ты имел ввиду под - обновился?

Ок спасибо... А как потом опять перенести в .dt из .1CD ?

выгрузить так же :))

я имею ввиду платформу на 13 не обновляли?

Обновляли! У нас сейчас самая последняя стоит 1С:Предприятие 8.1 (8.1.13.41) А что в этом глюк - кстати знаю еще один конкретный глюк платформы - но ни как не могу написать в 1С...

я заметил это у многих, да и сам столкнулся. У меня была запара на СФвыданных, точнее на её проводках 76.АВ, везде где фигурировал 76.АВ валило 1Ску, молча. Ошибка другая правда, но диагноз тот же. просто перед тем как обновиться, расправел все СФ, закрытие месяца, книгу и т.д. потом только обновлял, вроде пока фурычит. Правда после обновления он мне все СФ убил нахрен собака :)

ЖЕСТЬ! Вот за это я и не люблю 1С - кривота. Я раньше с банковским бэкофисом работал - системки покруче были! А здесь как из говна и пыли все слепили...

тоже хотел скулем, как ты кстати, почикать, ан нет, не получиться, даже не парься.

Я сегодня не такой как вчера - Я вчера был ростом выше на метр И в плечах гораздо шире был я, Да и был шишками покрыт, словно кедр...

Затвра тоже сильно я изменюсь - Буду я горбатый и с бородой, Вот такой я, понимаете, гусь, Вот такой вот я мужик заводной...

-)))) Стебайтесь - стебайтесь а я все-равно все сделаю -)))

Я думаю все будет - ОК!

Я не хвастаюсь вам, но у меня Изменяется набор хромосом Лишь намедни я был белым конем, А сегодня я - Буденный на нем! Но не я один на свете таков Нынче может измениться любой А вот припрется к вам сейчас unTonee - Вы, ведь, хрен поймете кто он такой...

Жил в Москве один товарищ, Трубку крепкую курил Вот и умер, потому что За здоровьем не следил...

А как вы вышли из сложившейся ситуации ?

поподробнее...

см

Полёт - нормальный! Уже chdbfl проверяет 1CD файл! УРА!

Проверка окончена - идет выгрузка в .dt файл -)

рано радуешься,chdbfl может сказать что ошибок не обнаружено, а диагноз останется :)

Да ладноо... -(((

посодют, всех вас нах посодют...

Как дела? Проверка структуры chdbfl, имхо, не помогла сбойные данные восстановить?

Вроде все - ок. Возможно действительно chdbfl и не помогла, ща проверю - что и как...