v7: Загрузка данных в SQL - "ошибка поиска в файле безымянный файл" #804133

Собственно вот такая беда. Понятно, что ошибка в файле выгрузки (текстовом 1цв7-дат, который запихан в зип)... ТИИ перед выгрузкой делалось только с исправлением ошибок, обнаруженных при проверке физической целостности... логическую не решился - очень много пустых ссылок, которые нужны "технологически" и которые очищать нельзя, а создавать новые объекты - тоже некомильфо, ибо не нужны они в базе совершенно... И вот что там за ошибка, как ее искать? ошибка вылазит в то время, как в строке состояния показывается "загрузка документов: Т_Расходная накладнаяЖ 6900" Особо интересует мнение профессора Ёпрста (от него видел замечания об именно этой беде, да и вообще на эти темы)... заранееблагодаренивсётакоэ

Касперского убей

: Антивирусов нет, только встроенный - пробовал с включенным, пробовал с октлюченным - результат тот же. тем паче, что на потоке загрузки улетает (по результатам прерванной загрузки ситуация вполне соответствует - этих накладных имеется только до лохматого 2009-го года)

+: "на потоке загрузки" - значит не в антивирусе/правах дело, если бы антивирус/права не позволяли - на старте действия срубило бы...

: гуглено-перегуглено, в том числе прочитаны упомянутые ссылки. первая как раз и послудмла основанием для того, чтобы позвать персонально Ёпрста (посты №28 и №30) по второй ссылке - не о том вообще. в любом случае - спасибо.

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

+: пардон, там в №62 приведен ответ от 1с - "если 1Cv77.dat менее 4 Гб ... то проблем быть не должно." у меня как раз тот случай - дат-файл 3Гб+ проблема упаковки-распаковки решена (приблудой от Альфа)

там еще были описаны алтернативные способы : через  риб и загрузки данных по частям в разнве баз скл и потом перегрузка.

: через риб - на потом, очень длинно получится.... да и очищать признак рб - хз как (пока).. по частям - не силен в DTS-ах и нет прямог доступа на скл-сервер, да и даже после нескольких прочтений остаются неясности... спасибо.

ёмаё... а ведь действительно 2Гб - максимальный размер дат-файла который может быть за(!)гружен. не в ошибке дело. тии с исправлением ошибок.. выгрузка 3Гб+ дат-файл (зазиповать-раззиповать решено). на загрузке - вылет (на том же месте что в скл что в дбф), вход монопольно, последний загруженный документ - выдираем цифровой ид - ищем в дат-файле секцию этого документа по этому ид - обрезаем дат-файл от найденного документа до конца... выходим - и оппа - действительно, обрезка дала дат-файл 2048Мб ровно. Видать или обрезать мумукаться предварительно придется (непростая обрезка, накручено аналитических ништяков дофига)... или - через урбд? создавать периферийную скл-базу... по кускам давать миграцию объектов - и дозагружать в нее?.. а потом ре-инициализировать урбд в скл?

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

: патч Альфа - тоже. я же говорю - эту проблему я решил (невозможность движка 1с зиповать большие файлы)... проблема в другом - дат-файл >2Gb не хочет за(!)гружаться

ну и порежьте его и загрузите как в в качестве текстового редактора нотепад++ или фар

: 3гб+ текста сносно скушал только ультраедит (нотепад и фар благополучно сдохли на нем). "как в 12" - не умею, и кроме того, сервер не мой, там админ при своих делах, мне выдал базу и подключение - этим и пользуюсь, никаких тулз кроме того - как и что "резать" - хз, там структура

там же всё блоками, вырезается на ура. А так, если нужно в скуль вгрузить, нужно сперва в дбф проверить следующее: общие реквизиты доков с типом строка неогр. длины должны быть последними в списке не должно быть пустой даты в 1sjournl/1sentry/1soper/ не должно быть дублей по iddoc, id справочника. Ну еще зацикленность групп проверить. + вырезать мусор от уриба (если есть).

можно и вообще извратом, прямым запросом в скуль с дбф. Единственное, с доками придётся повозится в плане создания поля date_time_iddoc , да и где то валялись готовые хранимки для этого

: о, пришел, рад видеть! в смысле "блоками" и где "там"? если я из дат-файла кусок документов (прям по виду) вырежу (дат1) - загрузка без вырезанного... потом кусок документов всуну вместо загруженного впихну (дат2) - так оно при загрузке разве не затрет ранее загруженные (из дат1) документы??? (да, конечно, единственный общий реквизит документов типа строка неогр.длины - последний в списке общих реквизитов документов, да и ошибка при этом другая вываливалась, скульная а не 1с-ная) остальное - тоже вроде норм, оно четко на 2Гб загрузки вылетает...

