Ошибка помещения файла выгрузки на сервер для выполнения операции загрузки

21.02.12 — 11:10

1 — 21.02.12 — 11:12

кэши чистились?

2 — 21.02.12 — 11:13

(0) Мне даже интересно как связаны драйвера на видеокарту с выгрузкой 1С

3 — 21.02.12 — 11:14

(2) Да и вообще нефиг ОСи на серверах обновлять и включать автоматическое обновление

4 — 21.02.12 — 11:50

5 — 21.02.12 — 11:52

(3) Это вы про «grphcs.dll» из каталога «bin» 8.х? О_О

6 — 21.02.12 — 11:54

(1) кэши 1С? Если его, то чистились, но за неделю до возникновения проблемы

(2) мне тоже. v8: Совместимость железа и 1С 8.2

(4) да, я эту статью админу сервера показывал. Сказал, что с его стороны все хорошо.

7 — 21.02.12 — 11:56

А вручную выгружается?

8 — 21.02.12 — 11:56

(7)да

9 — 21.02.12 — 12:01

BackUpFileName = """H:Bkpbase1c_" & Date & "_0.dt"""
StartString = """C:Program Files (x86)1cv828.2.14.540bin1cv8"""
StartString = StartString & " CONFIG"
StartString = StartString & " /Sservbase"
StartString = StartString & " /Nlogin"
StartString = StartString & " /Ppasswd"
StartString = StartString & " /DumpIB"
StartString = StartString & BackUpFileName
WshShell.Run StartString, 1

10 — 21.02.12 — 12:04

Делать бекапы через выгрузку в .dt некорректно. Используйте средства СУБД.

11 — 21.02.12 — 12:07

(10) а если файловая, то каким средством?

12 — 21.02.12 — 12:11

13 — 21.02.12 — 12:14

(10) [Делать бекапы через выгрузку в .dt некорректно]

классная отмазка

14 — 21.02.12 — 12:17

(13) это факт а не отмазка. сама 1с заявляет что дт не для этого.

проблему то решить надо, а юзать в качестве бэкапов дт — на самом деле не по феншую

15 — 21.02.12 — 12:18

16 — 21.02.12 — 12:18

(14) а не выгружать регулярно в dt — самоубийство

17 — 21.02.12 — 12:19

(16) раз в месяц — и хорошо. причем только в диагностических целях, некоторые ошибки всплывают только при формирования дт-шника, которые не видит ТИИ

18 — 21.02.12 — 12:21

(17) а если у ТС активный поло(зачёрнуто)кодерский процесс и каждый день динамически обновляется конфа ?

19 — 21.02.12 — 12:24

>>и каждый день динамически обновляется конфа

расстрел

>>активный поло(зачёрнуто)кодерский процесс

юзать хранилище, обновлять в определённое время в штатном режиме.

20 — 21.02.12 — 12:37

21 — 21.02.12 — 12:42

22 — 21.02.12 — 13:03

(20) >>а если ночной dt утром надо разработчику

надо дак надо, я только говорю что в качестве основного бэкапа так не делается в нормальных конторах, более надёжно — бэкап СУБД.

>>каждый день динамически обновляю конфу

молодец, чо ещё сказать) повезло значит что не натыкался на глюки. Это говорит только о том что организационно работа не спланирована, нет никаких правил, несеръёзный подход ИМХО.

у нас за такое расстреляют без предупреждения, и правильно сделают.

23 — 21.02.12 — 13:18

(21) Могу предположить, что DESIGNER и CONFIG обрабатываются по-разному…

24 — 21.02.12 — 13:38

(23) пардон, этого не заметил. Попробую.

25 — 21.02.12 — 14:25

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

Рад, что все оперативные вмешательства Вы можете сделать выгнав пользователей или оставить на обновление в нерабочеее время

26 — 21.02.12 — 14:36

(25) Оперативного вмешательства на уровне «Программного Кода» быть не должно впринципе. Обработками поправить данные или отчеты-печ формы — для этого не надо обновлять конфу. Все доработки должны сначала тестироваться, чтоб не надо было оперативно править код. Отдельные задачи разрабатываем, тестируем вместе с юзерами и только потом обновляем рабочие базы. Как пример.

