Ошибка выполнения запроса ошибка при выполнении запроса post к ресурсу e1cib modules call

• Главная
•  / 
• Статьи
•  / 
• Программирование на 1С:Предприятие
•  / 
• Ошибка при выполнении запроса POST к ресурсу e1cib/modules/call

Одна из новых ошибок 1C — является обращение к модулю по пути /e1cib/modules/call. Данная ошибка является следствие отправки POST запроса к функции размещенной в этом файле. В этой краткой статье мы рассмотрим как решить эту проблему и почему она возникает.

Причины возникновения ошибки работы с ресурсом

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

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

Как решить проблему с модулем call

Для решения этой ошибки, следует обратиться к документации по 1С:Эвотор. Давайте попробуем следовать инструкции:

1. Зайдите в программу
2. Пересоздайте оборудование
3. Повторно загрузите продажи из ККТ

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

Неспецифицированная ошибка работы с ресурсом

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

Заключение

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

Надеемся, что статья вам помогла и вы смогли найти решение своей проблемы.

06.11.19 — 06:13

1 — 06.11.19 — 06:25

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

2 — 06.11.19 — 07:06

какая то срочная необходимость  в 8.3.15  вообще есть ?

3 — 06.11.19 — 07:16

(2) Просто сидели на 8.3.13, а новые конфиги уже рекомендуют 8.3.14. Посмотрели ошибки, что в 8.3.14 что в 8.3.15 одинаковые, решили на последний переходить. Тем более что есть отзывы, что он быстрее.

4 — 06.11.19 — 07:17

Ну и описанное в (0), судя по тому что пишут в инете, происходит буквально на чуть не на всех релизах начиная с 8.3.5. Так что надо понять что за проблема и как ее решать.

5 — 06.11.19 — 08:21

(0) Вчера вышел очередной релиз. Идите дальше.

6 — 06.11.19 — 08:27

(0) посмотри на процессы 1с, скорее всего они перезапускаються в момент падения, изучи журналы ошибок возможно проблемы лицензирования

7 — 06.11.19 — 08:52

(2) Тоже перешли на 8.3.15, ибо

«Рекомендуется использовать текущую версию конфигурации «Управление торговлей», редакция 11 с версией системы 1С:Предприятие 8 8.3.15.1489 (и выше).»

Всё виндовое, MS SQL Server.

После установки платформы 8.3.15.1565 стали возникать периодические вылеты КАМИНа (после ТиИ получше стало, но совсем не исчезло).

А вчера попробовал запустить УТ в толстом клиенте (обычно в тонком работает): постоянные вылеты.

Может, совпадение, но похоже, что дело в толстом клиенте — КАМИН как раз использует толстый клиент. В тонком таких проблем нет.

8 — 06.11.19 — 09:05

(7) У нас похоже наоборот. Щас всех заставили ходить под толстым клиентом и уже полтора часа все норм. ТЖ запустил, логи смотрю, пока никакого криминала, но пока и не рушится ничего.

9 — 06.11.19 — 09:08

(5) Ну каждый день мы не можем релизы менять. Просто пока переходили, тестировали и прочее, выпустили новый релиз и там поправлены пара незначительных ошибок.

10 — 06.11.19 — 09:25

Для статистики.

В течение недели поменял платформу 8.3.15.1700 (Две PG, одна MSQL)

Полёт нормальный

11 — 06.11.19 — 09:34

Хм, почти два часа все было норм, щас опять выкинуло, причем не всех. Может старые конфиги УПП и КА мешают современной ЕРП? Фигово что все на одном РПХосте сидит. Так можно было бы локализовать хоть на предмет какая база выглючивает.

12 — 06.11.19 — 09:36

Может в лицензии ПРОФ есть ограничение на количество соединений/сеансов? У нас в сумме свыше 256 точно бывает, если считать фоновые и вообще все.

13 — 06.11.19 — 09:36

(0) ктож одновременно меняет платформу и субд?

14 — 06.11.19 — 09:38

(12) чисти настройки кластера и заново настраивай

15 — 06.11.19 — 09:38

ТС, не гонитесь за хотелками типовых. Типовая хочет, а платформа не может. Вот как бывает оказывается.

В смысле последние релизы (13-14-15) платформ баговатые идут. И конца и края не видно.

Откатитесь на тот релиз платформы где работало. В крайнем случае поставите отдельно службу 15ю для одной базы, а остальные будут жить спокойно.

16 — 06.11.19 — 09:39

