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

Доброго времени суток.

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

Кто встречался с таким, подскажите как можно решить эту проблему?
Предполагаю варианты:
Есть ли возможность через ODBC записывать данные в таблицы SQL? Или может какие другие есть легкие способы решить эту проблему?

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

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

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

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

Выгрузка и загрузка есть известное решение проблем кривых данных
Окей, кривые данные у меня слетели, но мне они нужны!!!

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

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

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

Вот по этой статье:
https://mudritskiy.blogspot.com/2013/05/1-adodb.html
Организовал универсальный перенос данных из DBF в SQL.
База большая, как перенесутся данные таблицы по итогам отпишусь решило это мою проблемку или нет.

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

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

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

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

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

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

ADOSoedinenie  = New COMОбъект("ADODB.Connection");
И (не знаю как ее назвать 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 файла.

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

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

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

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

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