Куперс

Бухучет и анализ

1С ошибка 120

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

Нарушена целостность структуры конфигурации

Рис.1

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

Создайте резервную копию!

Рис.2

Если конфигуратор не доступен, надо скопировать базы в другую папку на ПК или на флешку. Хотя при использовании способа, которым мы будем избавляться от этой ошибки, ничего критического произойти не должно, поскольку доработок конфигурации 1С он не предусматривает.

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

Избавляемся от ошибки – чистим кэш

Для того чтобы почистить этот самый кэш, нам надо узнать, где он хранит свои данные через «Настройку» в окне запуска.

Чистим кэш

Рис.3

В настройках смотрим путь к каталогам шаблонов и обновлений. Наши временные файлы кэш хранятся в папке Roaming. Мы видим ее прописанную в указанном пути.

Чистим кэш

Рис.4

Найдем и откроем эту папку через «Мой компьютер». Если вы папку не находите, так как она может быть скрыта настройками компьютера, надо в меню «Сервис»-«Параметры папок…» установить видимость скрытых файлов. Вызвать строку меню в окне можно нажав кнопку «Alt».

Чистим кэш

Рис.5

В открывшемся окне на закладке «Вид» устанавливаем переключатель в положение «Показывать скрытые файлы и папки».

Показывать скрытые файлы и папки

Рис.6

Скрытые папки появились. Переходим далее в папку Roaming, где находится множество файлов и папок, где выделенные папки с цифрами и буквами – это и есть папки с файлами кэш. Их можно удалять, при запуске программа вновь создаст новые файлы.

Переходим далее в папку Roaming

Рис.7

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

Внизу окошка будет указан путь к выделенной информационной базе

Рис.8

Открыв папку, мы видим в ней файлы. Файл 1Cv8 – это файл конфигурации, его трогать нельзя, это наша информационная база, а остальные файлы временные, их также можно удалить.

Открыв папку, мы видим в ней файлы

Рис.9

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

Если работа исправление ошибок вызывает у вас вопросы, обратитесь к нашим специалистам. Мы проконсультируем и подберем для вас оптимальную стоимость сопровождение 1С, ориентируясь на ваши индивидуальные потребности.

Записки IT специалиста

Ошибки информационной базы 1С:Предприятия — вещь крайне неприятная, особенно при отсутствии резервных копий. А если такая неприятность все-таки приключилась, то приходится порой принимать нестандартные и идущие в противоречие с общепринятыми практиками решения. Но это не должны быть шаманские камлания с бубном, а логически обоснованные и точно выверенные действия, которые позволят выйти победителем из, казалось бы, безнадежной ситуации. Сегодня мы расскажем об одном таком случае из нашей практики.

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

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

При этом в повседневной жизни данная ошибка никак себя не проявляла, и утилита chdbfl также не нашла в базе каких-либо ошибок. Тем не менее база оказалась серьезно повреждена и любые попытки спасти ситуацию малой кровью: выгрузить данные в узел РИБ или посредством выгрузки-загрузки через XML приводили к ошибкам.

«А как-же резервные копии?» — спросит иной читатель. Резервные копии содержали точно такую же ошибку, так как она не препятствует выгрузке в DT файл и, тем более, архивированию непосредственно файла базы. Можно сказать, что клиент столкнулся с распространенной ошибкой начинающих администраторов, когда резервные копии создаются, но не проверяются.

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

На Инфостарте была найдена статья, которая на первый взгляд обещала привести к успеху, но все стало только хуже, раньше хотя бы конфигуратор открывался:

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

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

Здесь мы вплотную подошли к одному из самых распространенных мифов 1С — очистке кеша. Со временем это переросло в какой-то магический ритуал: не знаешь, что делать — очисти кеш. Давайте разберемся, что такое этот кеш и зачем он нужен.

