Вход | Регистрация


1С:Предприятие :: 1С:Предприятие 7.7 и ранее

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

v7: Не все данные из 1С 7.7 загружаются в SQL базу.
Я
   FoXSkr
 
29.10.16 - 17:52
Доброго времени суток.

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

Кто встречался с таким, подскажите как можно решить эту проблему?
Предполагаю варианты:
Есть ли возможность через ODBC записывать данные в таблицы SQL? Или может какие другие есть легкие способы решить эту проблему?
 
 
   dmitryds
 
1 - 29.10.16 - 18:02
(0) попробуйте ТА двинуть туда-обратно
   dmitryds
 
2 - 29.10.16 - 18:02
(1) + без перепроведения
   Злопчинский
 
3 - 29.10.16 - 18:05
Сомневаюсь что если есть записи регистров без документах регистратора - вряд ли эти записи будут ВЫГРУЖЕНЫ

Выгрузка и загрузка есть известное решение проблем кривых данных
   Злопчинский
 
4 - 29.10.16 - 18:07
(0) ты видать сильный умелец - дерни обычным запросом из одноэс данные по документам, которые двинулись регистр в 2005 году
   Фрэнки
 
5 - 29.10.16 - 19:43
так после загрузки в новую базу, кроме того, что визуально невозможно обнаружить данные за прошлые года, наблюдается нарушение итогов или остатки на начало 2016 испорчены?
   FoXSkr
 
6 - 29.10.16 - 19:47
(5) Да остатки на начало на начало 2016 испорчены.
   FoXSkr
 
7 - 29.10.16 - 19:48
(1) (2) ТА слетела на начало 2016г. И обратно не возвращается.
   FoXSkr
 
8 - 29.10.16 - 19:54
(4) Не не сильный, раз с таким впервые встретился. Да и с 7.7 уже двести лет не работал.
Записи регистра я то могу получить и путем перебора самой dbf таблицы. Вопрос в том как их в SQL запихнуть. С SQL я знаком только на этапе разработки элементарных запросов что бы получить от туда данные, а вот записывать не приходилось. Хотелось бы знать возможно ли это в принципе и с помощью чего, что бы хотя-бы направление куда копать выбрать.
   FoXSkr
 
9 - 29.10.16 - 19:57
(3)Сомневаюсь что если есть записи регистров без документах регистратора - вряд ли эти записи будут ВЫГРУЖЕНЫ
Да так и есть.

Выгрузка и загрузка есть известное решение проблем кривых данных
Окей, кривые данные у меня слетели, но мне они нужны!!!
   FoXSkr
 
10 - 29.10.16 - 22:24
(0) В дополнении, таблица которая не выгружается "RG" - т.е. таблица в которой хранятся рассчитанные итоги.
А в самом регистре движений данные только за 2016г.
Получается сторонними средствами данные до 2016 г. очистили, оставили только итоги.
 
 Рекламное место пустует
   dmitryds
 
11 - 29.10.16 - 22:42
(10) похоже все же ответ в (1)
   АНДР
 
12 - 29.10.16 - 22:53
Результат ТИИ?
   FoXSkr
 
13 - 29.10.16 - 22:53
(11) Если движения только за 2016 год то как он мне итоги за 2005 год востановит?
   lvz
 
14 - 29.10.16 - 23:08
(0) вопрос: ты пишешь про таблицы, файлы, записи. А как в самой 1-ске, видны ли в исходной базе документы, элементы справочников, которые не попадают в базу, полученную выгрузкой-загрузкой?
   Фрэнки
 
15 - 29.10.16 - 23:29
(13) ну если данных уже нет... остатки из старой базы сохранить обработкой на начало 01.01.16, а затем загрузить - лучше не сделаешь. кто базу резал, тот срезал мастерски. Архив перед срезкой прошлых лет куда дели? Может для пользователей будет интересен просмотр прошлых лет из восстановленной той базы архивной, а эту уже не мучить больше, чем она сможет дать. Остатки перевыставить обработкой и все.
   FoXSkr
 
16 - 30.10.16 - 05:11
(14) Справочники, и документы перенеслись корректно. Не перенеслись рассчитанные итоги по регистрам. Скоре всего 1С их и не переносит т.к. считает что это лишняя информация т.к. итоги можно потом рассчитать по таблице движений регистра. А вот рассчитать она их не может т.к. таблица движений уже обрезана.
   VladZ
 
17 - 30.10.16 - 05:51
(16) При переходе на SQL платформа пересчитывает итоги. Поэтому программе глубоко все равно, что там перенеслось. Заново все пересчитает.
   VladZ
 
18 - 30.10.16 - 05:55
Нужно разбираться, как урезалась база. И где хранятся данные по остаткам.
   torgm
 
19 - 30.10.16 - 10:13
Ну что я могу сказать, приплыли. Самый простой вариант, создать документ вводданныхостатков регистров. Заполнить на конец 15 года, и перенести , по крайней остатки будут верными, а затем если надо также создаёшь документ движения регистра и заполняешь по предыдущему переоду и также переносишь.
   FoXSkr
 
