Расположение Temp-файлов 1С

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

Это проблема кеша.
Удалите базу из списка и заново ее добавьте.

BabySG (09 февраля 2012 - 11:09) писал:

Ну это временное решение. База постоянно правится, значит глюк буду иметь постоянно... Да и пользователей штук 30. Хотелось бы, чтобы проблема не повторялась. Хочу батником при запуске сеанса убивать необходимые файлы... Кто-нибудь знает расположение этих файлов?

Еще раз: это проблема постоянна и не устранима без удаление кеша.
Едиственный способ обхода - не использовать динамическое обновление.

Расположение файлов описано на ИТС http://its.1c.ru/db/...#content:1591:1

С этой проблемой воют постоянно. На 8.2.14 и 8.2.15 ситуация стала лучше, поэтому уточните версию.
Батником сносить постоянно файлы - не вариант. Т.к. запуск базы будет замедляться.

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

Цитата

BabySG (09 февраля 2012 - 11:16) писал:

Конфигурация на этапе доработки и соответственно без динамического обновления никак.

BabySG (09 февраля 2012 - 11:16) писал:

У меня нет прописки на сайте ИТС. Будте добры, выложите здесь расположение файлов :)

BabySG (09 февраля 2012 - 11:16) писал:

Версия 8.2.13.219 - буду обновлять

Сураев Игорь (09 февраля 2012 - 11:31) писал:

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

Сураев Игорь (09 февраля 2012 - 11:31) писал:

?
не верю. Меняйте подход к работе.
Еще раз: сделайте копию базы и работайте на ней. Переносите доработки в боевую базу только тогда когда отладите.

Ну да ладно. Дело ваше. Мое дело посоветовать, как поступать решайте сами.

Господа! Условия работы не позволяют по другому. Два программиста , параллельно непрерывно дорабатываем УТ, один сидит в основной базе, я в копии. Задачи от руководителя сваливаются непрерывно (права подправить, косяки свои всякие, отчеты, печатные формы и кучу всего, чем занимается второй программист). Обновлять приходиться каждые два часа, потому что шеф хочет видеть результат . Выгонять всех из базы по этому поводу - это полчаса уговаривать все отделы. Откладывать до ночи - это тормоз в работе. Так что только динамическое обновление
Предлагаемый вариант каждый раз перед обновлением переподключать базу... ну проще разобраться с файлами. Причем как я понял это необходимо делать только для программистов, а с остальными разбираться только при возникновении проблем...

Специально для Вас сделана такая вещь, как хранилище.
Изучите его возможности.

Поэтому проще не "в лоб", а изучить матчасть.

Хранилище конфигурации решит вопрос с паралельной разработкой. Но не решит вопрос с динамическим обновлением.
Иногда действительно оно нужно. Не возможно все отладить в хвост и в гриву. Иногда внедришь модуль, а он через год сбойнет. Ибо возникнет неучтенная вещь, возникающая 1 на 15 000 000 случаев.
Но по возможности надо избегать.
По своей практике могу сказать, что если за неделю приходится прибегать к динамическом обновлению чаще чем один раз => что то не так в работе.

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

Решил поделиться своим опытом.

Крест на динамическом обновлении поставил несколько лет назад, работая на версии 8.1.лохматая. Тогда у меня была проблема в том, что у пользователей, которые на момент динамообновления работали в базе (УТ), отваливались все их настройки (сортировки списков, настройки полей и т.д.)

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

1. Модифицирую и тестирую конфигурацию в копии базы.
2. В консоли администрирования сервера 1С убеждаюсь, что на текущий момент нет "длинных" активных транзакций от пользователей (перепроведение документов, ресурсоемкие отчеты и т.д.)
3. Переношу изменения в живую базу без сохранения конфигурации.
4. Отправляю сообщение активным пользователям о том, что через N минут выходим из базы на минутку.
5. По истечении N минут в консоли администрирования сервера 1С удаляю все соединения (кроме собственного )
6. Записываю изменения.

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

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

Успехов