(11) Запустите несколько агентов на разных портах.

17 — 06.11.19 — 09:50

set LOG_FILE="scripts.log"
set SERVICE_1C_NAME="1C:Enterprise 8.3 Server Agent (x86-64)"
set SERVICE_RAS_NAME="1C:Enterprise 8.3 Remote Server"
set CNTX_PATH="C:srvinforeg_1541"
set PFL_PATH="C:ProgramData1C1cv8"
set TEMP_PATH="C:WindowsTemp"
echo stop %DATE% %TIME% >> %TEMP_PATH%%LOG_FILE%
sc stop %SERVICE_1C_NAME%
sc stop %SERVICE_RAS_NAME%
timeout 5
taskkill /f /im "rphost.exe"
taskkill /f /im "rmngr.exe"
taskkill /f /im "ragent.exe"
taskkill /f /im "ras.exe"
timeout 5
echo done stop %DATE% %TIME% >> %TEMP_PATH%%LOG_FILE%
echo clean temp %DATE% %TIME% >> %TEMP_PATH%%LOG_FILE%
DEL /Q /F /S %CNTX_PATH%snccntx*
DEL /Q /F %PFL_PATH%*.pfl
DEL /Q /F /S %TEMP_PATH%*.*
echo done clean temp %DATE% %TIME% >> %TEMP_PATH%%LOG_FILE%

18 — 06.11.19 — 09:51

(13) Мы. Просто появилась возможность сделать все и сразу. Изначально стояла задача перейти на PG, а так как PG хочет не менее 14-ой, то решили не мелочиться и ставить сразу 15-ую. Естественно тестили это дело. (15) Ну 13-ая у нас пока висит, на всякий случай. (16) Тоже вариант, но щас пока смотрим как оно работает без извращений. Есть еще мнение что не почистили кэш, но админы уверяли что почистили, потому что щас выкинуло только двух пользователей, остальные работают.

19 — 06.11.19 — 09:52

(17) Кэш на сервере почистился, ибо базы полностью пересоздавали когда со скуля на PG переводили. Т.е. в оснастке удалялись и создавались заново, по крайней мере со слов админов. 🙂

20 — 06.11.19 — 09:53

(17) «Если баз не много (3-5), то установить в настройках рабочего сервера 1 базу на процесс.

Хотя для начала я бы попробовал наоборот — типовые настройки.

Очень странно, что при 256 сеансах у вас один rphost. » Для этого надо иметь лицензию КОРП, а тут только ПРОФ.

21 — 06.11.19 — 09:56

Вдогонку к (7).

Ну вот, выходит новая конфа Торговли (ничего принципиально нового, только ошибки исправили), и вот на тебе, рекомендуют ещё более новую платформу, чем предыдущая версия конфы:

«Рекомендуется использовать текущую версию конфигурации «Управление торговлей», редакция 11 с версией системы 1С:Предприятие 8 8.3.15.1656 (и выше).»

Если совсем плохо будет, придётся как-то организовывать возможность работы двух платформ для разных БД. Раньше с таким не сталкивался.

22 — 06.11.19 — 11:05

(10) А какие конфигурации, если не секрет?

23 — 07.11.19 — 04:59

Хм. Убрали ключ -debug все заработало. Я понимаю что этот ключик зло на рабочей базе, но должно же и с ним работать. Может че с окружением не так.

24 — 07.11.19 — 05:07

(23) у вас там что, круглосуточная работа?

25 — 07.11.19 — 05:09

(23)И да, вы чистку с отменой отладки не совместили?

26 — 07.11.19 — 05:09

*чистку кэша

27 — 07.11.19 — 05:34

(25) Я вчера вечером, всех выгнал, почистил все кэши. Не помогло. Отключил отладку на сервере. Помогло. На ночь поставил закрытие месяца. Не вылетело до сих пор и пока никого за полтора часа работы не выкинуло. Но в логах много событий типа:

«00:31.881002-0,EXCP,0,process=rphost,OSThread=5664,ClientID=6802,Exception=NetDataExchangeException,Descr=’server_addr=(2)192.168.3.32:59976 descr=2(0x00000002): Не удается найти указанный файл.  line=1149 file=srcDataExchangeServerImpl.cpp'»

и

«00:26.084004-0,EXCP,3,process=rphost,p:processName=ERP_SINAR,OSThread=8140,t:clientID=125,t:applicationName=BackgroundJob,t:computerName=1CSA,t:connectID=3800,SessionID=1267,Usr=Жмаева Л.Д.,Exception=SeanceContextException,Descr=’Сеанс отсутствует или удален

