Файл не обнаружен no such file or directory 1с
Регулярно при сохранении конфигурации появляется ошибка вида "Файл не обнаружен 'C:UsersuserLOCALS~1Temp1v8_E0E3_e.tmp' 2(0x00000002): Не удаётся найти указанный файл". Файла действительно не обнаруживается, другие аналогичные временные файлы в каталоге лежат. Пробовал на разных терминальных серверах под разными пользователями. Ошибка всё равно возникает. Что это может быть и как с этим бороться?
Вполне современные терминальные сервера. Никакого ФАТа. Win 2012. Нашёл Win 2003 и тоже попробовал. Не помогло.
Антивируса, упаси боже, на терминальных серверах нет. Есть виртуализация. Сервера виртуальные на Proxmox
Если ничего не путаю, совместимость со старыми программами и генерация коротких имён типа "LOCALS~1" по умолчанию включена. Даже на самых современных виндах.
попробуй сохранить конфигурацию поставщика отдельно. Или сделать сверку конфигурации поставщика с основной конфигурацией. Если будут ошибки, значит у тебя разрушилась конфигурация поставщика. Было у меня такое.
Права выглядят нормально. И пробовал на двух разных серверах. Проблема сохраняется - где-то один раз из десяти при сохранении конфигурации вылетает. Пробовал. Не помогает. Сравнение с конфигурацией поставщика делал. Проходит без ошибок. Проблем не видно. Мои изменения в сравнении видны корректно. Может связано с хранилищем конфигурации? Но без него как-то не хочется работать.
Автор так и не описал, когда же у него возникает ошибка. "При сохраненни конфигурации" - Я как минимум три варианта тут вижу
Поясни. Туплю, наверное, но не понимаю, о чем речь. Пробовать мучать конфигуратор на другой базе? Так дорабатывать нужно эту. Даже если на другой базе проблемы нет, мне это не поможет.
Мне кажется, что попробовав на разных серверах разных версий, я исключил проблемы windows и профайла пользователя. Завтра попробую исключить влияние доменной политики и терминала, запустив на недоменном компьютере. Остаётся проблема в базе (ТИИ к утру что-то скажет) и проблема релиза (релиз поменять проблемно, много удалённых пользователей).
было у меня такое на локальном компьютере. После chkdsk, chkdfl, ТИИ и убрать/добавить базу в список базы, этот глюк исчез.
Сохрани основную конфигурацию, загрузи в чистую базу, внеси изменения, обнови конфигурацию БД. Затем то же самое, только вместо первого пункта сохрани конфигурацию БД.
Описание ошибки:
Обнаружена при разработке обработки для изменения содержимого файла формата XML в серверной базе 1С 8 в режиме управляемого приложения. При тестировании на сервере ошибка не возникала. Проявила себя при работе на рабочем месте пользователя.
По факту ошибка возникала при выполнении метода "Прочитать()" для объекта "ТекстовыйДокумент". Как было отмечено, при тестировании работы обработки непосредственно на сервере данной ошибки не возникало. Она проявила себя уже при попытке работы на другом рабочем месте. Обработка разрабатывалась для конфигурации 1С: Комплексная автоматизация 8, ред. 2, которая работает в режиме управляемого приложения - это необходимо отметить. Т.к. это проясняет причины возникновения проблемы.
По привычке разместил операции по чтению содержимого текстового файла и извлечению его содержимого на стороне сервера - см. "&НаСервере" перед процедурой "ОбрабткаНаСервере()". Клиент-серверная архитектура платформы 1С: Предприятие 8.3, казалось бы, к этому обязывала.
В итоге получалось, что платформа на клиентском рабочем месте искала файл по указанному пути на сервере, где развернут сервер 1С: Предприятия 8 исходя из директивы "&НаСервере", а не на рабочем компьютере, где была запущена обработка.
Но, как оказалось позже - конструктор "Новый ТекстовыйДокумент", методы "Прочитать()", "ПолучитьТекст()" - все они доступны не только на стороне сервера, но и на стороне тонкого и толстого клиента. Поэтому замена директивы "&НаСервере" на "&НаКлиенте" решила проблему.
Пытаюсь на 8.3 в управляемых формах на клиенте прочитать файл:
ВыбФайл = "C:\ВО_200114.txt";
Текст=Новый ТекстовыйДокумент();
Текст.Прочитать(ВыбФайл);
Выдает ошибку:
: Ошибка при вызове метода контекста (Прочитать)
Текст.Прочитать(ВыбФайл);
по причине:
Файл не обнаружен 'C:\ВО_200114.txt'
Но файл там 100% есть! Помогите
(2) , взял отладчик, и в том месте где идет Прочитать(ВыбФайл), скопировал значение ВыбФайл в буфер обмена, потом вставил в командную строку и нажал энтер => файл открылся.
(3), реально! положил сюда \\nbnb\хлам\ВО_200114.txt => прочитал. А почему с моего диска С не хочет читать?
(12) , тоже пишет что не найден.
(8),(10), так получается он ищет диск С не моего компьютера, а на сервере, где база sql крутится? хотя я запускаю 1с через толстого клиента со своего компа..
(13) Если команда выполняется на сервере, то вполне логично, что и файл ищется на сервере. И скорее не на сервере SQL, а на сервере 1С.
(15) , вы реально здесь телепаты.
обработка получения имени пути у меня на клиенте выполняется, а вот прочитать я его пытаюсь из модуля обработки, код которого выполняется на сервере.
Спасибо большое, никак не привыкну к управляемым формам.
(19) твоим следующим вопросом, по-идее, должно быть такое - почему со своего компьютера файл читается, а с компьютера Афанасия Мухтаровича - нет. Я подожду :)
(25) конечно не причем. Т.к. ты не задал этот вопрос, т.к. у тебя все хорошо и с этой ситуацией ты пока не столкнулся :) Я повторюсь - я подожду :)
(26) , Интригант? о_О
вот, смотрите в (8), там "\\nbnb\хлам\ВО_200114.txt" - это и есть компьютер Григория. И все отлично считалось.
(26), то есть вы хотите сказать, что те папки, которые видны с сервера будут считываться, а те что не видны - нет. Это я понимаю. Решение вижу только два: открывать им доступ с сервера или выполнять метод Прочитать "&наклиенте".
В вэб-клиенте вопрос: Передать файл на сервер \\nbnb\хлам\ВО_200114.txt ? Ура я нашел модальное окно, в режиме использования модальности - не использовать. 8.3.4.389
В один прекрасный вечер произошла неприятная ситуация, сервер физически перестал запускаться. Сисадмин после осмотра объявил о неисправности обоих дисков из зеркального рейда. Просто как выиграть в лотерею))). Бекап базы был не очень далекий, но все-таки хотелось восстановить базу 1С полностью, чтобы не потерять даже одного дня работы. Диск отвезли в специализированную контору, и за ночь они выудили что смогли с этих дисков.
Естественно, не обошлось без потерь. На сервере стоял сервер PostgreSQL и, следовательно, меня интересовала папка из его рабочего каталога data. На новом компьютере установил postgresql с нуля. той же версии, что и стоял на упавшем сервере, с теми же настройками. Остановил службу чистоустановленного postresql , заменяю папку data в рабочем каталоге postreSQL (обычно это находится примерно там - C:\Program Files (x86)\PostgreSQL\9.0.3-3.1C\), восстановленной специалистами с битого диска. Запускаем службу PostgreSQL. У меня она не сразу запустилась. После некоторых экспериментов выяснил, что при копировании папки слетели права на нее и служба не могла ее прочитать и не стартовала из-за этого. Настроил права на каталог data - все взлетело))) Чудо, даже 1С запустился конфигуратор)))
А вот дальше ждал неприятный сюрприз. При попытке выгрузить базу в dt вылетала ошибка СУБД ERROR: could not open file ''base/33264/49743'': No such file or directory. Тестирование и исправление вылетало с той же ошибкой. Видимо специалисты не все файлы таблиц postgresql восстановили.
Я решил проблему следующим образом. Сохранил структуру конфигурации в cf файл. При тестировании и исправлении по строке состояния заметил, на каком объекте падает тестирование. У меня это оказался регистр накопления. Я его удалил, обновил базу данных. а потом заменил конфигурацию базы данных на сохраненную ранее в cf. При таких действиях таблица создастся заново, но данные из нее будут потеряны.
Мне повезло, что пострадала только одна таблица, и это оказался регистр накопления. Его легко можно заполнить заново, перепроведя документы. Если бы пострадал какой нибудь справочник или документ, было бы, конечно, хуже, данные оттуда уже нельзя было бы восстановить так просто. Могла также пострадать какая-нибудь системная таблица 1С и тогда конфигурация вообще не открылась бы. Мой путь решения не идеален, но в моем случае помог восстановить базу полностью. Может, кому поможет мой опыт))
Немного дополню ваш вопрос, а потом расскажу решение речь идет про Linux сервер и бд Postgre о этом говорит порт: 5432 и это и есть корень вашей проблемы.
И ошибка ваша выглядит так:
Connection refused
Is the server running on host "127.0.0.1" and accepting
TCP/IP connections on port 5432?
РЕШЕНИЕ:
1. нужно проверить на сервере есть ли в открытых портах 5432 и сам postgresql
Должно быть примерно так, если у вас пусто или вот так:
tcp 0 0 127.0.0.1:5432 0.0.0.0:* LISTEN 1439/postgres
Pезультат выполнения команды означает, что PostgreSQL принимает подключения по адресу 127.0.0.1 и порту 5432. Чтобы изменить настройки, понадобится отредактировать файл postgresql.conf
Найти местонахождение файла можно командой:
$ find / -name postgresql.conf 2> /dev/null
/etc/postgresql/10/main/postgresql.conf
Надо указать PostgreSQL, что необходимо принимать подключения по всем адресам:
listen_addresses = '*'
и перезагрузить СУБД:
service postgresql restart
Также можно прямо с сервера проверить подключение постгресскуэль
psql -U my_login -h 192.168.0.14 postgres
Если сервер доступен, то будет получен доступ к базе данных postgres:
psql
Type "help" for help.
ОЧЕНЬ ВАЖНО
Залезьте в лог постгре cat /var/log/postgresql/postgresql-10-main.log
И если у вас там: ВАЖНО: нет доступа к файлу "online_analyze": Нет такого файла или каталога
и до этого у вас все работало на вашей убунте и postgres и тут после рестарта все сломалось, предположу что вы обновили убунту.
libpq5/bionic-security,bionic-updates 10.6-0ubuntu0.18.04.1 amd64 [может быть обновлён с: 10.5-10.1C]
postgresql-10/bionic-security,bionic-updates 10.6-0ubuntu0.18.04.1 amd64 [может быть обновлён с: 10.5-10.1C]
postgresql-client-10/bionic-security,bionic-updates 10.6-0ubuntu0.18.04.1 amd64 [может быть обновлён с: 10.5-10.1C]
И вероятно починив порт 5432 и создав online_analyze
у вас будет ошибка: error could not access file $libdir/mchar no such file or directory
РЕШЕНИЕ:
1. Качайте дистрибутив с сайта 1С и переустанавливайте его.
2. И блокируйте обновления постгрес:
sudo apt-mark hold libpq5:amd64 postgresql-10 postgresql-client-10
Читайте также: