Плагин для лечения выгрузки и загрузки больших баз в 1С 7.7 #256662

Плагин выводит предупреждение MessageBox перед открытием (при чтении) и перед закрытием (при записи) файла 1Cv77.dat. Цель - лечение проблемы с большими (несколько Гб) выгрузками, которые не может правильно обработать штатная библиотека для работы с ZIP-файлами от 1С.

Плагин выводит предупреждение MessageBox перед открытием (при чтении) и перед закрытием (при записи) файла 1Cv77.dat. Цель - лечение проблемы с большими (несколько Гб) выгрузками, которые не может правильно обработать штатная библиотека для работы с ZIP-файлами от 1С.

Плагин выводит предупреждение MessageBox перед открытием (при чтении) и перед закрытием (при записи) файла 1Cv77.dat. Цель - лечение проблемы с большими (несколько Гб) выгрузками, которые не может правильно обработать штатная библиотека для работы с ZIP-файлами от 1С.

Маладца, как всегда! Но а когда сам паковать/распаковывать будет, иль на том и остановишься?

Спасибо огромное! Очень нужная штука!!!

Спасибо!

затрудняюсь найти правильную DLL для ZIP. Они вообще есть в природе? :-)

правильную - это какую?

есть бесплатные компоненты Перевел систему на бесплатные компоненты UnRar.dll и zLibEx. может это то что надо?

еще 5 баллов в копилку. Научи еще систему разбивать дат на куски и отдельно запаковывать :-)

Покопать на , прочем, кому я советую)))

полезная штука

написал у себя в новостях :)

Блин подождите рекламировать еще проверить надо. :-)

1С использует

Сейчас попробую на большой (3 Гб выгрузка SQL) базе запустить (на маленькой-то все работает...).

Роман, респект !!!

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

а разве подменой это лечится?

+ или 1С сама в конце этот файл портит?

Если база 9,2 гига устроит могу протестировать. Только вот сколько времени эта бодяга у меня шаманить будет?

База 25 Гб, SQL. Щас потестим...

Если проблема только в зипе (а не где-то еще глубже в 1С), то она должна вылечиться. (19, 20) Если получится это запустить, то будет здорово.

щас 25 в один гиг свернет :)

Не :-) Выгрузила щас все справочники + 4й док, ДАТ уже 2,7 Гб. Полдела сделано, джём-с

Итак, всё не так просто оказалось! Выгрузил базу, ДАТ файл получился 3,71 Гб. Далее стал загружать в пустую базу ДБФ. Загрузила справочники, на втором виде доков выдала ошибку: --------------------------- Конфигуратор --------------------------- Ошибка поиска в файле an unnamed file --------------------------- OK   --------------------------- Вспомнил! Поднимал тему Теперь ясно однозначно, проблема именно в том, как 1С загружает данные! Ограничение архиватора преодолимо(либо патчем, либо как я делал в той теме), но при загрузке всё одно вывалит ошибку

А если в пустую базу SQL? Может, там ограничение на гиговый размер файла DBF срабатывает?

сейчас попробую в SQL

+ хотя загруженная ДБФка (самая большая) - всего 590 Мб = 25

"При этом если система эксплуатируется в однопрограммном режиме, то размер файла может быть 2 гигабайта, однако если появится второй пользователь, а файл будет больше 1 гигабайта, то система 1С начинает сбоить по ЧТЕНИЮ" (с) hogik

вот ведь! У нас так и случилось на ДБФ! А все твердили про 2Гб-ограничение = Гружу в SQL, пока нормально

А CDX?

CDX при загрузке 1С создаёт ПОСЛЕ того как загружены ВСЕ данные. До индексации даже не дошла - выдала и осталась в конфигураторе

+ возможно индекс для 590Мб ДБФки был бы больше 1 Гб, и 1Сина это просчитала? Думаю, загрузка в SQL должна прояснить

Ну как накернилось на SQL?

Интересно! Вылетела на том же документе, по счетчику загрузила раза в два его больше (для ДБФ было значение 37 000, сейчас 60 000), и сообщение другое: --------------------------- Конфигуратор ---------------------------    Ошибка загрузки данных! --------------------------- OK   ---------------------------

Раньше пробовали менять файл, все равно с ошибкой вылетала, так что здесь проблема в 1С, а не только в сжатии... Такое ощущение, что она и не пытается загрузить данные более 2GB (т.е. начинает, а как начинает грузить более этого размера выдает ошибку)

ай да romix!!! ай да.... МОЛОДЕЦ!!!! :)

Обломинго. Попробую излечить...

надеюсь получицца. Проблема очень насущная, и очень уж давно известна... Рад буду потестить ещё