в общем, вопрос теперь трансформировался в вот какой: как загрузить дат-файл >2Гб в sql 2005+ ? (вроде как патч ромикса и патч альфа с солюшеном-7 дают такой результат - попробовал грузануть выгрузку с ромиксом без солюшена-7 - загрузилось норм, как только подключаю солюшен-7 - патч ромикса отрубается, а с патчем альф-а spyconfig вылетает вон та ошибка)

прим.: в - о попытках загрузить в дбф, в скл понятное дело никак

Можешь, сперва грузануть только справочники. Способов 2: а)вырезать из дат файла (долго). б)грохнув таблички в дбф (быстро) потом, аналогично, грузануть документы. Можно частями, определенных видов

Это, ежели кусками грузить. Файло дат, разве что ультраедит32 править. Там ничего сложного в структуре.

: угумс, ультраедит юзаю. так загрузка оставляет в живых ранее загруженное штоль??? (как-то нелогично)

Это же решаемо - грузи в разные базы, потом импортом в самом sql склеивай.

: ох блин, нету у меня доступа в скл-сервер. базу дали - и алё. да и не умелец я в скл-администрировании, совсем не умелец... :(((( блин, что, никак не подружить солюшен7 с большими выгрузками?

Подними временно MS SQL 2000, где ты бедешь царь и бог. И солюшн не понадобится...

ну, поставь себе экспресс какой нить на локальную тачку и балуйся. Как слепишь базу, просто сульный архив перенесешь и всё.

Мда... Протестировал на размере 3+. Точно так же вылетает. А ведь решение Ромикса давно уже существует. Неужели никто не напарывался? Или у него пропатчено и это дело?

: твое решение не пускает загрузку дальше 2Гб? (я попробовал патчем ромикса на ХР в дбф - грузит нормально все 3Гб+)

2 Не пукает. Буду думать как исправить. У Ромикса оказывается это решено давно: "24.02.2007 добавлен перехват SetFilePointer, поскольку этот системный вызов портил картину при загрузке (не получалось загружать данные больше 2 Гб)."

+ Только вот что-то не нашел в доступных исходниках этого перехвата. Только объявление класса для перехвата.

+: спасибо за прояснение ситуации! буду ждать с нетерпением фикса, а то, сам видишь по выгрузке - скоро наступит час "че" для файлового варианта... пока буду пробовать без плагинов выгрузить (на сообщении об ошибке - скопировать из каталога базы дат-файл пока его не потерло); а при загрузке в скл (только с солюшен7) - на сообщении "При загрузке данных все существующие данные будут уничтожены!" - в подпапке UZ000000 каталога базы данных - подменить "кривой-пустой" дат-файл из ошибочного зипа на тот, который скопировал ранее при архивации... как думаешь - прокатит?

2 Это примерно то, что делает плагин ромикса. Но зип ведь не ошибочный создается. Там просто еще одна проблема (ограничение) при загрузке большого dat. Именно при загрузке. Выгружается-то нормально. Соответственно, для загрузки таких архивов можно использовать решение ромикса пока я не доработаю свое.

: загружать надо в скл 2008 соответственно используется солюшен7. который отрубает нафиг ромикса. замкнутый круг етить его в кочерыжку. :(

был поправленый, который "не отрубает" на нимфостарте посмотри

эта вроде как.

хотя не, это для подмены запроса. блин

неужели никто из пользователей солюшена7 не переносил в скл базы выгрузкой-загрузкой >2Г дат-файла?

не проканало... обрыв загрузки ровер на 2Гб :(

последний вопрос.. : Алексей, патч ромикса при использовании "секретного релиза" (солюшен7) отрубается напрочь - в отличие от твоего. т.о. для переноса в нативные форматы sql2005+ (а именно в 2008, который используется у нас) с использованием упомянутого релиза меня может спасти (мне тоже немного удивительно что только меня) только твое решение проблемы загрузки 2гб+ в spyconfig... собственно вопрос - вот: *** Можно ли надеяться на решение этой проблемы spyconfig? и если "да" - то хотя бы ориентировочно когда? спасибо.

2 Сроки не назову. Но решение проблемы и мне самому нужно. Так что буду работать.

Исходную базу не сжать?

2 Задача перенести базу из DBF в SQL. Чем поможет "сжать исходную базу"?

хмм 4-гига переносил ромиксом - под сервер2003 если память не изменяет, хотя может изменять - давно ето было

2 см.