Не для кого ни секрет, что многие данные в информационной базе не меняются в течении длительного времени и поэтому нет необходимости каждый раз их запрашивать из БД, а можно поместить в локальный кеш и брать оттуда. Кеш делится на пользовательский, где хранятся данные, с которыми работает пользователь и кеш конфигурации, где сохраняются программные модули и данные о конфигурации. Первый располагается в перемещаемой части профиля пользователя %USERPROFILE%\AppData\Roaming\1C, а второй в его локальной части %USERPROFILE%\AppData\Local\1C.

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

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

В нашем случае проявлению указанной ошибки могла поспособствовать именно очистка кеша конфигурации. Если до повреждения ИБ конфигурация была открыта (а она была, т.к. базу обновляли), то при загрузке конфигуратора должны были быть подгружены кешрованные данные, что дало бы возможность либо обновить конфигурацию, либо загрузить ее из файла. После очистки кеша такая возможность пропала.

Но вернемся к нашей базе. Что именно произошло? До замены кеша база могла загрузиться в конфигуратор, после его замены — уже не смогла. Следовательно, в кеше поврежденной базы хранились нужные части конфигурации, которых в кеше исправной не оказалось, либо они оказались неидентичными загружаемой конфигурации. Поэтому в нашем случае кеш нам не враг, а наоборот друг и мы должны его не очищать, а наоборот, сохранить.

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

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

Теперь дело техники, снимаем поврежденную конфигурацию с поддержки и загружаем из файла конфигурацию того же релиза, которую можно выгрузить из заведомо исправной базы или взять из комплекта поставки. Сохраняем, обновляем конфигурацию базы данных.

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

Ошибки 1С — Коды ошибок 1С 7.7, 1С 8.1, как их решать   

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

1. Правильная интерпретация ошибки.

2. Воспроизведение ошибки.

3. Исправление ошибки 1С.
Опишем эти этапы подробнее.

Правильная интерпретация ошибки

Этот этап самый важный, так как правильное определение природы ошибки поможет избежать избыточного расходования ресурсов в будущем. На нашей практике встречалось множество компании, сотрудники которых используют бессистемный подход к решению проблем 1С, не имея даже представления о том, с чего начать. Для объективного анализа проблем мало информации поступающей от пользователя, необходимо также использовать весь объем информации от сервера БД, сервера приложений, самой системы 1С в виде технологического журнала и замера производительности, журнала Windows и MS SQL. Без анализа всей информации в комплексе, в лучшем случае, эффективность исправления ошибок будет на несколько процентов, что абсолютно не устраивает конечного потребителя, а в худшем (для некоторых типов ошибок) — ситуация может усугубиться и тогда времени для принятия решений будет очень мало. Мы рекомендуем осуществлять периодический контроль, сбор информации из разных источников по работе системы, чтобы при появлении ошибок можно было оперативно разобраться с событиями, которые привели к ним и принять взвешенное управленческое решение по исправлению. Как пример, помощь в сборе комплексной информации об ошибках и сбоях системы может предоставить комплекс мониторинга производительности «PerfExpert».

Воспроизведение ошибки

Данный этап требуется для подтверждения правильности интерпретации ошибки, контроля исправления и тестирования. В ряде случаев ошибку сложно смоделировать и тестирование придется совместить с работой «боевой» информационной системы.

Исправление ошибки

После правильного определения природы ошибки 1С само действие по исправлению представляется, как наименее затратная и дешевая работа. К ней обычно привлекаются рядовые ИТ специалисты, а отличие от первых двух этапов, где в основном задействованы аналитики и эксперты.
Ошибки 1С условно можно разделить на несколько групп:

1. Ошибки, связанные с функционированием платформы 1С 7.7., 8.1.

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

2. Ошибки, связанные с функционированием БД системы 1С.

К ним относятся ошибки ожидания блокировки MS SQL, взаимоблокировки, другие ошибки MS SQL. Эти ошибки можно диагностировать с помощью различных средств, например, мониторинг производительности «PerfExpert» или профайлер MS SQL. «Софтпоинт» имеет большой опыт исправления подобных ошибок, например с применением технологии «Гибкие блокировки».