ID=4828417a-f23b-4e5b-8c3f-f9dd08327b56, File=srcClusterDistribImpl.cpp(1640)'»

Хотя пользователи ни на что не жалуются. Твои тезки периодически завершаются и появляются новые вместо них. 🙂

28 — 07.11.19 — 05:37

А вообще ЕРП на 8.3.15 и PG довольно быстро работает, по сравнению с 8.3.13 и MSSQL 2005, при прочих равных (оборудование и ОС остались теми же).

29 — 07.11.19 — 06:24

(28) сравнил версионник и блокировочник на управляемых блокировках!!! Но только пока не забываешь регулярно постгри обслуживать(бывает и раз в сутки это мало, но это про хайлоад) — он к этому более требователен чем сиквел.

30 — 07.11.19 — 06:32

(27) «Отключил отладку на сервере. Помогло. »

А включать отладчик по http пробовали? Просто интересно.

31 — 07.11.19 — 06:42

32 — 07.11.19 — 07:02

(30) Нет. Не пробовали.

33 — 07.11.19 — 07:18

(29) А че конкретно надо регулярно запускать для обслуживания?

34 — 07.11.19 — 08:21

(33) vacuum analize — дабы похерить старые версии и обновить статистику.

35 — 07.11.19 — 08:21

+ (34) автовакуум не всегда отрабатывает…

36 — 07.11.19 — 08:22

(34) А что там в новых версиях постгреса со статистикой неявных временных таблиц (подзапросов), починили её? А то, помнится, он ооочень часто ошибался раньше и гонял нестед лупы.

37 — 07.11.19 — 08:38

(36)говорят стало лучше, самому некогда пощупать — работы просто пипец… вото ветка где спецов по постгри есть: Какую версию PostgreSQL ставить?

38 — 07.11.19 — 08:46

Все равно выкидывает. Значительно реже и не в таких масштабах (меня с двух разных баз выкинуло по одному разу за 4 часа), но выкидывает. Щас есть два мнения: 1. Что то с сетью или сетевыми интерфейсами. 2. На новой платформе могут работать только новые конфиги и надо убирать все старые на старую платформу.

39 — 07.11.19 — 08:48

+(38) При этом закрытие месяца работало всю ночь и еще потом два часа днем и доработало до конца без ошибок. Т.е. проблемы начались когда подтянулись пользователи. Буду пробовать добиваться чтобы все старые конфиги убрали с новой платформы.

40 — 07.11.19 — 08:56

Писал уже в (6) проверьте процессы они перезапускаются ? если да проверьте логи скорее всего отваливается лицензия следовательно падает процесс который не сразу перезапускается ибо лицензия глюкнула, если конфа работает под толстым клиентом то это 100% вылет пользователя если под тонким может и незаметно пройти если падение не долгое было.

41 — 07.11.19 — 08:57

(40) естественно чтобы посмотреть логи необходимо настроить технологический журнал.

42 — 07.11.19 — 09:01

(40) Да, процессы перезапускаются. Причем активно. Хотя меньше чем вчера. (41) Настроил ТЖ, но в этом потоке сообщений про лицензию не вижу ничего. Какую надо включить настройку и по какому признаку потом искать именно эти записи?

43 — 07.11.19 — 09:01

44 — 07.11.19 — 09:02

(40) Выкидывает не всех и не изо всех баз. Т.е. как-то выборочно.

45 — 07.11.19 — 09:03

(43) Менять можно. Но при входе очередного пользователя ругается что параметры надо задать по умолчанию.

46 — 07.11.19 — 09:06

47 — 07.11.19 — 09:08

(42) если есть возможность поставь атрибут «ALL» (возможны тормоза) чтобы всвё видеть или «SRVC» чтобы посмотреть что с сервисами происходит

48 — 07.11.19 — 09:12

(46) на разных сервисах возможно народ висит при этом вылетел только один, при таком раскладе из толстого клиента выкинет в тонком пройдет не заметно на рабочей процесс переползет (если есть рабочий).

49 — 07.11.19 — 09:24

запусти пинг на долго… потом когда стопнешь через часик — посмотри % потерь. Насколько помню >0,05% — уже очень плохо

50 — 07.11.19 — 09:31

(49) Тогда лучше уж писать результаты пинга в файл txt.  И потом анализировать.

51 — 07.11.19 — 09:39

