Невосстановимая ошибка. Ошибка при выполнении запроса POST к ресурсу /e1cib/logForm:
Выглядит данная ошибка вот так:
Сначала напишем список предположительных причин данной ошибки, которые Вы можете найти в интернете и которые являются ОШИБОЧНЫМИ:
- Ошибка в релизе 1С
- Ошибка в платформе 1С
- Повреждение базы данных (требующее лечения с помощью «Тестирования и исправления»)
- Ошибка кэша
- Ошибка сервера 1С (предлагается перезапуск службы сервера 1С)
Нет, все перечисленное не имеет отношения к действительности. Иногда проделанные выше действия, кажется, что помогают с исправлением ошибки. Но просто совпадение с решением одновременно реальной причины.
Сложность разбора реальной причины данной проблемы заключается в том, что воспроизводится она непредсказуемым образом.
Замечено, что ошибка воспроизводится практически только при клиент-серверном режиме работы. И обычно при выполнении длительных операций.
«Ошибка при выполнении запроса POST» — есть информация, что ошибка возникает при выполнении длительных, нагруженных операций над базой данных в ситуациях, когда у процесса rphost заканчивается разрешенная оперативная память на процесс.
Нашей рекомендацией является – снять ограничение на количество оперативной памяти на рабочий процесс сервера 1С.
Также может помочь переход с х86 сервера 1С на х64.
Либо иногда может помочь обновление платформы 1С на актуальный релиз и/или перезапуск сервера 1С. Перезапуск понятно, почему помогает. При этом освобождаются ресурсы.
В целом рекомендуем такую ресурсоемкую задачу, как перенос данных 1С, выполнять на мощном оборудовании, с использованием SSD-дисков, если возможно, то файлового режима работы для базы 1С-приемника данных. Если файловый режим невозможен, то рекомендуется использовать только сервер 1С разрядности х64.
Для снятия ограничений на потребление памяти нужно в консоли сервера 1С зайти в свойства рабочего сервера, как показано на скриншоте:
Если для настроек указать значения «-1», как на скриншоте, то данные ограничения для сеансов использоваться не будут. То есть не будет выполняться завершение сеансов, которые потребляют много оперативной памяти.
Используйте эту настройку под свою ответственность. Нужно понимать, что в большинство случаев при параллельной работе большого количества пользователей вы получите стабильную работу сервера 1С все-таки если не будете отключать данную настройку.
Мы рекомендуем устанавливать значения «-1» только на время выполнения задачи переноса данных 1С, либо другой нужной Вам ресурсоемкой задачи.
При обмене данными клиент-сервер в программе «1С Бухгалтерия» (обычно версий 8.3.хххх) оператор локального ПК может внезапно столкнуться с сообщением «Ошибка при выполнении запроса POST к ресурсу /e1cib/logForm». Данная проблема обычно имеет программную природу, и вызвана некорректно написанным обновлением к данной программе. Ниже я разберу, что это за ошибка, каковы факторы её возникновения, и как её исправить.
Сначала напишем список предположительных причин данной ошибки, которые Вы можете найти в интернете и которые являются ОШИБОЧНЫМИ:
- Ошибка в релизе 1С
- Ошибка в платформе 1С
- Повреждение базы данных (требующее лечения с помощью «Тестирования и исправления»)
- Ошибка кэша
- Ошибка сервера 1С (предлагается перезапуск службы сервера 1С)
Нет, все перечисленное не имеет отношения к действительности. Иногда проделанные выше действия, кажется, что помогают с исправлением ошибки. Но просто совпадение с решением одновременно реальной причины.
Сложность разбора реальной причины данной проблемы заключается в том, что воспроизводится она непредсказуемым образом.
Замечено, что ошибка воспроизводится практически только при клиент-серверном режиме работы. И обычно при выполнении длительных операций.
«Ошибка при выполнении запроса POST» — есть информация, что ошибка возникает при выполнении длительных, нагруженных операций над базой данных в ситуациях, когда у процесса rphost заканчивается разрешенная оперативная память на процесс.
Нашей рекомендацией является – снять ограничение на количество оперативной памяти на рабочий процесс сервера 1С.
Также может помочь переход с х86 сервера 1С на х64.
Либо иногда может помочь обновление платформы 1С на актуальный релиз и/или перезапуск сервера 1С. Перезапуск понятно, почему помогает. При этом освобождаются ресурсы.
В целом рекомендуем такую ресурсоемкую задачу, как перенос данных 1С, выполнять на мощном оборудовании, с использованием SSD-дисков, если возможно, то файлового режима работы для базы 1С-приемника данных. Если файловый режим невозможен, то рекомендуется использовать только сервер 1С разрядности х64.
Для снятия ограничений на потребление памяти нужно в консоли сервера 1С зайти в свойства рабочего сервера, как показано на скриншоте:
Если для настроек указать значения «-1», как на скриншоте, то данные ограничения для сеансов использоваться не будут. То есть не будет выполняться завершение сеансов, которые потребляют много оперативной памяти.
Используйте эту настройку под свою ответственность. Нужно понимать, что в большинство случаев при параллельной работе большого количества пользователей вы получите стабильную работу сервера 1С все-таки если не будете отключать данную настройку.
Мы рекомендуем устанавливать значения «-1» только на время выполнения задачи переноса данных 1С, либо другой нужной Вам ресурсоемкой задачи.
При обмене данными клиент-сервер в программе «1С Бухгалтерия» (обычно версий 8.3.хххх) оператор локального ПК может внезапно столкнуться с сообщением «Ошибка при выполнении запроса POST к ресурсу /e1cib/logForm». Данная проблема обычно имеет программную природу, и вызвана некорректно написанным обновлением к данной программе. Ниже я разберу, что это за ошибка, каковы факторы её возникновения, и как её исправить.
Содержание
- Перевод и причины дисфункции
- Как исправить ошибку запроса POST к ресурсу /e1cib/logForm
- Заключение
Перевод и причины дисфункции
После текста сообщения об ошибке при обращении к /e1cib/logForm обычно следует описание причины её возникновения, которая может иметь различный характер (ошибка на сервере, ошибка СУБД и другие).
Проблема возникает на серверной версии программы, причём после установки очередного обновления к «1С». Проблемными стали версии программы 8.3.6, 8.3.8.хх, 8.3.9.ххх, на которых рассматриваемая мной дисфункция возникает наиболее часто.
Данная ошибка возникает случайно, в большинстве случаев не имеет каких-либо закономерностей при своём появлении, чем раздражает довольно многих пользователей, заваливающих техподдержку 1С «письма счастья».
Как я уже упоминал выше, причиной возникновения ошибки запроса POST является некорректно написанный разработчиками код программы. Потому в данном случае не стоит искать причины в некорректном функционале своего ПК, а сосредоточиться на действующих вариантах решения проблемы, которые я опишу ниже.
Также вам может быть интересен наш материал о коде ошибки 0000000002, связанной с дисфункцией подаваемой декларации.
Как исправить ошибку запроса POST к ресурсу /e1cib/logForm
Чтобы избавиться от ошибки рекомендую выполнить следующее:
- Выполните стандартное «Тестирование и Исправлении» (ТиИ) вашей базы данных. Данная операция осуществляется переходом в «Конфигуратор», где во вкладке «Администрирование» необходимо выбрать опцию «Тестирование и Исправление». Операцию необходимо осуществлять в монопольном режиме, потому никого кроме вас в базе быть не должно. Перед выполнением указанной процедуры рекомендуется сделать страховочную копию ваших баз данных;
- Установите наиболее свежие обновления к вашей версии 1С. Поскольку пик появления данной ошибки пришёлся на 2016-2017 годы, то с тех пор разработчиками был выпущен ряд обновлений, позволяющих устранить данную ошибку. Установите свежие апдейты для вашей «1С», и если не помогло, то идём дальше;
- Откатите программу до прежней версии. В некоторых случаях (когда у пользователей было установлены самые свежие обновления) помог откат программы до более ранней (и более стабильной) версии программы;
- При доступе к серверу 1С рекомендуется почистить кэш. Остановите на сервере службу под названием «агент сервера 1с предприятие», в каталоге кэша сервера удалите всё кроме файлов, имеющих расширение *.1 Примерный путь к каталогу может быть:
Program Files1cv8srvinforeg_1541
После чего вновь запустите указанную службу;
- Перезапустите сам сервер 1С Предприятие. У некоторых пользователей это помогло решить проблему запроса POST к ресурсу /e1cib/logForm;
- Обратитесь в официальную поддержку 1С за консультацией и помощью. Также может помочь обращение по сети (к примеру, на е-мейл v8@1c.ru) или по телефону (495) 956-11-81 в техническую поддержку 1С. Поскольку рассматриваемая ошибка имеет массовый характер и наблюдается не первый год, то наверняка у специалистов техподдержки уже имеются работающие алгоритмы решения возникшей проблемы.
Обратитесь в техподдержку 1С
Также на нашем сайте мы разобрали ошибку 0400300003, связанную с нарушением условия обязательного присутствия элемента.
Заключение
Основным фактором возникновения ошибки запроса POST к ресурсу /e1cib/logForm является некорректно написанный разработчиками код обновления к программе «1С». Эффективным решением возникшей проблемы станет обновление вашей версии 1С до самой свежей версии, где рассматриваемая дисфункция уже исправлена, и появлений рассматриваемой ошибки более не наблюдается.
Опубликовано 28 марта 2018 Обновлено 28 января 2021
Содержание:
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С». Кстати, Вы также можете обратиться и к нам по этому или любому другому вопросу. Мы всегда на связи и с радостью поможем решить Вашу проблему.
Специалист компании «Кодерлайн»
Иванова Ольга
Невосстановимая ошибка Ошибка при выполнении запроса POST к ресурсу /e1cib/logForm: по причине: Ошибка СУБД: Файл базы данных поврежден
Описание ошибки:
При попытке запуска работы сеанса с базой 1С 8:
Невосстановимая ошибка
Ошибка при выполнении запроса POST к ресурсу /e1cib/logForm:
по причине:
Ошибка СУБД:
Файл базы данных поврежден ‘D:1C BasesAccounting/1Cv8.1CD’
по причине:
Файл базы данных поврежден ‘D:1C BasesAccounting/1Cv8.1CD’
Найденные решения:
Если нажать ссылку «Показать информацию для технической поддержки», то в открывшемся окне будет полный текст ошибки:
Появляется при попытке запустить базу 1С. Стала возникать после того, как на рабочем месте было аварийное, т.е. непредвиденное завершение работы, выраженное отключением электричества. В момент отключения электричества, и соответственно рабочего компьютера, база была открыта, с ней работали, активный сеанс работы с 1С.
Так или иначе разновидность данной ошибки уже была описана ранее в публикациях. Но проявляля себя уже в процессе работы с базой:
Ошибка «Файл базы данных поврежден ‘СUsersимя_пользователяAppDataLocal1C1cv8……vrs-cachecache.1CD'»
Ошибка СУБД: Файл базы данных поврежден
В данном же случае методика устранения ошибки такая же, как и в приведенных двух выше статьях-описаниях. Сначала (1) выполняем проверку физической целостности по инструкции, предварительно, скопировав файл базы, т.е. создав его непосредственную копию, поскольку возможности штатно создать архив базы через конфигуратор не получится в виду наличия этой же ошибки «Ошибка СУБД: Файл базы данных поврежден». После шага (1) дополнительно выполним шаг (2) — операцию тестирования и исправления базы данных.
Если повреждения окажутся не масштабные, то после этих двух операций база снова готова к работе.
Оцените, помогло ли Вам предоставленное описание решения ошибки?
© www.azhur-c.ru 2014-2020. Все права защищены. Использование текстов и изображений с данной страницы без письменного разрешения владельца запрещено. При использовании материалов с данной страницы обязательно указание ссылки на данную страницу.
07-10-2020
Журавлев А.С.
(Сайт azhur-c.ru)
«Неисправимая ошибка» при свертке базы |
Я |
16.01.20 — 15:40
Платформа 8.3.13.1690, конфа УТАП 11.4.9.83
При свертке базы во время выполнения второго пункта 1С отваливается с ошибкой: «Невосстановимая ошибка Ошибка при выполнении запроса POST к ресурсу /e1cib/logForm по причине:» и всё на этом.а
1 — 16.01.20 — 15:44
База весит 100Гб, оперативной памяти на сервере 64Гб, в настройках кластера снимал ограничение(-1) про максимальный объем памяти, не помогло.
2 — 16.01.20 — 16:21
… может тех. журнал глянуть ?
3 — 16.01.20 — 16:49
(2) смотрел, никаких подробностей
4 — 18.01.20 — 17:52
up. Попробовал обновить сервер и платформу до 8.3.14.1976, не помогло, та же самая ошибка.
5 — 18.01.20 — 20:25
(4) но памяти не хватает.
Может у тебя клиент, с которого свертку запускаешь, она на 32-бит, т.е. ошибка не на сервере, а на клиенте?
6 — 18.01.20 — 21:06
а зачем свертка http запросы делает ?
7 — 19.01.20 — 03:00
(5) Всё x64, свертку запускаю прямо на сервере. Есть подозрение конечно, что тупо памяти не хватает, в процессах рождаются rphost в количестве 7 штук, один основной отъедает 1,4Гб оперативы, другие по 300-500Мб, разрешено памяти на один процесс до 20Гб, после какого-то времени 1С падает с ошибкой и эти процессы сокращаются.
8 — 19.01.20 — 10:00
(7) А есть статистика, что этот рпхост перед падением доходит до предела памяти?
Понятно, что ошибка сформулирована именно в таком сообщении, которое отсылает к проверке памяти, но действительно ли в памяти проблема…
Тут как бы возникает специфический вопрос. На фоне террабайтных дисков для установки во всякие там компы, которые можно купить в розницу за относительно небольшие деньги,
получается, что 100 гб в базе вроде бы и не так много. Однако, процессы с таким размером памяти работать не хотят.
А может быть, с учетом того, что базу надо изнасиловать, обеспечить этому событию абсолютную монопольность на сервере?
Ну и убрать при этом любые ограничения на использование памяти, конечно.
Вообще, Заказчику в подобной ситуации нужно понимать, что одного сервера для нормальной работы в режиме 24/7 при таком размере баз и процессов уже не хватит.
И если КОРП версию 1С покупать по стоимости просто неадекватно, то может быть имеет смысл купить просто еще одну лицензию на сервер 1С
и запускать всякие системные и сервисные вопросы на дополнительном компьютере.
Например, этот дополнительный сервер можно поставить на линукс платформе (это такой ненавязчивый намек)
9 — 20.01.20 — 02:37
(8) Дело в том, что при свертке базы, наблюдая за статистикой я увидел нагрузку на память всего 15%, проц sql сервером отъедался на 35% максимум. Полная монополия была обеспечена для этого дела. Так же игрался с параметрами кластера и сервера 1С, убирая любые ограничения по памяти, устанавливая перезапуск процессов чаще, ничего не помогло. Сегодня попробую выгрузить базу в файл и сделать свертку. По поводу дополнительного сервера это было бы замечательно, но руководство у нас очень сложное на выделение средств.
10 — 20.01.20 — 08:48
(9) ненавязчивых намеков не понимаем? ну тогда ладно.
11 — 20.01.20 — 08:55
(10) да понимаем, другое дело, что это требует достаточно больших временных затрат, а нужно сейчас, а лучше вчера )))
12 — 20.01.20 — 09:05
(11) а пробовал в порядке проверки работоспособности свертки, как обработки, запустить на короткий период? Т.е. на первые два года работы базы, а не весь период, который решили свернуть?
Кстати, как-то очень давно уже не приходилось проверять на практике, что получается со свертками, если их делать по каждому году, а не сразу за большой период — будут они поддерживать корректно наличие последовательности предыдущих сверток.
13 — 20.01.20 — 09:10
(12) Не поверишь, но это один из вариантов, который мне сегодня утром пришел на ум. Так же есть еще одна задумка. У нас в базе по алкоголю хранится очень большое количество сканов сопроводительной документации, которая распечатывается при реализации товара. Не знаю сработает ли это, сработает ли правильно, но, что если попробовать выпилить эти сканы из базы? ну и соответственно подчистить ссылки на все эти изображения? Я сам не программист, но есть возможность озадачить человека написать обработку под это дело.
14 — 20.01.20 — 09:32
(9) А загрузку диска смотрел?
15 — 20.01.20 — 09:42
(14) Диск тоже не сильно напрягался.
16 — 20.01.20 — 09:45
(8) >> одного сервера для нормальной работы в режиме 24/7 при таком размере баз и процессов уже не хватит.
Странное утверждение. У нас работают базы и по 150ГБ и даже больше, и не по одной штуке на одном(!) сервере, и 24/7.
По-моему, размер базы — это отнюдь не единственный параметр, на который следует опираться, делая подобные заявления.
17 — 20.01.20 — 09:47
(0) Автор. А нафига вообще вам свёртка?
Тупой конечно же вопрос, но на всякий случай спрошу. А перед запуском свёртки тестирование и исправление базы и конфигурации делали? Уверены, что в базе действительно нет ошибок?
18 — 20.01.20 — 09:49
(9) >> игрался с параметрами кластера и сервера 1С, … устанавливая перезапуск процессов чаще.
В чём смысл этого действа?
В чём смысл вообще установки перезапуска процессов?
Уверены, что проблема не связана с тем, что рабочий процесс по вашей же настройке перезапускается и теряет связь с реальностью (длительная незавершенная транзакция падает)?
19 — 20.01.20 — 09:52
(7) >> разрешено памяти на один процесс до 20Гб
Для чего установлено это ограничение? В чём смысл?
20 — 20.01.20 — 09:53
(17) Свёрка нужна для уменьшения объема базы в первую очередь, есть в этом нужда, да и в любом случае тот период, который подвергается свёртке полностью закрыт и давно забыт. ТиИ делалось.
(18) Пробовал и с большим временем до перезапуска процесса, проблема не решилась.
(19) оно было установлено изначально, когда я пришел работать. Ограничения снимались для выполнения свёртки.
21 — 20.01.20 — 09:53
Складывается впечатление, что вы понастроили кругом заборов и теперь пытаетесь понять какой именно из них мешает приложению.
22 — 20.01.20 — 09:54
(21) Еще раз повторюсь, что так называемые «заборы» были убраны полностью, когда столкнулись с проблемой указанной в самом начале, но это не спасло ситуацию.
23 — 20.01.20 — 09:55
(20) >> Свёрка нужна для уменьшения объема базы
Более идиотскую потребность придумать сложно. Я бы ещё понял, если бы база была в несколько терабайтов. Но ради 100Гб устроить себе такой геморрой… Успехов.
24 — 20.01.20 — 09:56
(23) +100500
25 — 20.01.20 — 09:57
(0) поделку для свертки где хоть взяли то? И она прям для утапа написана? )
26 — 20.01.20 — 09:58
+ к (23) И не удивляетесь, когда поймёте, что база сократилась только на 15-20%% вместо ожидаемых 50-70%% (или сколько вы там планируете).
Следующие вопросы автора будут — что делать с неудалившимися, но помеченными на удаление объектами, и почему размер базы почти не изменился.
27 — 20.01.20 — 09:59
А так, посмотреть базопузомером, что там место занимает и выкосить лишнее и свертка не нужна будет. Если еще и сжатие в скуле включмть и реструктуризовать таблички в скуле..она еще похудеет в разы
28 — 20.01.20 — 10:18
(23) нет возможности работать с таким объемом данных комфортно, ресурсов маловато серверных и расширить их в ближайшее время не представляется возможным.
29 — 20.01.20 — 10:54
(28) >> нет возможности работать с таким объемом данных комфортно
С таким — это с каким? Какой ожидается объём?
Вы отдаёте себе отчет в том, что никакой разницы по комфорту работы между 100Гб и 50Гб не будет? Не боитесь, что наобещав пользователям манну небесную, устроив им ад на земле со сверкой начальных остатков их выверкой и исправлением всех косяков свёртки, вы будете ими прокляты, когда они поймут, что никакого обещанного комфорта нет? Кроме мифической экономии дискового места для бекапов никакого толку от свёртки нет. И это надо чётко понимать.
И что же поменяется, когда вместо 100Гб база будет весить, например, 80, а через год — снова 100?
>> ресурсов маловато серверных.
Каких именно?
30 — 20.01.20 — 10:55
Есть конторки которые за сотку другую свернут остатки скульным скриптом.
31 — 20.01.20 — 10:56
(28)
Ё.. вам нужен базопузомер, а не свёртка. Тем более, в утапе.
Там поди ни разу никто всякие регсведения типа запросыегаис/запрросы и ответы егаис и т.д не чистил никогда
32 — 20.01.20 — 11:05
(31) поделитесь ссылкой?
И да, никто никогда ничего не чистил.
(29) когда база весила 50Гб, работала она заметно быстрее. Да можно говорить за усталость оборудования, но нет, все проверки по железу проходят на ура, реиндексация и ребилд индексов делается регулярно по расписанию.
33 — 20.01.20 — 11:12
(32) та любую с нимфостарта, хоть такую
http://catalog.mista.ru/public/251332/
34 — 20.01.20 — 11:12
(32) кеши чистите? И еще настройки вариатов отчетов. Со временем могут занимать гигабайты. И реиндексацией вы их нифига не удалите
35 — 20.01.20 — 11:13
(34) Да, кеши чистим тоже регулярно. А про настройки вариантов отчетом можно подробнее, куда копать?
36 — 20.01.20 — 11:19
(32) SQL И 1С на одном сервере? (в (9) есть намек на это). А то про ограничение 1С на память прочитал, а SQL вообще может под себя всю память забрать.
37 — 20.01.20 — 11:22
(36) Да, всё крутится на одном сервере, в настройках SQL стоит ограничение до 25Гб потребляемой памяти, т.к. уже сталкивался с тем, что он кушает как не в себя )
38 — 21.01.20 — 03:52
Взяли период свертки один первый год, чуть дольше попытался поработать, но в итоге все равно отвалился с той же ошибкой.
39 — 21.01.20 — 04:39
(34) и форм бывает тоже
40 — 21.01.20 — 05:07
Короче самая жирнота это регистр сведений «Двоичные данные файлов » со сканами сопроводительных документов… только они весят почти 65Гб…
41 — 21.01.20 — 06:22
(40) вынеси во внешнее хранение и сожми РС
42 — 21.01.20 — 06:37
(41) Не будет ли от этого медленнее проходить работа с этими файлами? Опять же, как это скажется на надежности?
43 — 21.01.20 — 06:42
(42) копать молотить!!! Если адекватно разместишь — будет быстрее!
44 — 21.01.20 — 06:53
(43) Спасибо!
45 — 21.01.20 — 08:53
(32) >> когда база весила 50Гб, работала она заметно быстрее.
Во-первых, уменьшения в два раза вы не получите.
Во-вторых, я уверен на 99%, что это утверждение явно ничем не подкреплено, кроме субъективных утверждений. Потому что чудес не бывает. Ибо скорость работы клиент-серверной базы мало зависит от её объёма (во всяком случае, когда речь идёт о 100Гб).
В-третьих, даже если реально имеет место снижение скорости (что, по-моему, не факт), то причина, скорее всего, не в объёме, а либо в самой конфигурации, либо в данных (какие-то регистры не закрываются). Не исключено, что и в железе или кривой настройке SQL.
46 — 21.01.20 — 14:50
(45) спасибо за Ваши ответы, непременно буду изучать все моменты. Я далеко не программист, а средней руки сисадмин, прогера наняли только пару дней назад, так, что пока только «въезжает в тему».
47 — 21.01.20 — 14:53
(43) можно еще вопрос? после переноса файлов на том, они всё еще остаются в базе, как их вычистить? не разу не пользовался функционалом хранения файлов на томе, подумал, что после переноса файлов во внешнее хранилище они из базы потрутся сами.
48 — 21.01.20 — 15:39
(47) 1.В РС добавляешь Реквизит в котором указываешь полный путь к файлу, устанавливаешь значение этого реквизита попутно сохраняя файлы на диск, удаляешь реквизит типа ХранилищеЗначений.
Фрэнки
49 — 21.01.20 — 15:42
(48) но база автоматом не сожмется, наверное? шринки там какие-то… процедуры в админке СУБД надо бы…