>>исходить надо из природы возникновения

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

27 — 21.02.12 — 14:39

(26) прикольно,

т.е. когда у тебя УПП падает на ветке графа, который ты до того ни разу не использовал, ты посылаешь офис в сад ?

28 — 21.02.12 — 14:41

(26) Да? вы чо? говорят и в УПП ввели константу NOERRORS и вылизана она вся от поставщика и рядом небараны авнеца не напишут

29 — 21.02.12 — 14:44

(26) Чистите кэш чаще, и не только у себя, для начала, можно при логоне

30 — 21.02.12 — 14:47

чот вы всё утрируете, высасываете ситуации из пальца, если в базе работают больше месяца — все такие грубые косяки найдёны и исправлены. Далее нормальная работа идёт — доработка, тестирование, обновление. если 5 раз обновлять за утро — это только если сам програмер в своём же коде наделал таких косяков и не тестил ничего.

Форс мажоры бывают — раз в полгода может динамически обновим. Но это нештатная ситуация.

31 — 21.02.12 — 14:49

Боюсь вмешиваться, но что мне со своей компонентой grphcs делать?

32 — 21.02.12 — 14:50

(31) переустанови/исправь платформу

33 — 21.02.12 — 14:52

(31) Обновись до 8.2.13.219

34 — 21.02.12 — 14:59

(30)[Форс мажоры бывают — раз в полгода может динамически обновим.]

=)

35 — 21.02.12 — 14:59

(31) ок

(33) а почему именно на эту? Может тогда уже на 8.2.15.ххх?

36 — 21.02.12 — 15:02

(35) 14, 15 еще не совсем устаканившиеся/стабильные.

37 — 21.02.12 — 15:03

(30) бессмысленно, сколько раз я обновляюсь сегодня — сугубо мое личное дело, главбуха и директора по ИТ, будем в Вашем монастыре работать — будем по Вашим правилам жить.

А пока мне в Итилиуме насчитывают время между обращением и исполнением заявки

38 — 21.02.12 — 15:04

(36) спасибо. значит слать франча, который предлагает 15ю платформу лесом?

39 — 21.02.12 — 15:06

(38) 15 последняя в толстом клиенте вроде бы писали, что стабильная, но пока 13.219

40 — 21.02.12 — 15:07

(34) что 🙂 ? осенью последний раз было динамическое)

41 — 21.02.12 — 15:08

>>на релиз 2.0.32.4

там написано с какой платформой минимум он работает? Имхо просто файлик повредился, можно просто переустановить

42 — 21.02.12 — 15:11

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

43 — 21.02.12 — 15:11

*типовые конфы не

44 — 21.02.12 — 15:14

(42)(41) Спасибо за информацию. Буду думать и пробовать.

45 — 21.02.12 — 15:38

(5)нет это я про «Админ сервера клянется, что никаких изменений с видеоподсистемой сервера не производилось, а драйвера видео стоят самые последние. «

46 — 21.02.12 — 15:42

(44) С правами доступа у пользователя от имени которого выполняется BackUP проблем нет?

47 — 21.02.12 — 15:44

(46) нет.

Переустановил платформу — ничего не поменялось.

Сегодня до кучи переустановлю платформу на втором сервере(где база на SQL крутится).

Ну и попробую DESIGNER на CONFIG поменять.

1. 19.04.2017, 12:03

   
   

   #1

   

   
   Гость форума
   

   ---

   Неверный формат файла для загрузки информационной базы
   

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

   ---

2. 19.04.2017, 12:10

   
   

   #2

   

   
   Спец
   

   ---

   Re: Неверный формат файла для загрузки информационной базы
   

   так надо же было написать, какой формат у файла

   ---

3. 19.04.2017, 12:23

   
   

   #3

   

   
   Гость форума
   

   ---

   Re: Неверный формат файла для загрузки информационной базы
   

   1Cv8.dt — вот такой файл.

   ---