(46) Это первое что сделали. Меня тоже выкинуло.

52 — 07.11.19 — 09:40

53 — 07.11.19 — 09:40

(49) Пинг с какой машины и до какой?

54 — 07.11.19 — 09:42

(52) Ну если что, то можем быстро переползти обратно на 8.3.13. Щас пока работаем. Но думаю что в итоге так и поступим.

55 — 07.11.19 — 09:42

(53) От клиента к серверу. На машине проблемного пользователя ping SERVER1C….

56 — 07.11.19 — 09:42

57 — 07.11.19 — 09:44

(54) Я бы на 8.3.13 не рисковал, точнее говоря, успешно его пропустили и сели на 8.3.14.1779

В сентябре вернули параметры на дефолтные и продолжаем пока сидеть на нем.

58 — 07.11.19 — 09:44

(56) Нужно ни на какой, а рекомендуется уже на последней ЕРП. Ну и с PG 10.10 тоже рекомендуется уже 8.3.14, хотя еще пару недель назад было 8.3.15, потом поменяли почему то, может именно по этому.

59 — 07.11.19 — 09:45

(57) Если на 8.3.14, то это снова на неделю минимум подготовка, чтобы у всех ее установить.

60 — 07.11.19 — 09:45

(53) с на какой валится до сервера 1С, если серверов несколько — до каждого из них.

61 — 07.11.19 — 09:49

(52) Точно -l 60000? У меня при таком параметры 100% потери пакетов.

62 — 07.11.19 — 09:50

(55) Нет проблемного пользователя. Всех с разной периодичностью выкидывает.

63 — 07.11.19 — 09:52

64 — 07.11.19 — 09:54

(63) не ниже 8.3.12 вроде. Чего вы нас путаете? Это рекомендованная 8.3.14, это разные вещи, неи ниже и рекомендованная.

65 — 07.11.19 — 09:57

(61) Да. /l 60000. Потери могут быть но незначительные.

Можешь попробовать с меньшими значениями. Например, с 1000.

66 — 07.11.19 — 10:00

(64) Никто никого не путает. Я писал на сообщение автора ветки в (58) о версии СУБД PG 10.10.

Она (PG 10.10) работает с платформой НЕ НИЖЕ 8.3.14. То есть вполне совместима с 8.3.15.

При откате на 8.3.13 использование PG 10.10 на свой страх и риск. Вроде как, должно работать, но это не точно и 1С это не проверяла.

67 — 07.11.19 — 10:00

(61) Ну значит у вас стоит оборудование которое не тянет. коммутаторы/свитчи не все тянут или игнорируют больше заявленного размера.

68 — 07.11.19 — 10:03

ОФФ. Вообще странно, что сплошь и рядом встречается игнорирование требований совместимости со стороны пользователей и непонимание того, чем отличается «необходимо» от «рекомендуется» и требования к конфигурации и к СУБД.

69 — 07.11.19 — 10:05

(61) У вас сеть точно проводная, не WiFi?

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

70 — 07.11.19 — 10:06

71 — 07.11.19 — 10:08

(69) Или выяснится что петля в сетке и как только нагрузка на локалку слега вырастает («когда зашли все пользователи») сетевой шторм начинается ))

72 — 07.11.19 — 10:10

Админам скажи чтоб iPerf -ом проверили  и в НЕ рабочее время. А то всю локаль положат.

73 — 07.11.19 — 10:29

(36) https://forum.infostart.ru/forum86/topic229257/#message2327174

В 7-ом сообщении текст запроса на 1С и его трансляция в PostgreSQL.

Не думаю, что довели оптимизатор до такого состояния, чтобы он с легкостью работал с подобным. Жаль, что нет плана этого запроса.

74 — 07.11.19 — 10:35

(73) Джойн с подзапросом — тяжелый случай для постгреса всегда был. А в 1с это сплошь и рядом, ибо виртуальная таблица регистра это по сути подзапрос. Суть в том, что на момент формирования плана основного запроса еще нет информации о том, какова будет статистика подзапроса, и оптимизатор её оценивает как-то эвристически. И в большинстве случаев предполагает, что результат будет мелкий, а в 1с он как правило большой. Тут всю систему надо менять, отказываться от принципа формирования плана «сверху вниз», в сторону формирования плана «снизу вверх» с выполнением подзапросов ДО формирования плана запроса верхнего уровня. Но это вряд ли будет в постгресе.. никому кроме 1с это не надо.

75 — 07.11.19 — 10:42