20 - 31.10.16 - 10:40
Вот по этой статье:
https://mudritskiy.blogspot.com/2013/05/1-adodb.html
Организовал универсальный перенос данных из DBF в SQL.
База большая, как перенесутся данные таблицы по итогам отпишусь решило это мою проблемку или нет.
   Это_mike
 
21 - 31.10.16 - 11:09
(18) чувак зафиксировал остатки одним из 100500 существующих "двигателей регистров", и почистил "задние движения". а может, и не почистил, а "поправил как надо".
   FoXSkr
 
22 - 31.10.16 - 11:33
(21) Так и было. Поэтому рассчитанные итоги это их все. Не дай бог кому-то вздумается их пересчитать.
   Ёпрст
 
23 - 31.10.16 - 11:38
Просто ввели итоги обычной записью в RG  и удалили старые периоды.
При выгрузке в 1с-ине, итоги не выгружаются от слова совсем, только движения документов. Итоги потом рассчитываются с нуля.
У автора, нет документа, толкнувшего останки, есть только итоги. Подобная поделка валялась на нимфостарте в качестве свёртки.
   Ёпрст
 
24 - 31.10.16 - 11:38
Решение - либо прямым запросом затолкать в скуль , либо снять останки в дбф и только их перегнать.
В общем, ничего сложного
   Это_mike
 
25 - 31.10.16 - 11:43
(23) это не самое правильное решение - бездокументарная запись.
Но соглашусь с (24) - ничего сложного
   Это_mike
 
26 - 31.10.16 - 11:43
(22) и нефиг их пересчитываать.
Для выборочного пересчета есть куча про цедур
   Ёпрст
 
27 - 31.10.16 - 11:44
(25) ну, я об этом говорил в своё время, но не все слушают/думают над последствиями
   Это_mike
 
28 - 31.10.16 - 11:48
(27) а кто делал "гранату для обезьяны"? :-)))
   Ёпрст
 
29 - 31.10.16 - 12:12
(28) о_О
   FoXSkr
 
30 - 02.11.16 - 06:21
(24), (25)
Вопрос к знающим. Как еще можно оптимально загрузить данные из DBF в SQl. Сейчас я сделал обработку которая просто перебирает таблицу DBF и по одной записи заносит их в SQL. первые миллион записей зашли довольно резво, но потом все хуже и хуже. Короче таблица в 900мб с примерно 6-7 млн. записей заходит сутки. А у меня таких 7. Не думаю что это то решение которое ждет клиент. Как можно ускорить этот процесс?
   Это_mike
 
31 - 02.11.16 - 07:23
(30) ну, во-первых, можно грузить данные напрямую из дбф в сиквел через дата трансформэйшн сервис (или аналоги в поздних версиях сиквела)
во-вторых, многое зависит от режима базы на сиквеле
в третьих, неясно, где тормоза. если в темдб, то можно реконнектится изредка.
ну и т.д.
   FoXSkr
 
32 - 02.11.16 - 08:45
(31) А как определить в тормаза в темпдб? Или только методом проб и ошибок?
Одна таблица загрузится до конца, попробую реконнект настроить, тем более я и журнал регистрации в 1С 8 забыл отключить, тоже наверное какие никакие тормоза.
P.S. Из перебоев света и прочее пришлось в 1С 8 добавить регистр сведений где храню информацию о последней удачной записи в SQL что бы в случае перебоя не начинать все заново и не искать ручками где остановился.
   FoXSkr
 
33 - 02.11.16 - 08:45
Может быть из за индексации (может я сейчас и глупость говорю). Может имеет смысл отключить индексацию, загрузить и потом проиндексировать всю таблицу?
 
 
   FoXSkr
 
34 - 02.11.16 - 08:46
(33) В SQl как то это возможно? Я просто с SQL вообще можно сказать ламер.
   Это_mike
 
35 - 02.11.16 - 09:01
(33) может, и из-за индексов.
я вообще не знаю, что вы там делаете, в клюшках или снеговике, что подразумеваете под "в SQL" и т.п.
   пипец
 
36 - 02.11.16 - 09:35
нормальная поделка - и в качестве свертки (23) там делались движения регистра на документ СвёрткаИБ если мне память не изменяет, внедренный в базу и не имеющий модуля проведения (хотя все движения) вешались на него - так вот ПОСЛЕ двиганья ТА тудой обратно- эта свертка благополучно полетит в тар тарары
   FoXSkr
 
37 - 02.11.16 - 09:35
(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 файла.
   пипец
 
38 - 02.11.16 - 09:40
оййоплина ))))
ЗЫ связи таблиц в  7.7 знаемо ? не проще как советовали запустить на копии 1с 77 ТА в режиме восстановления данных ?
ЗЫЫ может бросить эту затею ?? и поискать архив ДО обрезания
   пипец
 
39 - 02.11.16 - 09:42
(30) ничо не понел из постинга , скуль так и работает с нарастающей большой транзакцией - в чём вопрос та ? убыстрить скуль или чего ?
   Ёпрст
 
40 - 02.11.16 - 09:52
(37) зачет ага. Зачем тебе вообще перенос rg, еще и таким неверным способом ?
   Ёпрст
 
