Доброго времени суток! Решил базу перевести на SQL так как один из файлов ДБФ уже подбирается к 2Гб. Сделал тестирование и исправление, выгрузил. Когда загружаю создаются все таблицы, а в конце во время "Загрузка системной информации" вылетает:
Инструкция по адресу "0x200e22ed" обратилась к памяти по адресу "0x00000014". Память не может быть "read". Пробовал назад в ДБФ загрузить ошибка появляется в тот же момент но номера инструкции и ошибки другие.
Может кто сталкивался, помогите пожалуйста. Спасибо.

Антивирус?

(1) есть такой. Microsoft security. но пробовал на другой машине без антивируса - результат тот же.

Система, sql какие? В 1с никаких левых патчей не стоит?

(3)Сервер 2003, SQL 2000. 1С пробовал и с патчами и без.

Всё делаешь локально на сервере, разумеется? Не через сеть?

один вариант через рдп, другой - виртуальная машина

(6) На виртуалке свежеустановленная система, только sql и 1с? И та же ошибка? Тогда предполагаю, что выгрузка кривая получилась. Если базу просто скопировать на второй комп и там уже сделать выгрузку и загрузку?

Сервис паки на скуле стоят?

(7) На том же компе пробовал другую базу перевести на SQL получилось без проблем.

(8) 4-ый

(7) "Если базу просто скопировать на второй комп и там уже сделать выгрузку и загрузку?" и так тоже делал не помогло

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

(12) Это делалось уже не раз... И это не выход.

(0) база распределенная?

(14) значит плохо делал, Тии делал?

!(15) на (13)

(14) нет, не распределенная

(15) Делал ТиИ

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

Недавно словил такое: 1С SQL вылетал при получении большого пакета УРБД. Профайлером смотрел: курсоры перебираются и внезапно - вылет. Не помогала загрузка в новую базу даже. В результате пришлось создавать новую ПБ, быстрее оказалось чем возиться. Попробуй заново.

(20) Если б это только мне нужно было то давно уже все заново было. Но бухгалтерам и аналитикам нужно все в одной базе, а не возиться с несколькими.

(21) Процесс начни заново, а не дрочи один и тот же zip-файл. Чтобы снизить вероятность всяких неожиданностей - на проверенном сервере, в терминале или вживую.

(20) Навело на мысль. Сделать ПБ развернуть её SQL и сделать не распределенной. Ну или уж совсем в качестве бреда создать пустую и перенести информацию любым способом.

Смотри реквизиты неограниченной длины в общих реквизитах и на всякий случай во всех остальных объектах. Должны стоять в конце списка.

Хотя если так "Пробовал назад в ДБФ загрузить", то это наверное что-то другое уже.

Вспоминается, что то там было про строки неограниченной длины в конце метаданных.....

vde69 щас придёт и все расскажет

(22) у меня этих "зипов" уже целая куча.

(24) я такие реквизиты на одной из копий поубирал все до одного и не только общие но ничего не дало.

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

(0)У меня так было когда-то на доставшейся в наследство самописке (изначально была 1С:Бухгалтерия). Помогло только очень сильное урезание базы, тестирование и исправление при этом проходило нормально. По моему опыту, логика у баз dbf и баз SQL платформой 7.7 обрабатывается по-разному.
Если урезание базы для Вас не выход - ну тогда я бы сделал новую базу на MS SQL, накатил бы на неё конфигурацию исходной базы, а потом бы стал переносить данные через XML. Заранее Вам сочувствую.

(30) Спасибо за совет.

(31) Спасибо. Уже тоже приходили мысли по поводу новой чистой базы и перекидки данных через xml

Три последних действия SQL перед слетом:

exec sp_executesql N'Delete from _1SSYSTEM; Insert into _1SSYSTEM values(@P1,@P2,@P3,@P4,@P5,@P6,@P7,@P8)', N'@P1 datetime,@P2 int,@P3 varchar(9),@P4 varchar(3),@P5 varchar(36),@P6 varchar(1),@P7 datetime,@P8 int', 'Feb 28 2015 12:00:00:000AM', 0, '     0   ', 'OFC', '688A90AE-F6A4-4007-BBB7-0144645A784E', 'M', 'Jan  1 2015 12:00:00:000AM', 0

Select * from _1SSYSTEM(NOLOCK)

Select * from _1SSYSTEM(NOLOCK)

OFC - похоже на префикс базы, при распределенных базах, но в конфигураторе не зарегистрирована ни одна база УРБД.

(0) и эта выгрузка поди обратно в дбф базу тоже не лезет еще, да ?
:))

скинь выгрузку на [email protected] на поглядеть

Инициализация значит проводилась, создавалась центральная база
ИД заполнен тоже

(36) Думается, это не проверялось. Такая большая база (см. первое сообщение - одна из таблиц уже более 2-х ГБ) запросто может загружаться в dbf несколько дней.

(39) Это детская база, даже для дбф варианта.

Получилось. Зашел у УРБД, сделал из этой базы центральную, выгрузил и загрузилась в SQL. Похоже до меня с этой базы уже кто-то делал УРБД. БОЛЬШОЕ ЧЕЛОВЕЧЕСКОЕ СПАСИБО ВСЕМ.

(41) всё проще. Нужно было либо выкинуть мусор в dat файлике от уриба. Либо изначально прибить таблички (и поправить в системных) от уриба в дбф-базе перед выгрузкой