Там многократно вызывается SetFilePointer с шагом 512 байт. Относительно позиции FILE_BEGIN. :-) Может его отрубить тогда все сработает :-)

Пробую отрубать, вроде все загружает :-)

Не, просто втупую отрубить - это сильно.. а вдруг где косяк вылезет... там что, при "суммировании" по 512 байт идет где-то "переполнение"...? и указатель позиционируется не туда куда надо...?

Проверил (сравнивал пред. и след. позицию), там суммирование идет по 512 байт. Вызовы идут примерно так: То есть, все вызовы SetFilePointer - бесполезные... Исходят из mfc42.dll Можно отрубать имхо.

ну так результат-то какой? все ок?

Выложил обновленную версию, в которой отрублен вызов , т.к. чтение там строго последовательное. Ссылка прежняя. Можно обновить только plugin_unload_dat_fix.dll Проверил на своей базе (к сожалению у меня нет большой базы с неск-гиговым DAT).

!!!!!!!!! Ай, молодца!!

отлично! Сейчас запущу загрузку, завтра напишу что получилось

Внимательно следим за вестями с фронта

Ну давай зачотку, поставлю пятак! ждемс...

Я нагенерил данных, DAT 2,5 гига. При выгрузке надо переименовывать DAT (когда появится окно предупреждения) и подставить вместо него пустой (или почти пустой) файл с тем же именем. При загрузке надо подставить вместо него правильный DAT. Выгрузка и загрузка в одну и ту же базу у меня не получалась, пока я не создавал базу заново, или не делал Детач-Аттач. Обновил немножко еще dll - убрал отключение SetFilePointer в режиме записи (выгрузки) DAT. Ссылка та же.

как-то все недоделано... ну уже бы прикрутил бы и запуск стороннего архиватора

за разработку тройка тебе :-))

Лучше бы настройку запуска внешнего батника сделал бы чтобы не ручками подменять DAT файл

+ Гружу ДАТ из . В новую ДБФ базу загрузилось! Никаких ошибок не выдавала, всё в порядке. Сейчас считает регистры, думаю прервать и попробовать в новую SQL базу подгрузить. ДБФ-файл движения (самый большой) получился 1,5 Гб, так что думаю, что ждать пересчёта смысла нет - всё равно вылетит. Про SQL потом расскажу

Архивировать большие базы не всегда хорошо... Ждать порой долго, и место на винте (если все происходит в пределах одного компа) не экономится, а наоборот... Могу запрос имени DAT-файла сделать при загрузке, и вопрос писать его в ZIP или переименовывать/замещать пустышкой при выгрузке.

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

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

ИМХО выгрузка-загрузка для больших баз нужна только для лечения глюков в данных, и архивирование тут вообще ни к чему

Ну и перенос в сиквель тоже, когда база до DBF-ного предела дорастает. :-)

лишь бы не переросла :-)

По идее 32 бита - это же 4 гига, а приколы лезут уже с 2-х или с 1-го.

У нас как только регистр остатков (RG) перевалил за 1 Гб, перестал открываться период, ругалась на битый индекс. + Загрузила! Индексует щас... Не знаю, сколько ещё ждать, пока регистры посчитает (дождусь), но думаю, что уже можно ставить разработке 5+! Спасибо огромное, Роман, каждый патч - просто как бальзам на жирное туловище платформы!

:-)

:) а у меня запуск, выгрузка нормально, а при загрузке произвольной выгрузкой, после замены дат файла начинает создавать процедуры, но после "загрузка системной информацией" выдает ошибку загрузки.. и в readme файле ничего про начальный файл загрузки нет..

Если в ту же базу SQL загружаешь, то у меня она валится если не сделать детач-аттач, или не пересоздать базу SQL. Перезагрузка компа не помогает. Что это за явление, я затрудняюсь сходу сказать.

А после детач-аттач все работает.

:) я в новую и чистую гружу.. а ты под какой выгрузкой начинаешь загружать?

Я начинаю загружать выгрузку с пустышкой (размер 1 байт) вместо dat.

Т.е. в зипе не файл dat, а одноименная пустышка размером 1 байт.

А потом когда появляется окно, делаю подмену на нормальный dat.

я вообще MD-шник скопировал и в DAT переименовал, потом в архив сунул. Разницы же нет, всё равно подменяем его

Я наверное лучше автоматизирую этот процесс (переименование DAT и подкладывание вместо него пустышки), а то я сам не сразу допер что надо делать :-)

:) золотые слова! большинство же ожидает возможности автоматизации

очередной раз респект и уважуха. Большое тебе спасибо.

вместо апа... ждем новостей...

ну и я апну на всякий случай :)

Реально помогло и главное в кон :), огромное спасибо

