v7: Замена ссылок в движениях регистров(в таблицах DBF)

Добрый день!
Подскажите, есть какой-нибудь инструмент(обработка), для замены ссылок на элементы справочника в таблицах регистров - ? Естественно, без перепроведения.
Зачем, и насколько это "чревато", я себе отчет отдаю, и понимаю, что делаю...
Руками, редактором DBF я это делаю спокойно, и результат вполне приемлемый. Но, это когда 1-2 косяка надо поправить(минимум в трех табличках RA, и потом пересчет регистров, что-бы RG выправились), когда их несколько десятков, то это становится нетривиальной задачей.
Есть куча обработок, вот например: http://catalog.mista.ru/public/77355/ Судя по описанию, это именно то, что мне надо. Но!!! Она, как и все остальные, которые мне удалось найти - под SQL. Нужно что-то аналогичное под DBF. Существует такое? Под прямые запросы, или под SQLLite - ? Если есть у кого - поделитесь плиз...

В общем, решил сделать как в (1) советуют...
Но, сказывается недостаток(точнее, полное отсутствие) опыта работы с 1C SQL...
Сегодня пол дня потратил, что-бы разобраться, как поднять SQL сервер... Разобрался, поставил 2008 экспресс(честно сказать, еще те пляски с бубном), секретный релиз 1С... Вроде, работает.
Но, почему-то при загрузке базы, где-то ближе к концу, падает... Две попытки не увенчались успехом. Сейчас, тестирую базу 1С DBF, из которой выгружал... Но, сомневаюсь, что это поможет, скорее всего проблема на стороне загрузки...

+(4) Спецы по работе с базами 1С SQL, подскажите...
Предпринял с десяток попыток загрузить в SQL, все время падает при загрузке, вот так: https://content.foto.my.mail.ru/mail/m_w_w/_mypagephoto/h-338.jpg
Подскажите, где чего посмотреть, что-бы определиться с причиной?

Есть предположение, что падает из-за недостатка памяти(х86, не смотря на то, что ее 8 гиг, видится только 3.5)...

Но, смущает, что падает всегда на одном месте - как доходит до загрузки дока ВозврАлк, так вылетает... Других документов перед этим куча загружается, все нормально... Может есть какая-то особенность в данных для SQL? Посмотрел этот документ сейчас... Ничего такого в нем нет, один только реквизит ТЧ стремный - "Марка", строка 68 символов... Ну, и что такого?  DBF такое переваривает нормально...

Может я что-то в SQL сервере недонастроил?

Или все-таки "доктор сказал - в морг, значит в морг!" :-( , и такую задачу можно только на компе с виндой х64 решить?

(12) Вот, я это и спрашиваю... В каких конкретно логах смотреть, где они лежат?
(13) Чем? Файл DAT 875 мб, его даже Notepad++ не открывает, говорит, слишком большой...
(15), (16) Да нет там в шапке ничего такого... Даже общий реквизит "Комментарий", он штатно в ТиС, на основе которой сделана эта конфа, неограниченной длинны, я в этот документ не вставлял, он не нужен.

В MLG 4 строчки:

20201006;10:24:54;;C;Sys;OpenSession;0;НОВЫЙ СЕАНС : Компьютер MOY(m);;
20201006;10:28:05;;C;UpDown;UpDownUplFromFile;1;D:\Basa_1C\Самвел\bbbb.zip;;
20201006;10:33:48;Администратор;C;Sys;OpenSession;0;НОВЫЙ СЕАНС : Компьютер MOY(m);;
20201006;10:34:13;Администратор;C;UpDown;UpDownUplFromFile;1;D:\Basa_1C\Самвел\bbbb.zip;;

Ни о чем... А где еще логи какие смотреть, я не знаю...

(20) Ну, ЖР я показал выше - там 4 строчки всего...

А через менеджмент студию, сейчас посмотрю... SQL 2008.

Ну, хоть убейся, не могу найти где посмотреть...
Единственное, что нашел - https://content.foto.my.mail.ru/mail/m_w_w/_mypagephoto/h-339.jpg
Но, там ничего интересного нет... Так, всякие подключения/отключения...

(23) 10.39.07 - По дурналу винды видно: https://content.foto.my.mail.ru/mail/m_w_w/_mypagephoto/h-340.jpg

(24) Вот мне почему-то тоже так кажется.

DD: https://cloud.mail.ru/public/3a9N/2Nmo7WLVD а это DDS: https://cloud.mail.ru/public/4Vuk/2tq3yeKnp до кучи...

+(26) дурналу = журналу... Промахнулся пальцем, клавиши рядом :-)))

+(26) - (24) Вот мне почему-то тоже так кажется.

И все-таки похоже падает на загрузке документа "ВозврАлк". При чем, не первого, а второго...
Вот ОбщийЖурнал с отбором по этому документу:
В базе DBF: https://content.foto.my.mail.ru/mail/m_w_w/_mypagephoto/h-342.jpg
В "недозагруженной", но при этом открывающейся базе SQL: https://content.foto.my.mail.ru/mail/m_w_w/_mypagephoto/h-341.jpg