4. 19.04.2017, 18:45

   
   

   #4

   

   
   Спец
   

   ---

   Re: Неверный формат файла для загрузки информационной базы
   

   формат тот
   как загружаешь?

   ---

5. 01.07.2021, 21:22

   
   

   #5

   

   
   Гость форума
   

   ---

   Re: Неверный формат файла для загрузки информационной базы
   

   Всем добрый день. У меня такая же фигня. Сломался сервер (полетели диски) и к сожалению он не запускается и не работает.
   поменяли диски, установили windows server 2012. потом началось самое веселое. есть архив базы 1Сv8.dt
   И как бы я понимаю что просто нужно установить платформу 1С8, можно даже не устанавливать конфигурацию, потом создать новую базу (даже без конфигурации), потом зайти в конфигуратор и в «Администрирование» — «Загрузить информационную базу». вроде бы просто но осталось узнать какая платформа 1С8 стояла.
   Из слов бух….. ка бы была 8.3.17.2127 — но к сожалению конкретно эту версию я не смог найти и установил 8.3.18.1289
   Все сделал как описал выше и при загрузке инфо. базы, через сек 10 выскакивает ошибка «Неверный формат файла для загрузки информационной базы. Ошибка формата потока»
   и три кнопки: «Завершить работу» «Подробно» «Перезапустить». Если нажать «Подробно» то пишет по причине: «Ошибка формата потока», и ВСЕ!?
   В общем бодался долго, изучал интернет но там все пишут про чистку кеша, аварийная перезагрузка сервера и др…. которое мне совсем не подходят.
   Пробовал удалять и устанавливать разные версии платформы 1С8: 8.3.10.2667 потом 8.3.17.1851 потом 8.3.18.1289 и везде такая же ошибка при загрузке инфо базы.
   Подскажите в чем проблема и почему такая ошибка и что я не так делаю! может надо найти версию точь в точь 8.3.17.2127?
   Помогите пож… !!!
   и если кто знает где скачать платформу версии 8.3.18.2127?

   ---

6. 02.07.2021, 18:03

   
   

   #6

   

   
   Спец
   

   ---

   Re: Неверный формат файла для загрузки информационной базы
   

   Возможно проблема не в версии платформы, а просто битый архив. Какой размер файла? В файловом варианте загружается?

   ---

7. 16.02.2022, 11:28

   
   

   #7

   

   
   Гость форума
   

   ---

   Re: Неверный формат файла для загрузки информационной базы
   

   была такая же проблема. удалось решить так — зашел в Конфигуратор, обновил, после спокойно всё заработало.

   ---

8. 16.11.2022, 23:39

   
   

   #8

   

   
   Гость форума
   

   ---

   Re: Неверный формат файла для загрузки информационной базы
   

   Сообщение от VladKapter
   

   была такая же проблема. удалось решить так — зашел в Конфигуратор, обновил, после спокойно всё заработало.

   А что именно обновил ? , если база в формате .td через конфигуратор не грузится с ошибкой потока…

   Спасибо.

   ---

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

«Ошибка загрузки информационной базы. В информационную базу загружены не все данные по причине: Ошибка СУБД: Превышен максимально допустимый размер внутреннего файла ‘D:1CBASESNewDB/1Cv8.1CD’«

Я лично потратил ОЧЕНЬ много времени на поиск решения этой проблемы и в итоге нашел его, что позволило нам создать файловую копию базы данных размером 18 Гб и в итоге сэкономило примерно неделю времени (могу в комментариях рассказать, как было дело, но сейчас речь не о том).

Итак, причин возникновения такой ошибки может быть несколько:

1. Размер КАКОЙ-ЛИБО таблицы в базе данных превышает лимит для файловой версии (4 Гб). Если честно, во избежание подобных эксцессов мы проверяли размеры таблиц базы заранее с помощью обработки «SQL базомер» (или аналогов). 
2. Ошибка связана с глюком особенностями платформы, и вызвана определенной спецификой структуры метаданных выгружаемой конфигурации.

