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

(0) Загрузить базу на sql сервер, провести обработку запросами, выгрузить обратно в DBF.

1с++ и прямые запросы.
Синтаксис - на 1cpp.ru

(0) если разово - был какой-то редактор dbf с sql-подобным языком. поищу дома, но вот хоть убей не помню названия. можно Фокспро поставить.

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

(3) да есть такой, Sdbf.exe

(1) ну-ну

Написать примитивный запрос на update нужных табличек проще всего на vfpoledb, синтаксис не особо и отличаться будет от запроса для mssql.
А если записей много и надо ускорить, то да, надо подобрать ручонкками индекс для where или соединения

как сказано в (7) - взять дбф базу. взять консоль запросов - вроде есть и для дбф.
и лабать прямыми запросами.

даже нафиг не надо никаких консолей.
работа разовая, кропаешь код в обработке и все...

(0) за всю свою долгую практику всего пару раз приходилось делать такое а если у вас это постоянно то тут скорей проблем в учете а не услугах программиста

+(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 решить?

(11) смотри в логе, там может быть зарегестрирована ошибка. Или в логе сиквела

(11) как тупой вариант - вырежь из выгрузки всю секцию с ВозврАлк. Если загрузится - возвращай секцию, удаляй из нее половину доков, грузи... и так половиннным делением, пока не найдешь документ на котором валится

(11) Да, и память тут совершенно ни при чем...

(11) Вспоминаю что строки неограниченной длины не загружались то ли если первая то ли последняя?

(15) это в шапке, строки неогр длины должны быть последними.

ну, что в логах-то?

(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;;

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

(18) ну, в 1с в ЖР. в сиквеле - зависит от версии. вроде начиная с 2008 уже sql managemrnt studio, там уже logs или Журналы ошибок

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

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

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

(22) а загрузка упала во сколько?

(11) Еще может быть что ВозврАлк - это последний успешно обработанный.
А вот следующее за этим действие приводит к краху

dd дай глянуть

(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) дурналу = журналу... Промахнулся пальцем, клавиши рядом :-)))

(27) "дурнал" - тоже неплохо звучит... как Юля Зуева

+(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

(26) https://prnt.sc/utz7a4
вот это кажется страшноватым, но это не точно )

(29) а ТЧ первого дока загрузилась?

(30) общая длина?

(32) за давностью лет не помню, н вроде была рекомендация при переносе dbf-sql строковые реквизиты длиннее N символов предварительно делать неограниченными, потом переносить, потом можно обратно.
Но это, похоже, не случай ТС.

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

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

(34) если передвинуть этот документ "вторым" - следующий загрузится?

Смущает меня немного другое... Вот скриншот общего журнала "с испокон веков": 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) В смысле? Как его передвинуть? Номера поменять местами в исходной базе, до выгрузки? Можно попробовать, обработку надо написать по быстрому, что-бы это программно сделать, без перепроведения и нарушения последовательности...
Или что-то другое имеется в виду?

(36) дату поменять

(36) разницу журналов я не уловил

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

(39) да. Но ты ж говоришь, что его нет?

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

(36) а ,у тебя свертки нет? так может он не переносился еще

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

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

(43) а где ты ожидаешь увидеть его в ДД, что именно о нем, и зачем?
все реквизиты по умолчанию и общие с оттбором - в журнале, шапки нет, табчасти нет....

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

(45) скорее всего, до него просто очередь загрузки не дошла

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

(47) ну просмотреть-то файл выгрузки ты можешь?
с другой стороны, загрузились бы все возвратАлк, а потом споткнулся бы на Свертке

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

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

(49) FAR - просмотрщик, например.
ты ж, надеюсь, на копии делаешь  - ну и меняй как хочешь

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

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

(52) просмотр (f3) - точно, редактирование (f4) наверно тоже

(53) меньше гектара вроде открывал. но жрал дохрена оперативки. больше гектара-падал. Причем это версия для 32 и старая.

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

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

(55) Делай на 1c++.

(55) движения перенеслись?

(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

(59) отчет пустой потому, что движения перенеслись, а остатки не пересчитаны

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

(59) просто в логах должна быть ошибка. блин, облазил - не помню где

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

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

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

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

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

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

(65) нужно отдельно

(66) почему ты считаешь, что он отсутствует в метаданных? просто _в_словаре_ нет _дополнительных_ реквизитов (окромя даты-времени-номера, и общих с отбором) этого документа.

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

(70) словарь оно смотрит при создании таблиц для дополнительных реквизитов документов. iddocdef в базе не хранится, он лежит в md.

(0) дай выгрузку посмотреть

а так, непонятен вообще смысл перевода столь маленькой базы на sql

еще и экспресс

(73) "нас невозможно сбить с пути - нам по**ю куда идти"©

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

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

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

(73) ТС написал же - практика на будущее

Посмотрел словарик - полный ПЭ..

Нахрена все реквизиты пихать в тч каждого дока строками ? Загадка.
Когда достаточно запихать туда только 1 реквизит - Алкогольнаяпродукция с типом Справочник, в котором будут реквизиты производителя импортера и прочая хрень
+ 1 реквизит - марка, тип справочник.
Всё.

Стальной линейкой надо по пальчикам

Да и то, судя по словарю.. с новой маркой - облом. она же 150, а не 68...))
Т.е не работают

В лучшем случае. конфа под пиво..и то, через жпо

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

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

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

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

(83) на нимфостарте я забанен..давно. Считай, меня там нет

Эти клоуны там только надпись об этом потёрли, чтоб сдыно не было

(83) и какой смысл от серии и номера, если самой марки нет ? Если возврат, например, списать.. всё, приплыли ?

И да.. ты в курсе, что номер марки, который на самой марке напечатан (на новой) оне не уникален ни разу ? :)))

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

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

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

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

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

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

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

(93) Быстрее было переписать обработку под прямой запрос в дбф. Это отработало бы еще быстрее, чем в скуле.

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

(96) что злой то такой? )

(93) "А то, что не грузится в SQL, если есть док, которого нет в словаре метаданных - в мемориз... Будем знать"


Я вот сегодня смоделировал такую ситуацию. И у меня без краша грузанулось в сиквел

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

(99) извини, но я пас

(98) скорее всего, там много чего отсутствовало в словарике... надо словарик было сравнить до и после

(100) !!! :-)

Тут похоже, как а авиакатастрофах - никакая одна причина не могла привести к ней... Но, когда их несколько - совокупность приводит к катастрофе. Так, похоже и тут - складывается отсутствие документа в словаре, и ссылки на него из движений. Отсюда и краш. Убрал одну - добавил док в ДД, и крашиться перестало. Ну, чудес не бывает - до этого, я раз десять грузил, бесполезно. И вторая причина - загрузил базу с DD в котором нет упоминания на этот док, но и самого дока в данных не было, соответственно ссылок из движений на него, тоже все загрузилось. Как-то так.

(101) Ну, сравнил... До, есть выше, после - вот: https://cloud.mail.ru/public/2Cso/37CyWf8tG

Ничего такого нет. Только номера таблиц сдвинулись на единицу, начиная с этого дока...

(98): там вполне вероятно, что крах не просто из-за отсутствия в словаре данных, а из-за возникновения ситуации, в которой в данных есть и документ, отсутствующий в словаре, и (sic!) движения по нему.