Нужно написать обработку, которая переводит базу из скл формата в дбф и обратно за максимально короткое время (для перепроведения).
Штатный механизм медленен.
Необходимо "просто" перенести значения в соответсвующие таблицы.
Готовое решение есть у софтпойнта: http://softpoint.ru/article_id110.htm, но оно стоит денег.

Подскажите, пожалуйста, по следующим вопросам:

1) Как самым быстрым способом перезаписать значения в таблицах (например скульных, т.к. только чистка таблиц для последующей записи будет идти лишних полчаса)?
2) Есть пример как в одном запросе получать данные из дбф базы и записывать в скл и наоборот?
3) Может кто-то уже делал подобное? Поиск не помог.

Nick писал(а) 12. Октября 2007 :: 06:16:


Да, нужно перепроводить в дбф.

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

Конфигурация "Комплексная", расчет не используется.
Размер базы около 4 Гб.
Время выгрузки из скл и загрузки в дбф сейчас около 2.5 часа.
Время выгрузки из дбф и загрузки в скл сейчас около 1.5 часа.

Nick писал(а) 12. Октября 2007 :: 06:51:


>>У вас с идеологией что то не то! Зачем перепроводить?

Много правок задним числом, организация большая, тоже люди работают, ошибаются.
Именно последовательность восстанавливаем.

>>Время на загрузить выгрузить + проведение не будет болше чем просто перепровести в SQL?

в SQL за ночь проводятся документы приблизительно за месяц, в DBF - около трех,  с учетом выгрузок-загрузок

>>За какой период?

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

Nick писал(а) 12. Октября 2007 :: 07:06:


В монопольном со сдвигом ТА, используя транзакции.

>>Перепроводить базу за 9 месяцев это бред!

Согласен полностью! Но решения сколько месяцев перепроводить не от меня зависят.

>>У нас размер SQL базы 30 гб
Это у вас. У нас реально выгружать в дбф и перепроводить.

>>Сделай умную перепроводилку..
Хорошая идея, ей тоже можно воспользоваться.
Не можешь подсказать примеры ее реализации, кроме софтпойнта.
Вы сами как делаете?

По идеологии - неправильно.

По сабжу - в цикле обходишь все таблицы SQL и через OLEDB создаешь таблицы ДБФ (CREATE TABLE).
Есть небольшие отличия в структуре таблиц - на сайте http://metaprog.co.ua/secrprog/
и в статье Прямые запросы.
Ну добавляешь все необходимые файлы типа md , DD.
Переиндексируешь - все.

Небольшие трудности будут с типизацией колонок в ДБФ.

Вообщем несложно но муторно и неинтересно.

-KONST- писал(а) 12. Октября 2007 :: 07:33:

Одним нельзя - разные провайдеры.

Запросом получаешь данные в ТЗ, из ТЗ заливаешь в Таблицу ДБФ - текущие скорости
около 30 000 записей в сек - т.е. скорость заливки сравнима со скоростью выборки.
http://www.1cpp.ru/forum/YaBB.pl?num=1191570663

kiruha писал(а) 12. Октября 2007 :: 07:38:


Мне показалось что можно. Из вышеприведенной статьи софтпойнта:

"Рассмотрим краткое описание концепции реализации этого продукта.

Существуют различные средства доступа к данным в формате DBF и SQL.  Например, для того что бы из MSSQL сервера обращаться к данным в формате DBF достаточно подключить linked server выбрав в нем провайдером доступа Driver={Microsoft Visual FoxPro Driver}.
...
После этого будет возможно обращение к данным DBF с использованием некоторых конструкций SQL.
...
Для того, что бы быстро преобразовать данные из DBF в SQL, необходимо произвести импорт объектов посредством провайдера."

-KONST- писал(а) 12. Октября 2007 :: 07:43:


Ну и они выбирают данные через драйвер. Только из под SQL.
Как масло не намазывай
Если так больше нравится - можно и так

-KONST- писал(а) 12. Октября 2007 :: 08:03:

Пересоздавать таблицы!

Для MS SQL
TRUNCATE TABLE
эта инструкция не записывает сведения об удаляемых строках в журнал транзакций
поэтому выполняется быстрее чем delete и поэтому откат назад становится невозможен

Автору -1
ИМХО слишком сложная и трудоемкая задача.

kms писал(а) 15. Октября 2007 :: 13:11:


А зачем его создавать? Один раз скопировать и дальше подкладывать (если изменений нет).
То же с md.

Кстати, если брать скорость - то полную выгрузку вообще нет смысла делать - а только последний период с начальными остатками на начало периода .

kiruha писал(а) 15. Октября 2007 :: 13:33:

Я просто хочу понять, насколько -KONST- продумал разные побочные эффекты в обсуждаемом решении.
Тут же как всегда 95% - это прикладные вопросы, а 5% - риски.
Но этих 5%, возможно, достаточно, чтобы отказаться от этого решения в пользу чего-то другого.

kms писал(а) 15. Октября 2007 :: 13:53:


По поводу вариантов.
Правильно ли мне кажется, что в скл документы проводятся медленнее из-за того, что медленнее происходит запись средствами 1с движений регистров, операций? (помимо ошибки 2000 mssql).
Просто один из вариантов был сделать так, чтобы движения регистров удалялись и заново создавались только тогда, когда они изменились.

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

kms писал(а) 16. Октября 2007 :: 10:43:


База с начала года.
Комплексная сильно переписанная (не мной) в части проведения документов:
происходит назначение оплаты отгрузке (указывается какие конкретно документы должны оплатить какие конкретно отгрузки) по покупателям и поставщиками.

Вообще есть стандартные способы ускорения перепроведения.
Т.к. нужно как правило восстанавливать 1-2 регистра то делают

1. Константа.РежимПерепроведения
2. У всех документов очистка движений неавтоматическая
3. В зависимости от константы очищаются движения и расчитываются
движения заново только по нужным регистрам, например партии.

(0) (ИХМО) Про subj - забудь.
Начни с самого простого что может дать быстрый эффект -  с железа.
Хороший сервер, хорошая сеть  гораздо важнее subj
Цитата:

Так потихоньку распутывай механизм.
и далее оптимизация узких мест.