С первым случаем все понятно — если базомер показал превышение лимита по каким-то из таблиц базы, то эти таблицы необходимо почистить. Если речь идет о справочнике или непериодическом регистре сведений, то нужно постараться удалить оттуда ненужные элементы/записи. То же самое относится и к «тяжелым» документам с их табличными частями. В первую очередь следует заняться удалением помеченных объектов, конечно.

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

Регистры остатков могут некорректно (не по всем измерениям) закрываться, что приводит к ОЧЕНЬ значительному и быстрому разрастанию таблиц итогов. Списание «зависших» остатков регистра накопления может при последующем пересчете итогов дать экономию до нескольких Гб, проверено на собственном опыте у «нерадивых» клиентов. ))

Что же делать, если каждая таблица вашей базы размером менее 4 Гб, но ошибка все равно возникает?

Это значит, что у вас второй случай — проблемная структура метаданных конфигурации. Вероятнее всего, ошибка возникает на этапе создания индексов.

В двух словах опишу ситуацию в целом, чтобы было понятно, словами Виктора Сосновского из 1С. Ниже цитата с партнерского форума:

«При загрузке информационной базы в файловом варианте сначала загружаются данные всех таблиц, а затем создаются индексы. Ошибка создания индекса приводит к тому, что индекс, созданный с ошибкой, и все последующие индексы не создаются. Если в базе много данных, то это приведет к существенному снижению производительности. Полноценная работа с такой базой будет невозможна.»

Нужно узнать, какая именно таблица приводит к ошибке при создании индекса.

Включаем технологический журнал — в папку «С:Program Files (x86)1cv82__НомерВерсииПлатформы__inconf» (или аналогичную, __НомерВерсииПлатформы__ подставьте свой) кладем файл logcfg.xml примерно следующего содержания:

<?xml version=»1.0″ encoding=»UTF-8″?>
<config xmlns=»http://v8.1c.ru/v8/tech-log»>
         <dump create=»true» location=»D:1CBASESdumps» type=»0″ prntscrn=»true»/>
         <log history=»3″ location=»D:1CBASESlogs»>
         <event>
                      <eq property=»name» value=»dbv8dbeng»/>
         </event>
         <event>
                      <eq property=»name» value=»excp»/>
         </event>
         <property name=»all»/>
         </log>
</config>

Внимательно следим за тем, чтобы каталоги для дампов и логов:

1. Существовали
2. Различались
3. Были доступны для чтения и записи тому пользователю Windows, от лица которого вы запускаете конфигуратор.

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

Первое же вхождение EXCPCNTX в логе в моем случае указало на команду, которая вызвала ошибку: CREATE INDEX _Accum27148_ByDims_TRRRRRRRRRSSR (у вас название индекса будет другое).

По цифрам из названия индекса с помощью обработки «Структура хранения таблиц базы данных» (или аналогов, которые умеют показывать индексы) находим, какой таблице принадлежит данный индекс. У меня это оказалась таблица оборотов одного из нетиповых регистров накопления.

А дальше начинается самое интересное — нужно попытаться угадать, что именно в структуре вашей таблицы приводит к ошибке индексации.

В первую очередь следует смотреть, какие поля входят в индекс. Как выяснилось, платформа ОЧЕНЬ не любит, когда совокупный размер ключевых полей индекса становится значительным. В частности, она не любит индексировать длинные строки — так, в моем случае в индекс попадало измерение с типом СТРОКА (500) и оно вызывало ошибку. Другой представитель фирмы «1С» высказался на партнерском форуме еще в 2007 году:

«Если длина ключа оказывается близкой к 2К, то начинается резкий рост размера индексов с рядом неприятных последствий.«

 И действительно, в 2013 году ничего не изменилось — в подобных случаях наблюдается лавинообразный рост размеров индекса на файловой базе. А когда таблица индекса превышает лимит в 4 Гб, загрузка .DT останавливается с ошибкой.

Лично мне помогло отключить для проблемного измерения флажок «Использование в итогах», т.к. в реальности итоги по нему не требовались. Оно перестало попадать в саму таблицу оборотов и, как следствие, в индекс таблицы оборотов. Есть и другие способы — более строго ограничить размер строки, например. Читал, что некоторым это помогало.