(30) Да, поля длиной по максимуму... Но, тем не менее, справочники загрузились нормально, и номенклатура с длинным наименованием ЕГАИС, производители с длинным адресом.
Вот, первая попавщаяся карточка номенклатуры с длинным именем, скриншот из "недозагруженной" базы SQL: https://content.foto.my.mail.ru/mail/m_w_w/_mypagephoto/h-343.jpg

(31) Да, загрузилась, там одна строка всего, и в исходной базе то-же.

Смущает меня немного другое... Вот скриншот общего журнала "с испокон веков": https://content.foto.my.mail.ru/mail/m_w_w/_mypagephoto/h-345.jpg в исходной базе.
А вот то-же самое в новой: https://content.foto.my.mail.ru/mail/m_w_w/_mypagephoto/h-344.jpg

Нет первого в системе документа. Это "хитрый" документ, без табличной части, без модуля проведения, просто при обрезке базы на него ссылки из регистров идут, типа он движения сделал, а на самом деле прямыми запросами итоги перенесены на начало периода со ссылкой на него.
Вот он почему-то не перенесся. Странно... Хотя, ТиИ исходной базы проходит нормально, не трогает этот документ, и итоги по регистрам не плывут, все вроде хорошо, логическая целостность не нарушена...
Сейчас решил посмотреть на него в ДД, и не обнаружил его там, совсем... Но, он есть! Как так может быть, х.з...
Вот он в конфигураторе: https://content.foto.my.mail.ru/mail/m_w_w/_mypagephoto/h-346.jpg

(35) В смысле? Как его передвинуть? Номера поменять местами в исходной базе, до выгрузки? Можно попробовать, обработку надо написать по быстрому, что-бы это программно сделать, без перепроведения и нарушения последовательности...
Или что-то другое имеется в виду?

(37) В исходной базе, до выгрузки?

(38) Оба журнала с "испокон веков", без отборов. См. какой первый документ в исходной базе и в SQL.

Кого нет? Я сейча говорю об другом документе "СверткаИБ", его нет в журнале новой базы.

(42) Может. Может до него "очередь не дошла". Смущает, что упоминания о нем нет в DD...

Может его там и не должно быть, так, нет ни одного реквизита, ни в шапке, ни в ТЧ(точнее, ее совсем нет)? Добавить в него "фиктивный" реквизит, может тогда появится в DD и перенесется в SQL?

(44) Ну, да. Может на нем перенос "спотыкается"-?

(48) Чем его просмотреть? dat файл объемом 875 мб, чем его открыть? Notepad++ не хочет открывать, говорит слишком большой.

ВозврАлк двигает один регистр - ДвижМарок. Он не входит в ОсновнуюПоследовательность. Я так понимаю, дату в нем можно поменять безболезненно?

Поменял, он ругнулся, что последовательность будет нарушена(странно, почему?) но не нарушил. Осталась актуальная.
Конечно на копии. Эта база "на поиграться", так сказать, "отладить процесс", в реальной базе они сейчас работают. Когда разберусь с темой сабжа, все равно новую базу буду брать, "на ночь" :-)

Фар умеет такие файлы просматривать? Не знал, сейчас попробую...

+(51) Все проделал. Падает на следующем документе того-же вида, номер 2, от 06.11.19. Тот, который был под номером 1, перенес в 10.11.19, теперь до него и не доходит.
Вот картинка из общего журнала с отбором по виду документа: https://content.foto.my.mail.ru/mail/m_w_w/_mypagephoto/h-348.jpg

(56) Нет, ручной подмены МД не было, это точно. Я с головой пока дружу, а кроме меня в этой базе никто не работает.

Движения у документов, которые перенеслись, есть, вот только отчет "ОстаткиТоваров" почему-то пустой: https://content.foto.my.mail.ru/mail/m_w_w/_mypagephoto/h-349.jpg
У того документа, на котором спотыкается, тоже движение по регистру "ДвижениеМарок" есть.
Похоже до пересчета регистров, просто дело не дошло, и таблички RG по таблицам RA не создались, а отчет из итогов регистров(RG) данные тянет.

(57) Ну, по теме сабжа, наверное да, так будет правильнее. Но, смущает "недоделанность" перехода на SQL. Уже даже просто интересно, почему не получается, да и на будущее, мало ли когда и зачем может понадобиться.

+(59) Да, все именно так и есть, ведомость показывает движения без остатков: https://content.foto.my.mail.ru/mail/m_w_w/_mypagephoto/h-350.jpg

(61) Да, я выше так и написал, с картинкой :-)

Сейчас попробую аналогичную базу другого клиента так перенести, она по меньше, но структура аналогичная, и там свертки(и соответствующего документа) не было, хотя документ в метаданных присутствует.

(63) Ну, мне то еще хуже - "трудно вспоминать, когда не знал, да еще и забыл" :-)))

Кстати, вопрос - в SQL-сервере, нужно отдельную базу создавать для отдельной базы 1С, или просто из 1С добавить базу? Просто не знаю, как это устроено...