3. Ошибки, связанные с нехваткой аппаратных или программных ресурсов. Например, нехватка оперативной памяти, нехватка памяти для блокировок и т.п. Они диагностируются аналогично предыдущему типу ошибок и исправляются корректировкой настроек Windows, MS SQL.
4. Ошибки, возникающие спонтанно в процессе работы системы 1С.

Например, это может происходить из-за неравномерного распределения запросов пользователей между ресурсами серверов. Один пользователь может запустить конструкцию на языке 1С, которая займет 90% всех ресурсов сервера. Таким образом, остальным пользователям в этот момент времени не достанется необходимого количества ресурсов и возникнет ошибка. Для исправление таких ошибок необходим непрерывный контроль ситуации в информационной системе, например, с применением мониторингоа производительности PerfExpert.

Ниже приведены коды ошибок и их описания:

10 — Ошибка закрытия файла

20 — Ошибка создания файла

30 — Ошибка определения длины файла

40 — Ошибка установки длины файла

50 — Ошибка при попытке заблокировать файл

60 — Ошибка при открытии файла

70 — Ошибка чтения файла

80 — Ошибка даления файла

90 — Ошибка переименования файла

100 — Ошибка позиционирования в файле

110 — Ошибка снятия блокировки с файла

120 — Ошибка записи в файл

200 — Файл не является базой данных DBF-формата

210 — Неопознанное имя поля

220 — Неопознанный тип поля

230 — Запись слишком длинная

300 — Индексный файл не содержит информации о записи

310 — Нарушение структуры индексного файла

330 — Указанное имя индекса недоступно

340 — Ошибка уникальности индекса

400 — Ожидается запятая или скобка

410 — Выражение не завершено

422 — IFF() требует параметров одинаковой длины

425 — У STR() и SUBSTR() 2-й и 3-й параметры — константы

430 — Неверное число параметров

440 — Слишком сложное выражение

450 — Пропущена правая скобка

460 — Неверный тип подвыражения

470 — Неопознанная функция

480 — Неопознанный оператор

490 — Неопознанное значение

500 — Выражение не завершено символом двойной кавычки

920 — Недостаточно памяти

Ошибка при выполнении запроса POST к ресурсу /e1cib/logForm

При обмене данными клиент-сервер в программе «1С Бухгалтерия» (обычно версий 8.3.хххх) оператор локального ПК может внезапно столкнуться с сообщением «Ошибка при выполнении запроса POST к ресурсу /e1cib/logForm». Данная проблема обычно имеет программную природу, и вызвана некорректно написанным обновлением к данной программе. Ниже я разберу, что это за ошибка запроса POST к ресурсу /e1cib/logForm, каковы факторы её возникновения, и как её исправить.

Перевод и причины дисфункции

После текста сообщения об ошибке при обращении к /e1cib/logForm обычно следует описание причины её возникновения, которая может иметь различный характер (ошибка на сервере, ошибка СУБД и другие).

Проблема возникает на серверной версии программы, причём после установки очередного обновления к «1С». Проблемными стали версии программы 8.3.6, 8.3.8.хх, 8.3.9.ххх, на которых рассматриваемая мной дисфункция возникает наиболее часто.

«Ошибка при выполнении запроса POST к ресурсу /e1cib/logForm» возникает довольно случайно, в большинстве случаев не имеет каких-либо закономерностей при своём появлении, чем раздражает довольно многих пользователей, заваливающих техподдержку 1С «письма счастья».

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

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

Как исправить ошибку запроса POST к ресурсу /e1cib/logForm

