v7: Не все данные из 1С 7.7 загружаются в SQL базу. #784038

Доброго времени суток. Подскажите пожалуйста как лучше, а главное легче решить одну проблемку. Есть  база 7.7 на dbf нужно перевести на SQL. При выгрузки загрузки садятся не все данные. Открыл таблицу регистров накопления, которая загружена в SQL там записи почему-то только с 2016г. А в DBF файле горазда больше записей года так с 2005. Причем это не обязательно SQL, если просто сделать выгрузку и загрузку в другую DBF базу эффект получается такой же. А вот если сделать сохранить данные и восстановить данные то переносятся вся информация корректно. Знаю только что предыдущий умелец как то резал базу, как уж он это делал не знаю и что именно он делал тоже не знаю, в итоге сейчас получилась такая вот проблемка. P.S. Сразу говорю предыдущего умельца не отыскать. Кто встречался с таким, подскажите как можно решить эту проблему? Предполагаю варианты: Есть ли возможность через ODBC записывать данные в таблицы SQL? Или может какие другие есть легкие способы решить эту проблему?

попробуйте ТА двинуть туда-обратно

+ без перепроведения

Сомневаюсь что если есть записи регистров без документах регистратора - вряд ли эти записи будут ВЫГРУЖЕНЫВыгрузка и загрузка есть известное решение проблем кривых данных

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

так после загрузки в новую базу, кроме того, что визуально невозможно обнаружить данные за прошлые года, наблюдается нарушение итогов или остатки на начало 2016 испорчены?

Да остатки на начало на начало 2016 испорчены.

ТА слетела на начало 2016г. И обратно не возвращается.

Не не сильный, раз с таким впервые встретился. Да и с 7.7 уже двести лет не работал. Записи регистра я то могу получить и путем перебора самой dbf таблицы. Вопрос в том как их в SQL запихнуть. С SQL я знаком только на этапе разработки элементарных запросов что бы получить от туда данные, а вот записывать не приходилось. Хотелось бы знать возможно ли это в принципе и с помощью чего, что бы хотя-бы направление куда копать выбрать.

Сомневаюсь что если есть записи регистров без документах регистратора - вряд ли эти записи будут ВЫГРУЖЕНЫ Да так и есть. Выгрузка и загрузка есть известное решение проблем кривых данных Окей, кривые данные у меня слетели, но мне они нужны!!!

В дополнении, таблица которая не выгружается "RG" - т.е. таблица в которой хранятся рассчитанные итоги. А в самом регистре движений данные только за 2016г. Получается сторонними средствами данные до 2016 г. очистили, оставили только итоги.

похоже все же ответ в

Результат ТИИ?

Если движения только за 2016 год то как он мне итоги за 2005 год востановит?

вопрос: ты пишешь про таблицы, файлы, записи. А как в самой 1-ске, видны ли в исходной базе документы, элементы справочников, которые не попадают в базу, полученную выгрузкой-загрузкой?

ну если данных уже нет... остатки из старой базы сохранить обработкой на начало 01.01.16, а затем загрузить - лучше не сделаешь. кто базу резал, тот срезал мастерски. Архив перед срезкой прошлых лет куда дели? Может для пользователей будет интересен просмотр прошлых лет из восстановленной той базы архивной, а эту уже не мучить больше, чем она сможет дать. Остатки перевыставить обработкой и все.

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

При переходе на SQL платформа пересчитывает итоги. Поэтому программе глубоко все равно, что там перенеслось. Заново все пересчитает.

Нужно разбираться, как урезалась база. И где хранятся данные по остаткам.

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

Вот по этой статье: Организовал универсальный перенос данных из DBF в SQL. База большая, как перенесутся данные таблицы по итогам отпишусь решило это мою проблемку или нет.

чувак зафиксировал остатки одним из 100500 существующих "двигателей регистров", и почистил "задние движения". а может, и не почистил, а "поправил как надо".

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

Просто ввели итоги обычной записью в RG  и удалили старые периоды. При выгрузке в 1с-ине, итоги не выгружаются от слова совсем, только движения документов. Итоги потом рассчитываются с нуля. У автора, нет документа, толкнувшего останки, есть только итоги. Подобная поделка валялась на нимфостарте в качестве свёртки.

Решение - либо прямым запросом затолкать в скуль , либо снять останки в дбф и только их перегнать. В общем, ничего сложного

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

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

ну, я об этом говорил в своё время, но не все слушают/думают над последствиями

а кто делал "гранату для обезьяны"? :-)))

о_О

, Вопрос к знающим. Как еще можно оптимально загрузить данные из DBF в SQl. Сейчас я сделал обработку которая просто перебирает таблицу DBF и по одной записи заносит их в SQL. первые миллион записей зашли довольно резво, но потом все хуже и хуже. Короче таблица в 900мб с примерно 6-7 млн. записей заходит сутки. А у меня таких 7. Не думаю что это то решение которое ждет клиент. Как можно ускорить этот процесс?

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