Я обновил программу, там сейчас идет выгрузка DAT (по запросу) в определенный файл (в ZIP остается пустышка от DAT). При загрузке можно выбрать этот файл DAT (отказ от выбора файла = штатное поведение 1С).

:) бета тестирование начинается!

Error# : -120 Writing to File C:TestRA3612.DBF Уже загрузило много и так лохонутся.

Может место на диске кончилось? Или файл превысил 2Гб (или 1 Гб, там какой-то предел есть).

Чего-то третья версия плугина не сработала! До этого тестил вторую, на копии всё безупречно отрабатывало. Сейчас третью пробовал (текущую) - очень удобно с диалогами, это да. Файл выгрузки получился 4,01 Гб (до этого был 3,71 Гб), см , и в самом конце загрузки на предпоследнем доку выдала "Ошибка загрузки данных". Это чтож, получается есть ещё и ограничение на ДАТ-файл в 4 Гб?? romix, у тебя не осталось второй версии плугина? Может с ним загрузит правильно, у меня его не осталось = 24

+ Предел существует. Сделал удаление помеченных объектов (как раз накопились), снова сделал выгрузку (ДАТ файл получился ровно 4 Гб). При загрузке выдала ту же ошибку, но тот вид дока, что вылетел в прошлой загрузке - загрузился, ошибка вышла на последнем документе. Самое обидное, что по счётчику (в строке состояния) не хватило буквально чуть-чуть = (при выгрузке он поднимался до 700, при загрузке тоже поднялся до 700 и отвалился, видимо совсем коппек не хватило). Роман, можно с этим что-нибудь сделать?

Нашел более старую версию, сейчас ее выложу туда же...

(+83) Там теперь внутри папка v2 с более старой (и более простой) версией DLL.

А файловая система- NTFS? А то у FAT32 по-моему предел 4 гига...

Насколько я понял, то предела недолжно быть ... Дат файл весит 3,7Гб вконце как и говорится в инструкции спросило Ромикс использовать при сохранении я говорю да все, оно запаковало и в конце сказало, что в архив бросило пустой файл, потом делал загрузку и вот тебя пожалуйста ошибка. Так что именно ты переборол, я думал, что независимость размера ДАТ-файла :) места на диске хватает, разве он распаковывается на 50Гб :) система НТФС.

Writing to File C:TestRA3612.DBF Ошибка записи в файл... причем здесь Dat файл?

скороей всего как Ромикс сказал в 80 посте...

к трёпу про сжатие. Ежли subj на дельфях, то вот халявная ВКЛ-ина которая крют зипом

Да, конечно NTFS. Попробую со второй версией и отпишу о результатах

А база сиквельная, куда загружаешь? А то в DBF-ной ограничение то ли на 2 гига, то ли на 1 гиг (как утверждает некто hogik) на каждый файл.

гружу в чистую SQL-базу. Потому и заговорил про ограничение: 1.При ДАТ-файле 3,71 Гб загрузилось 2.При ДАТ-файле 4,01 Гб вылетело на предпоследнем виде дока 3.При ДАТ-файле 4 Гб вылетело на последнем виде дока. Т.е. предпоследний был загружен целиком (а их мало в базе, этих доков, и последнего, и предпоследнего, их относительно недавно ввели, ещё нашлёпать юзвери не успели в большом количестве), а последний (причём не в полном объёме) оказался уже за каким-то "пределом"

да суета это все и не серьезно, на таких объемах проще скульным BACKUP/RESTORE DATABASE пользоваться и не лохматить бабушку. И быстре и правильнее

выгрузка и загрузка это не то же самое, что BACKUP/RESTORE, вот в чём проблема!

+ начал загрузку второй версией плагина. Посмотрим что получится

Да, но иногда надо переносить из большой DBF в SQL.

иногда - надо, только вот как в этом поможет камраду pavel_tr?..

я объясню как. У нас базой достаточно долго никто не занимался, поэтому когда переходили на SQL она стала уже слишком большой для выгрузки-загрузки. Выкрутились тем, что убили 2 доп.регистра (ДАТ-файл был ровно 2 Гб, успели в самый последний момент - плагина тогда не было ещё), а потом перепроводили документы за 2 года (тогда были введены эти регистры). Сейчас живём на сиквеле, встал вопрос об обрезке. В принципе и сейчас можно обрезать, на копии уже всё оттестировал, но к примеру - в одном регистре (измерения: накладная,вид оплаты, клиент + ресурс: сумма) есть глючные данные (начиная с 1997 года по остаткам переходит сумма по клиенту, которая хз откуда взялась, а поле накладная пустое). Соответственно, при свёртке по этому клиенту остатки получаются неправильными. Если сделать выгрузку-загрузку конкретно этот, и многие подобные глюки можно вылечить