Не знаю, правильно или нет, создал новую. Сейчас загружается. Это место проскочило нормально, уже ссылки пересчитывает. Думаю - загрузится.
Что-то в этой базе(сабжевой) не так... Все-таки, наверное со сверткой связано, движения регистров есть, а ссылки из них идут на документ, который отсутствует в словаре метаданных, ну... Или все-таки с размером базы.

Попробовать сделать как в (45) писал? Добавить "фиктивный реквизит", что-бы док в DD прописался?

+(66) Думаю - загрузится.
Загрузилась. В "лучшем виде", как там и была. Правда, из под конфигуратора не получилось запустить в режиме "Предприятие", ругается, что только один пользователь может работать, но, это сейчас не важно, потом разберусь, видимо что-то в SQL сервере недонастроил. Но, сам факт...
Надо пробовать с документом свертки разбираться.

(69) В словаре нет вообще упоминания о нем. Хотя в метаданных он есть. Как оно там работает при переносе, может на словарь смотрит, х.з....

Но, тем не менее. Создал реквизит, док появился в DD. Выгрузил базу, сейчас загружается. Это ПРОБЛЕМНОЕ место - проскочил, думаю загрузится.

(72) Это свертка виновата :-)  Ты на меня уже в соседней ветке ругался за нее, вот похоже и акунулось... Сейчас грузится, все нормально...
Выгрузку какую дать, которая с "кривым", отсутствующем в словаре метаданных документом?

(73) А смысл - не охота было обработку писать под сабж. Да заодно и "потренироваться" работе с базами SQL. А то даже стыдно - вроде и опыт в 7.7 не малый, а базу SQL только вчера в живую "пощупал" :-)

+(76) думаю загрузится
Загрузилась, идеально.

(78) Знаю. Но, это сделано специально - отвязать(разорвать) ссылочную целостность, что-бы можно было безболезненно удалять марки, когда уже проданы, что-бы справочник не разбухал.
(80) Не облом. Для старых - код 68 символов содержится, для новых только серия и номер.

В личку на инфостарте скинул ссылку нв выгрузку.

(86) Сами марки, с полным кодом в справочнике марки, в нем реквизт длиной 150 символов. Делал давно, ещё тогда, когда о новых марках никто и не слышал.хватало для 68 симвсимволов и наименования. Когда появились новые, 150, добавил реквизит. А в наименовании для старых храню шк, для новых только серию и номер.
Когда марка продана или списана, удаляю ее из справочника регламентнрй обработкой, перепровелением по регистру "ДвижениеМарок", сами документы движения при этом остаются, так, как ссылок нет - связь со справочникам по текстовым полям. Поиск по справочнику пори лбой необходимости, из документов движения например, осуществляется с помощью SQLlite.

По сути, в моем решении, справочник Марки, это как-бы внешняя, отдельео-живцщая база данных, но внутри основной. Когда появился подарочный учёт, активно обсуждалось, где хранить все это безобразие - ведь по сути, каждая марка это должен быть элемент справочника, а их проходят миллионы за год... Как справочник разбухнет... Кто-то предлагал хранить во внешних бызах, типа MySQL и т.п., я же решил сделать "внешнюю базу" на справочнике 1С. Поэтому и такая структура базы, что марки в полях табличных частей документов хранятся, без ссылок на справочник. Спорное решение конечно, но оно работает, и вполне успешно.

Блин, как же не удобно с мобильника писать. Один только "подарочный" вместо "помарочного" учёт чего стоит :-)

(87) Не в курсе. Точнее, пока не столкнулся. Я сейчас не помню, там вроде ещё и тип марки хранится, первые три символа. А эти три поля - тип, серия, номер - уже дают уникальность ключа поиска. Это по сути, кусок от шк марки - сейчас не помню, сколько символов с начала. Доберусь до дома, освежу в памяти

Естественно в других случаях, я так не делаю, никогда. Не совсем идиот, и сам бы настучал указкой(может и чем потяжелее) по рукам за такое... Но, тут, это умышленно сделано, исключительный случай :-)

Ушли от темы сабжа... Попробовал обработкой из (0), супер!
Правда, пришлось закомментировать в ней, все, что с бухгалтерией связано, но это мелочи.
И, после всего пришлось пересчет итогов сделать, т.к. в движениях меняет, а итоги не трогает.
Ну, все равно, результат отличный.
Разово, навести порядок в базе, вполне можно, значительно удобнее, чем ДБФки руками ковырять. На постоянку, такое делать не стоит - за такое пользователей "по рукам линейкой" надо наказывать. Ну, да ладно. Исправлю.
Всем спасибо!
А то, что не грузится в SQL, если есть док, которого нет в словаре метаданных - в мемориз... Будем знать.

+(93) т.к. в движениях меняет, а итоги не трогает.
Ну, это само собой разумеется. Без пересчета итогов, RG и не получить. А обработка меняет ссылки, а не пересчетом занимается. Все правильно.

(98) Ну... У меня контактов куча в профиле. Маякни, с чего-нибудь вменяемого, отправлю ссылку на выгрузку. Не хочу выкладывать в паблик реальную базу клиента. Возможно, тут сложилось несколько причин - и дока нет в ДД, и движения есть со ссылкой(в никуда???) на него.