А как определить в тормаза в темпдб? Или только методом проб и ошибок? Одна таблица загрузится до конца, попробую реконнект настроить, тем более я и журнал регистрации в 1С 8 забыл отключить, тоже наверное какие никакие тормоза. P.S. Из перебоев света и прочее пришлось в 1С 8 добавить регистр сведений где храню информацию о последней удачной записи в SQL что бы в случае перебоя не начинать все заново и не искать ручками где остановился.

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

В SQl как то это возможно? Я просто с SQL вообще можно сказать ламер.

может, и из-за индексов. я вообще не знаю, что вы там делаете, в клюшках или снеговике, что подразумеваете под "в SQL" и т.п.

нормальная поделка - и в качестве свертки там делались движения регистра на документ СвёрткаИБ если мне память не изменяет, внедренный в базу и не имеющий модуля проведения (хотя все движения) вешались на него - так вот ПОСЛЕ двиганья ТА тудой обратно- эта свертка благополучно полетит в тар тарары

Клюшки? Снеговики? SQL 2005. Выгрузил базу 7.7, как обычно загрузил ее в SQL стандартными методами 1C 7.7. Недостающие таблицы пытаюсь до заполнить. Для этого написал скрипт (но уже в 1С 8, так как она мне стала роднее) который просто открывает DBF таблицу, перебирает все записи и по одной грузит их в SQL. Для этого я использую SQL соединение: И (не знаю как ее назвать SQL команду) Command = New COMObject("ADODB.Command"); Формирую запрос для этой команды что то вроде: INSERT INTO [v77].[dbo].[RG1207](PERIOD, SP1208, SP1209, SP1210) VALUES ( Convert(datetime,'01/08/2016',103),'   LTK1  ','  2N  OGM51  ',convert(numeric(20,2),0)) И выполняю его. И так для каждой строки DBF файла.

ЗЫ связи таблиц в  7.7 знаемо ? не проще как советовали запустить на копии 1с 77 ТА в режиме восстановления данных ? ЗЫЫ может бросить эту затею ?? и поискать архив ДО обрезания

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

зачет ага. Зачем тебе вообще перенос rg, еще и таким неверным способом ?

особенно, все останки вешать на одну дату- это вообще креатив :)))

А DBF я перебираю потому что мне так веселе садить что бы вешать остатки на одну дату!!! Все данные я беру с DBF и по ее аналогу заполняю таблицу в SQL. Ок. Посоветуй как именно мне ее перенести. Таблица RA обрезана, там нет данных за 2005 и т.д. лет. Лубой способ расчитать итоги по таблице RA приведет к провалу! Да путем несложного анализа понял что таким успехом я буду 7 дней переносить эти таблицы. Вот и думаю как это ускорить. И какие же там связи в таблице 77?? Не знаемо конечно, но проверяемо, сначала я таким методом перенес табличную часть одного вида документа и как не странно все перенеслось. Поэтому смею надеяться что и итоги тоже перенесутся.

Да ё. Если не можешь прямым запросом перенести итоги, то в дбф базе лепишь универсалный документ. Пихаешь в него итоги регистра на нужную дату, переносишь его в новую базу, проводишь. Усё

Или просто прямым запросом получаешь в дбф базе итоги регистра на определенную дату и пихаешь инсертом их в sql базу.

лучше - документ

+45 создать его прям в семерочной базе, и прям из итогов заполнить и провести. итоги, конечно, задвоятся. но потом пересчитать, и переностить штатно

, , , С этим я конечно согласен. Но надо это согласовать с клиентом (т.к. сейчас он при таком раскладе может получить отчеты за старые периоды) а вот при обрезки базы по человечески он уже этого не получит. Но это еще не все. Я уже 200 лет не работал в 7.7 да и когда работал приходилось работать только с регистром бухгалтерии. Поэтому я тупо пока не знаю как реализовать такой документ. По видимому нужно на каждый регистр создавать такой универсальный документ? Т.к. табличных частей там всего одна да и у нее есть ограничение в размере 9999.

Или в принципе сделать это все одним документом, просто при проведении загрузить все остатки в регистр. И потом запретить какое либо открытие и проведение этого документа в будущем.

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

но вот нафига "на каждый регистр" или "много табчастей" - я даже сообразить не могу...

Может завалялась такая? Поищу наверное лучше пойду этим путем. Побаловался и хватит.

да хоть хоть хоть

Спс. Их действительно миллион.

Вот этот влепи документ

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

плюс большие количества разбивает на документы-порции

"мам, ну купи слона..."©

Ты же сам на свой вопрос ответил. Кто-то как-то резал. Вот и нарезал в файлах регистров фсякой фигни. Ну с другой дбф все ясно. А вот как в скуль грузим не ясно. в скуль созранить и восттановить не зя. выгрузка и загрузка. все работай.