|
1С:Предприятие
:: 1С:Предприятие 7.7 и ранее
|
|
| ||
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 | |||
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 | |||
АНДР 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 | |||
Это_mike 26 - 31.10.16 - 11:43 | |||
Ёпрст 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 | |||
Это_mike 52 - 02.11.16 - 11:16 | |||
FoXSkr 53 - 02.11.16 - 11:24 | (52) Спс. Их действительно миллион. | ||
Ёпрст 54 - 02.11.16 - 11:35 | |||
Злопчинский 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) Ты же сам на свой вопрос ответил.
Кто-то как-то резал. Вот и нарезал в файлах регистров фсякой фигни. Ну с другой дбф все ясно. А вот как в скуль грузим не ясно. в скуль созранить и восттановить не зя. выгрузка и загрузка. все работай. |
|
Список тем форума
|