(65) /l 60000 — 100% потерь во все стороны, /l 6000 — норм. Уверен, что нолями не ошибся? Проблем с сетью, с 1С нет.

76 — 07.11.19 — 10:59

(71) от петли обычно в итоге сеть ложится

77 — 07.11.19 — 11:03

(75) Уверен. Нолями не ошибся. 60000 — это максимально возможный размер буфера (точнее — 65536).

Насколько большими пакетами обменивается 1С — я не знаю. Вполне возможно, что и 1000 достаточно.

У меня с 60000 потерь нет.

78 — 07.11.19 — 11:07

(77) Даже при /l 20000 — потери: 50%

79 — 07.11.19 — 11:25

(78) То что потери при больших пакетах это еще ничего не говорит.

80 — 07.11.19 — 11:38

(77) Между сервером 1С и сервером PG ставил 60000 — норм. Между моим компом и сервером 1С 100% потери, может из-за того что 100Мб сеть или куча всякого между нами. Но до перехода на 8.3.15 все же работало. Что интересно оно и на тестовом сервере, в котором пользователи на корпии базы всякое крутили, все работало норм.

81 — 07.11.19 — 13:05

(80) а у вас там до кучи админы что-то перепилить не решились пока вы платформу и базовод не апнули?

82 — 07.11.19 — 13:10

83 — 07.11.19 — 13:14

84 — 07.11.19 — 16:34

(82) Спасибо, попробуем.

85 — 07.11.19 — 16:39

Регл. задание Обновление агрегатов отключено. Агрегатами вообще не дает никак управлять. Т.е. погашены закладки и кнопки касающиеся агрегатов.

86 — 07.11.19 — 17:32

(82)ээээ, если корп и серверов есть — все фоновые можно подальше засунуть.

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

87 — 11.11.19 — 10:01

Что то совсем все плохо. Щас при проведении документов начало ругаться что объект не найден. Все встало колом. PG жрет процессор под 100%, при этом все висит. Какой-то так себе опыт перевода на PG получается. 🙂

88 — 11.11.19 — 10:03

Или мы не умеем ее готовить или ERP 150Г и 150 пользователей в принципе не способна работать на PG.

89 — 11.11.19 — 10:31

(87) В БГУ 1.0 на PostgreSQL 10.10 проведение одного из документов(внутреннее перемещение) может приводить к такому же эффекту, причем еще занимается вся доступная память, включая своп, после чего процесс postgres самоубивается с криками «Out of memory!» и всех выкидывает.

enable_nsetloop=off не помогает.

На 9.6.7 и 11.5 такого происходит.

90 — 11.11.19 — 10:43

К (89) Такого не происходит.

91 — 11.11.19 — 10:44

А «объект не найден» больше похоже на платформу, чем на СУБД. Может, совокупность версий конфигурации и платформы.

92 — 11.11.19 — 11:03

(91) Может. Просто чем дальше тем хуже. Возможно с индексами проблема, хотя делали реиндекс базе. Щас наверное откатим на MS SQL, а на копии посмотрим че это за фигня. Проблема конкретного документа или с базой чета. Тут вообще все странно, отражение в регл. учете запускается, в регистре к отражению все документов 30, но он часами не может их отразить, фоновое задание висит и только в размерах пухнет.

93 — 12.11.19 — 07:19

Хм. Короче. Выяснилось что упирается в дисковую подсистему. Длинная очередь к диску. Даже крутой рейд 10 не помогает. Поставили базу на SSD 970 EVO PLUS — все начало летать, право пока только половина пользователей ее нагружают, но раньше все висело даже на меньшем количестве. PG любит быстрые диски. Ну таки SDD даже если каждый год менять, то это все-равно дешевле, чем покупать новый MS SQL, раз так в 50. 🙂 Щас вот думаем, таки в продакт завести SSD или воспользоваться вредными советами и отключить fsync и прочее, ибо типа на рейде есть батарейка и не страшно.

94 — 12.11.19 — 07:55

(93) А включить асинхронную запись в постгресе пробовали?

95 — 12.11.19 — 08:03

(94) Нет пока. Админы тут посмотрели статистику и выяснили что просела производительность дисков. Короче, расследование показало очевидную вещь. У PG куча мелких файлов и он в процессе работы еще не меньшую кучу создает. Т.е. нужен быстрый произвольный доступ, что SSD конечно предоставляет с легкостью, а массив на SAS, пусть даже серверных дисках, не может. Отсюда же понимание почему у MS SQL не было таких проблем — там два больших файла на базу и еще несколько служебных и нужно быстрое последовательное чтение, что конечно уже рейд легко дает. Так что пока ситуёвина такая: если хотите переходить на PG да еще с большими и нагруженными базами, то нужны SSD или какие-то другие массивы с большой скоростью произвольного доступа.