Эти изменения необходимо применить к информационной базе, при этом произойдет реструктуризация вашей таблицы.

Если изменения внесены на SQL-копии базы, то после этого нужно заново выгрузить .DT и попытаться перезагрузить его в файловой версии.

Если SQL-копии нет под рукой, то можно попробовать исправить прямо на вашей недозагруженной файловой копии. После принятия изменений запускайте «Тестирование и исправление» в режиме реструктуризации таблиц базы данных. Индексы будут созданы платформой заново и, можно надеяться, уже без ошибок.

Кому особо не повезло и ошибка вылезла снова — тому следует повторить сначала всю процедуру, начиная с анализа логов. Возможно, проблемная таблица была не одна, или вам не удалось решить проблему с размерами полей, входящих в индекс.

Удачи вам!

Обновлено 15.10.2020

Добрый день! Уважаемые читатели и гости одного из крупнейших IT блогов Рунета Pyatilistnik.org. В прошлый раз мы с вами разобрали, что из себя  представляет файловая система raw, и как ее исправить, чтобы восстановить свои данные. Двигаемся дальше и поговорим сегодня на тему  капризности 1С, точнее на капризную работу в рамках Windows Server 2016. Я рассмотрю причину и устранение периодически повторяющейся ошибки на сервере 1С 8.3 «Ошибка при выполнении файловой операции«. Ее я стал встречать после обновления с Windows Server 2012 R2 д 2016. Думаю мой опыт сэкономит вам часик серфинга по интернету.

Описание проблемы

В моей компании заканчивается обновление операционных систем у виртуальных серверов, с Windows Server 2012 R2 на Windows Server 2016, я понимаю, что поддержка первых еще будет несколько лет, но хочется уже не делать это в последний момент, а слегка опережать, да и уже давно пора стремиться к Windows Server 2019. Сервера 1С не были исключением, обновление происходило по быстрому варианты. Тут подразумевается накатывание более новой версии ОС по верх старой, тут мы убивали двух зайцев:

1. Получали свежую версию ОС
2. Оставляли весь софт на сервере, и не требовалась его переустановка

В случае чего всегда можно было откатиться из снапшота на момент проведения работ, благо ESXI 6.5 это помогает делать в два клика. Все прекрасно обновилось и сервер зажил новой жизнью. В какой-то момент при запуске клиента 1С 8.3 на RDS ферме, стала появляться ошибка:

Устранение проблемы

Начав изучать данный вопрос мы не стали откатываться к бэкапу, так как данная проблема возникала не постоянно, а через некоторые промежутки и была вызвана явно не переходом на более новую версию операционной системы. Подняв исторические данные в системе заявок, я нашел похожую, где решением ошибки был перенос базы данных 1С на другой диск. Меня это заинтересовало и я стал прикидывать, что же могло быть в той ситуации. Через минут 20 я нашел одну закономерность, что на всех проблемных хостах был установлен компонент Windows дедупликации, как раз на тех дисках, где располагались базы данных 1С.

Я для тестирования отключил дедупликацию и вернул все в исходное состояние, и о чудо ошибка при выполнении файловой операции больше не появлялась. Все те же действия я произвел и на остальных серверах.

Из дополнительных методов я могу вам посоветовать еще очистку кэша 1С. Еще в на умных сайтах советуют на серверах, где используется 1С отключать протокол IPv6 на сетевых интерфейсах, но лично я не понимаю этого прикола, так как сама Microsoft советует по возможности этого не делать, в виду того, что очень многие ее сервисы и компоненты Windows в приоритете используют именно его, меньше будет проблем с DNS и Active Directory.

Вообще если у вас виртуальные сервера лежат на системе хранения данных, то у нее должна быть своя функция дедупликации и использовать лучше и правильнее ее. Если у вас есть другие варианты решения данной проблемы, то пишите их в комментариях. С вами был Иван Семин, автор и создатель IT портала Pyatilistnik.org.