День добрый, коллеги.

По сути сабжа:
1. Есть сервер Windows 2003 Enterprise, на котором установлена VMware Workstation 7.1.3.
2. База 1С (DBX) лежит на этом же сервере, на диске D:\Bases.
3. Виртуальная машина Windows XP Pro SP3
4. На ней стоит 1С Предприятие 7.7 (сетевая версия) (7.70.027)
5. виртуальная машина ходит в базу по сетевому диску (Z: = \\Server\Bases)
6. На виртуальной машине работает обработка (ОбработкаОжидания()), которая раз в 1 сек. выполняет процедурку...

Проблема:
Ориентировочно 1 раз за 48 часов получаю набор "матов" от 1С:

1.
CODEBASE ERROR
Error #: -50
Locking File
z:\ИмяБазы\sc495.DBF

2. идет сразу же за ним
Microsoft Visual C++ Runtime Library
Runtime error
c:\Program files\1Cv77\bin\1cv7.exe
The application has requested the Runtime to terminate it in unusual way.
Pleas contact the application's support team for more informations.


как я понимаю, эот о "Вари" пропадает сетевой коннект... но нет.. специально проверял:
1. Пинги не прирываются в этот момент
2. рядом была запушена еще одна копия такого же процесса из копии этой же базы и с тогоже диска z... она не "отпала"...

В чем загадка - понять не могу...
Может кто сталкиватся... Буду примного признателен.

(задумчиво)
Не использовать варю?

использовать virtualBox ?

(1) слишком просто и дорого =)

Для начала я бы на обычной Xp на "сетевом" пути (то есть её же диске, зацепленном через сеть) запустил бы 1С и посмотрел, как она ведёт себя все 48 часов - есть подозрение, что 1С не рассчитана на круглосуточную работу.
Кроме того, интересно узнать размер файлов базы, а также их количество (бывает, что сетевой буфер не позволяет открыть ещё один файл, хотя их количество меньше 65536 намного)

(0) Не в п.6 ли собака порылась ? Код процедуры в студию, и к какому справочнику относиться sc495.dbf в DDшнике посмотри

по порядку:
(4)
1. Тестировал я на простой машине, а не под Варей... живет аж бегом... тоже самое могу сказать и про физический ПК, на котором расположена база... Больше недели нормальной работы было... и остановка не была связана со сбоями...
2. Размер базы: 3,39 Gb
Файлов в ней 546, папок 12.

(5)
3. Файл sc495.dbf весит 5 kb и по ДД в нем
#==TABLE no 22     : Справочник Пользователи
# Name    |Descr                         |Type[A/S/U]|DBTableName|ReUsable  
T=SC495   |Справочник Пользователи       |A          |SC495      |1    

от себя заметил, что есть пару огромныз файлов, весом более 1,2 GB, а именно:
DT863.DBF  = 1,44 Gb
DT742.DBF  = 1,46 Gb
но им простительно... там так и должно быть...

(5)
Насчет кода - да тут нечего собственно описывать...

ОбработкаОжидания(ПазваниеПроцедуры(),2)

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

(6) Ну как знаешь

Быыла у меня другая загадочная история с ВАРЕЙ.

Есть сервер Windows 2003 Enterprise
На нем поднято AD и TS.
В терминале пользователи пользуются 1С с баз, которые у них там же и хнарятся.

Возникла необходимость на нем же установить VMWare WorkStation с Windows XP Pro SP3 для того, что б на ней запустить одновременно еще 2-5 екземпляров одной и той же базы.

Все бы хорошо.
1. Виртуальныю машину подняли.
2. По сети с виртульной машины на реальную не пускает, т.е. пускает, но дальше 2-го уровня вложенности попасть нельзя. Проблема оказалась в сомой виртуализации. Сеть там хитро работает на доступ к локальным файлам.
3. Сделали Shared Folder в VMWare. Подключили базу. Все хорошо, пока запущен один екземпляр базы. При запуске второго сейнса в ответ "Ошибка при загрузке журнала регистрации". И все. Пока не остановишь полностью виртуальную машину и не запустиш заново НИКТО, даже терминальные пользователи сервер, попасть в базу не могут. Она просто "мелькает" и пропадает... Скопировать каталог базы тоже не дает. Мол занят файл.

искал решения по всякому:
1. Пробывал изменить атрибуты папки, но вот значек "только чтение" с него не убирается по оприделению.
2. Менял владельца папки базы. безрезультатно.
3. раздавал права на папку все и вся. В том числе и групе "_vmware_users_", но тоже без результатно.

очень надо решить поставленую задачу, но соображений, в какую же сторону копать дальше просто не осталось.

РЕШИЛОСЬ вот так:

Суть такова:
1. VMWare в режиме "Bridging Network" не умее кореектно работать с "разшареными" ресурсами своего "реального" компьютера. Хотя именно эта настройка самая оптимальная, с точки зрания сети, так как все все видят и ходят в интернет.

2. Надо настраивать VMWare в режиме "Host only". Тогда подсеть у виртуальной машины будет другая. Но все данные с "реального" компьютера будут доступны "виртуальному" и наоборот. при этом нет никаких "глюков" в доступе и все права, заданые на папку на "реальном" ПК будут работать. Недостаток - отсутствие возможности без настройки NAT в VMWare Network Adapter Settings получить доступ на другие компьютеры в сети и с них на виртуальную машину.

3. По умолчанию решение №2 не дает виртуальной машине доступа в Интернет. надо настраивать параметры DHCP в VMWare Network Adapter Settings. Там по умолчанию нет ни шлюза, ни DNSа.


ЗЫ "описывал проблему умам "Инфострата", но обсуждение все дружно проигнорировали... сам нашел решение... там вообще что то тихо последнее время..."

изначальный сабж так и не решон...

ап!

подозрительно то, что проблема на справочнике юзверей... в какое время происходит? кто что делает со справочником юзверей - что в него производиться попытка писать...? проверить - не висит ли во время падения где-нибудь в другом сенансе/компе ОКНО АВТОРИЗАЦИИ - в это время файл вроде как будет полностью залочен...???

расказываю по порядку...
1. боты все до единого смотрят исключительно в журнал "задача". если есть задача, в которой исполнителем назначен этот самый пользователь - выполняют ее...
2. но есть один бот, который проверяет работу остальных... при этом он смотрит в справочник "пользователи" для того, что бы определить, кто "есть на рабочем месте, а кого нет". при этом он же, в зависимости от характера задачи, назначает исполнителя. (может тут и грабли конечно)
3. но есть еще одно "чудное создание", которое получает задачи из другой базы (SQL запросами). у него промежуток времени "от захода до захода" 30 сек. у остальных - 2 сек.

так вот 3-й то как раз и виснет первым.

лично я списываю это все на "отпадение" сетевого диска:
мотиваторы просты:
1. Иногда, даже во время, когда все работает нормально, я не могу запустить на этой же виртуальной машине еще один экземпляр базы, так как пишет "не найден путь к базе"...
после прохода же "Мой компьютер" - "Z:\" база запускается...
а иногда и реально не пускает на Z:\.

но, что самое смешное, так єто то, что навая л я прожку, которая:
1. Заходит на Z:\
2. создает там файлик 123.txt
3. Закрыается
- если не дошла - пишет когда и какая там была ошибка.

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

загадочка в общем то...

кто то на ВАРЕ тестил "беспрерывное катание"?

АП!

АП!