41 - 02.11.16 - 09:54
особенно, все останки вешать на одну дату- это вообще креатив :)))
   FoXSkr
 
42 - 02.11.16 - 10:04
(41) А DBF я перебираю потому что мне так веселе садить что бы вешать остатки на одну дату!!! Все данные я беру с DBF и по ее аналогу заполняю таблицу в SQL.
(30) Ок. Посоветуй как именно мне ее перенести. Таблица RA обрезана, там нет данных за 2005 и т.д. лет. Лубой способ расчитать итоги по таблице RA приведет к провалу!
(39) Да путем несложного анализа понял что таким успехом я буду 7 дней переносить эти таблицы. Вот и думаю как это ускорить.
(38) И какие же там связи в таблице 77?? Не знаемо конечно, но проверяемо, сначала я таким методом перенес табличную часть одного вида документа и как не странно все перенеслось. Поэтому смею надеяться что и итоги тоже перенесутся.
   Ёпрст
 
43 - 02.11.16 - 10:09
Да ё.
Если не можешь прямым запросом перенести итоги, то в дбф базе лепишь универсалный документ. Пихаешь в него итоги регистра на нужную дату, переносишь его в новую базу, проводишь. Усё
   Ёпрст
 
44 - 02.11.16 - 10:11
Или просто прямым запросом получаешь в дбф базе итоги регистра на определенную дату и пихаешь инсертом их в sql базу.
   Это_mike
 
45 - 02.11.16 - 10:26
лучше - документ
   Это_mike
 
46 - 02.11.16 - 10:28
(45) +45 создать его прям в семерочной базе, и прям из итогов заполнить и провести. итоги, конечно, задвоятся. но потом пересчитать, и переностить штатно
   FoXSkr
 
47 - 02.11.16 - 10:43
(43), (44), (45), (46)
С этим я конечно согласен. Но надо это согласовать с клиентом (т.к. сейчас он при таком раскладе может получить отчеты за старые периоды) а вот при обрезки базы по человечески он уже этого не получит.
Но это еще не все. Я уже 200 лет не работал в 7.7 да и когда работал приходилось работать только с регистром бухгалтерии. Поэтому я тупо пока не знаю как реализовать такой документ. По видимому нужно на каждый регистр создавать такой универсальный документ? Т.к. табличных частей там всего одна да и у нее есть ограничение в размере 9999.
   FoXSkr
 
48 - 02.11.16 - 10:49
(48)Или в принципе сделать это все одним документом, просто при проведении загрузить все остатки в регистр. И потом запретить какое либо открытие и проведение этого документа в будущем.
   Это_mike
 
49 - 02.11.16 - 10:53
(47) таких документов - "универсальных двигателей регистров" - на инфосрани вагон и маленькая тележка.
остатки он получит вполне естественно, точно так же, как и сейчас (разница лишь в том, что сейчас остатки в регстре болтаются как в проруби,  а будут - привязаны к документу-регистратору. и перепроведение этого регистратора равно как пересчет итогов - ничего не испорти)
 
 Рекламное место пустует
   Это_mike
 
50 - 02.11.16 - 10:54
но вот нафига "на каждый регистр" или "много табчастей" - я даже сообразить не могу...
   FoXSkr
 
51 - 02.11.16 - 11:12
(49) Может завалялась такая?
Поищу наверное лучше пойду этим путем. Побаловался и хватит.
   Это_mike
 
52 - 02.11.16 - 11:16
   FoXSkr
 
53 - 02.11.16 - 11:24
(52) Спс. Их действительно миллион.
   Ёпрст
 
54 - 02.11.16 - 11:35
Вот этот влепи документ
http://catalog.mista.ru/public/115597/
   Злопчинский
 
55 - 02.11.16 - 11:42
(47) у меня такой есть. внедряется без всякого программирования, тупо через клипборд.
позволяет заполнять остаткми. всеми. или с фильтром по каждому измерению. позволяет заполнять расходом остатков (для обнуления итогов если надо). или сторно остатков (остатков (для обнуления итогов если надо)
   Злопчинский
 
56 - 02.11.16 - 11:44
плюс большие количества разбивает на документы-порции
   Это_mike
 
57 - 02.11.16 - 11:53
(56) "мам, ну купи слона..."©
   varelchik
 
58 - 02.11.16 - 15:56
(0) Ты же сам на свой вопрос ответил.
Кто-то как-то резал.
Вот и нарезал в файлах регистров фсякой фигни.
Ну с другой дбф все ясно.
А вот как в скуль грузим не ясно.
в скуль созранить и восттановить не зя.
выгрузка и загрузка.
все работай.


Список тем форума
Рекламное место пустует  Рекламное место пустует
ВНИМАНИЕ! Если вы потеряли окно ввода сообщения, нажмите Ctrl-F5 или Ctrl-R или кнопку "Обновить" в браузере.
Тема не обновлялась длительное время, и была помечена как архивная. Добавление сообщений невозможно.
Но вы можете создать новую ветку и вам обязательно ответят!
Каждый час на Волшебном форуме бывает более 2000 человек.
Рекламное место пустует