Чтобы избавиться от ошибки POST к ресурсу /e1cib/logForm рекомендую выполнить следующее:

  • Выполните стандартное «Тестирование и Исправлении» (ТиИ) вашей базы данных. Данная операция осуществляется переходом в «Конфигуратор», где во вкладке «Администрирование» необходимо выбрать опцию «Тестирование и Исправление». Операцию необходимо осуществлять в монопольном режиме, потому никого кроме вас в базе быть не должно. Перед выполнением указанной процедуры рекомендуется сделать страховочную копию ваших баз данных; Выполните исправление вашей базы данных
  • Установите наиболее свежие обновления к вашей версии 1С. Поскольку пик появления данной ошибки пришёлся на 2016-2017 годы, то с тех пор разработчиками был выпущен ряд обновлений, позволяющих устранить данную ошибку. Установите свежие апдейты для вашей «1С», и если не помогло, то идём дальше;
  • Откатите программу до прежней версии. В некоторых случаях (когда у пользователей было установлены самые свежие обновления) помог откат программы до более ранней (и более стабильной) версии программы;
  • При доступе к серверу 1С рекомендуется почистить кэш. Остановите на сервере службу под названием «агент сервера 1с предприятие», в каталоге кэша сервера удалите всё кроме файлов, имеющих расширение *.1 Примерный путь к каталогу может быть:

Program Files\1cv8\srvinfo\reg_1541

После чего вновь запустите указанную службу;

  • Перезапустите сам сервер 1С Предприятие. У некоторых пользователей это помогло решить проблему запроса POST к ресурсу /e1cib/logForm;
  • Обратитесь в официальную поддержку 1С за консультацией и помощью. Также может помочь обращение по сети (к примеру, на е-мейл v8@1c.ru) или по телефону (495) 956-11-81 в техническую поддержку 1С. Поскольку рассматриваемая ошибка имеет массовый характер и наблюдается не первый год, то наверняка у специалистов техподдержки уже имеются работающие алгоритмы решения возникшей проблемы.
  • Также на нашем сайте мы разобрали ошибку 0400300003, связанную с нарушением условия обязательного присутствия элемента.

    Заключение

    Основным фактором возникновения ошибки запроса POST к ресурсу /e1cib/logForm является некорректно написанный разработчиками код обновления к программе «1С». Эффективным решением возникшей проблемы станет обновление вашей версии 1С до самой свежей версии, где рассматриваемая дисфункция уже исправлена, и появлений рассматриваемой ошибки более не наблюдается.
    Если Вам нужна помощь в решении данного вопроса, пожалуйста, обращайтесь к нам, по номеру телефона +7 978 585 67 88
    и наши специалисты помогут Вам.

Неправильный путь к файлу при запуске 1С

Пользователи, при запуске 1С с удаленных компьютеров могут увидеть ошибку ”Неправильный путь к файлу”.


Рис. 1. Окно с ошибкой

Прежде всего, нужно убедиться:
1.) Включен ли компьютер, на котором содержится база;
2.) Правильно ли прописан путь;
3.) Вставлены ли все сетевые провода или работает ли Wi-Fi.

Если все пункты соблюдены, то скорее всего неправильно настроены сетевые настройки. Обычно они могут слететь при обновлении операционной системы. Для решения данной проблемы мы должны:

Найти папку, в которой лежит база, и нажать по ней правой кнопкой мыши и выбрать пункт “Свойства”.

Рис. 2. Свойство папки с базой

Далее переходим на вкладку “Доступ” и там нажать кнопку “Общий доступ”.


Рис.3. Общий доступ

Появляется окно “Общий доступ к файлам”, там для пользователя “Все” должен быть установлен уровень разрешений “Чтение и запись”.


Рис. 4. Настройка доступа к папке

После этого снова будет открыто окно «Свойства папки». В нем нужно проверить вкладку «Безопасность», там должен быть полный доступ для группы «Все».


Рис. 5. Проверка полного доступа

Далее нужно нажать правой кнопкой мыши по значку сети внизу справа в углу и выбрать пункт “Открыть параметры сети и Интернет”:

Рис. 6. Открытие параметров сети

Появляется окно, в котором нам нужно выбрать пункт “Ethernet”, и после справа сверху в углу выбрать “Изменение расширенных параметров общего доступа”.

Рис. 7. Изменение расширенных параметров общего доступа

И дальше настроить параметры, как продемонстрировано на рисунках 8-10.

Рис. 8. Сетевой профиль “Частная”

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *

Наверх