96 — 12.11.19 — 08:17

(95) Ну это понятно. Просто интересно, проседает ли производительность с включенной асинхронной записью, то есть очередь возникает на чтение или на запись.

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

97 — 12.11.19 — 08:20

+(96) «по сети» читать как «по сути»)

98 — 12.11.19 — 10:51

(93) На RAID контроллере с кэшем и батарейкой и(тем более) SSD влияние fsync почти не заметно, можно даже full_page_writes включить для большей безопасности.

Еще PostgreSQL любит, чтобы вся база(или большаяя ее часть) была в shsred buffers, а shared buffers можно поместить  в huge pages, huge page сделать размером в 1ГБ..

Еще всем процессам PostgrSQL(autovacuum, сборщик статистики, bgwriter) нужны незанятые ядра, чтобы не тормозить.

99 — 12.11.19 — 11:15

Поставили SSD

Пользователи стали более лучше и быстрее переключаться с упавшего rphost-а 🙂

profit

100 — 12.11.19 — 11:27

(99) Ну это да, это косяк платформы. 🙂 Будем переходить на 8.3.16, там в последнем вроде как раз эти косяки с падением процессов пофиксили. Но вообще это конечно засада. После 8.3.12 ни одного стабильного релиза. Они бы вместо всяких, мало кому нужных, рюшечек довели бы до ума платформу, чтобы она тупо не падала от любого чиха. А то похоже на продукцию АвтоВАЗа еще лет 10 назад, когда в рассыпающемся ведре с болтами кучу всяких наворотов, которые тоже через раз работают.

Самое читаемое:

17.03.2022

Как установить дополнительные виджеты на экран телефона Андроид

Если у Вас возникли сложности с тем, чтобы добавить виджеты приложений на смартфон, то это пошаговое руководство…

Далее

17.03.2022

Как очистить кэш телеграмма на телефоне Андроид

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

Далее

17.03.2022

Как скопировать ссылку на свой телеграмм Андроид

Любой из пользователей мессенджера Телеграм в тот или иной момент времени задавался вопросом, как узнать, где…

Далее

02.03.2022

Ошибка 104101 в Zoom – как исправить

Содержание1 Ошибка 104101 в Zoom – как исправить1.1 Причины ошибки1.2 Смена параметров брандмауэра Windows1.2.1 Отключение…

Далее

Содержание:

1.       Почему появляется эта ошибка 1с 8?

2.       Исправление ошибку POST  

1.    Почему появляется эта ошибка 1с 8?

В процессе работы с 1С порой появляется сообщение «Ошибка при выполнении запроса POST к ресурсу /e1cib/logForm». Данное сообщение достаточно нередко связано с кодом 1С 8.3 в новых релизах 1С.

Рассмотрим, в чем же заключается «неправильность» выполнения запроса POST к ресурсу 1С, каковы первопричины ее образования и как с ней бороться.

В тексте сообщения обычно содержится растолкование источника появления проблемы – это ошибка 1С 8 либо на сервере, либо СУБД, либо какая-то другая.

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

2.    Исправление ошибку POST

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

· Провести типовое Тестирование и Исправлении базы 1С 8 (в конфигураторе в пункте меню «Администрирование» выберите Тестирование и исправление). Предварительно обязательно подготовьте архивную копию базы 1С 8!

· Установить последние актуальные обновления к базе 1С 8.

· Откатить программу 1С до предыдущей версии/релиза (восстановить копию базы 1С, сделанную до выполнения обновления).

· Работая с Windows, можно очистить сеансовые данные. Для этого потребуется остановить службу сервера базы 1С, после чего в папке C:Program Files1cv8srvinforeg_1541snccntx + *уникальный идентификатор* удалить все за исключением файлов, которые имеют расширение *.1, а затем обратно запустить «Сервер 1С».

· Перезапустить сам сервер 1С Предприятие.

· Обратиться на линию консультаций в официальную поддержку фирмы «1С». Кстати, Вы также можете обратиться и к нам по этому или любому другому вопросу. Мы всегда на связи и с радостью поможем решить Вашу проблему.

Специалист компании «Кодерлайн»

Иванова Ольга