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

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

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

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

Загрузка данных 1с77 с dat-файла
http://1c-pro.ru/threads/dostup-k-fajlu-bezymjannyj-fajl-zakryt.31581/

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

Проблема при переходе на SQL

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

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

там еще были описаны алтернативные способы : через  риб

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

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

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

пач ромикса (спасибо ему) вреде решает проблему

но если нет, то
я бы сделал по другому :

нашел самые большие таблицы в дат файле и перенес
их в другой (или другие)

загрузил бы в базы 1с скл. и слил в одну базу простейшим скриптом с помощью  sp_MSforeachtable.

тк имена таблиц должны при создании совпасть

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

ну и порежьте его

и загрузите как в (12)

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

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

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

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

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

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

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

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

потом, аналогично, грузануть документы. Можно частями, определенных видов

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

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

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

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

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

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

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

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

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

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

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

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

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

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

http://catalog.mista.ru/public/83504/

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

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

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

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

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

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

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

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

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

2(45) см.(41)