Голь на выдумки хитра. В хорошем смысле, конечно.

LionEyE
Используем VFP9.
...
тормоза.
...
Когда были на VFP 6 такого не было. Смигрировали на 9 и началось.

Может все-таки и какие-то настройки после миграции поменяли?.. Если теперь запустить под VFP6 - скорость нормальная?
Может можно сделать отдельный небольшой пример, который работает с разной скоростью под VFP6 и VFP9.

Посмотрел файлы:
________________________________________________________У нас:
14.12.2004 06:17 114 688 foxisapi.dll ________________не используется
14.04.2008 20:38 1 724 416 GdiPlus.dll ________________не используется
21.02.2003 22:42 348 160 msvcr71.dll _________________время другое - 08:42
15.10.2007 09:45 4 734 976 vfp9r.dll _________________объем другой - 4 624 К
15.10.2007 09:15 1 187 840 VFP9RENU.DLL ______________ не используется
15.10.2007 09:47 1 212 416 vfp9rrus.dll _______________ объем другой - 1 184 К
15.10.2007 09:45 3 907 584 vfp9t.dll _________________ объем другой - 3 816 К

Что скажете господа? Может ли это являться причиной?



Исправлено 1 раз(а). Последнее : LionEyE, 09.11.09 12:06

Господа. Вопрос так и не решился.
Провел несколько экспериментов:
1. Операционка ХР: dbf лежат локально. Запускаю первый экземпляр проги - файлы открылись. Запускаю второй, третий, четвертый. На пятом или шестом экземпляре при открытии файла dbf выдает ошибку что файл заблокирован или открыт в монопольном режиме. Выгружаю предыдущие 5 экземпляров - этот загружается, т.е. файл освобождается. Причем новый не загрузить пока все не выгрузишь, т.е. одного не хватает.

2. У клиента операционка ХР, a файлы на сервере с Win 2003 Srv R2. Вообщем история та же. На 5-м экземпляре +-1 вылетает ошибка (происходит блокировка).

3. У клиента1 операционка ХР, у клиента2 операционка Win 2008 Srv, a файлы на сервере с Win 2003 Srv R2. У клиента2 блокировка происходит уже на втором экземпляре. При этом если попробовать подключиться с клиента1, то коннект происходит, но тоже не более 4-5.

Ошибка 1705 File Access is denied

Антивирус Nod - на время тестов отключен.

Кто что знает по этому поводу!?
Уже и не знаю что думать...



Исправлено 1 раз(а). Последнее : LionEyE, 23.11.09 23:37

Загрузку проца, сети смотрел, в режиме "все плохо", каковы они? Скорее не из этой темы, ...
А если фильм положить в папку с прогой, и открыть ее на просмотр с этого кол-ва компов..., если есть на это возможность, ну, для проверки...



Исправлено 2 раз(а). Последнее : of63, 23.11.09 23:51

LionEyE
Господа. Вопрос так и не решился.
Провел несколько экспериментов:
1. Операционка ХР: dbf лежат локально. Запускаю первый экземпляр проги - файлы открылись. Запускаю второй, третий, четвертый. На пятом или шестом экземпляре при открытии файла dbf выдает ошибку что файл заблокирован или открыт в монопольном режиме.
Кто что знает по этому поводу!?
Уже и не знаю что думать...

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



Исправлено 1 раз(а). Последнее : ЮК, 24.11.09 07:06

LionEyE
Господа. Вопрос так и не решился.

Это грустно. Прежде всего советую посмотреть настройки в свойствах сетевой папки, как заметил ЮК. Далее, отвлекаясь вообще от VFP (добивать так добивать) - положите в эту папку какой-нибудь посторонний файл, например DOC, и попытайтесь его открывать на редактирование одновременно с нескольких рабочих мест. Если картина будет схожей с DBF, можно оставить фокс в покое и заняться настройками ОС/сети.

У меня пару лет назад внезапно возникла такая же ситуация - появлялась блокировка таблиц при работе более 5 пользователей, хотя файлы лежали на мощном сервере с Win2003. Причина оказалась весьма банальной - в стартовом модуле каким-то образом исчезла строка:
OPEN DATABASE XXXX SHARED

Sea_Cat
У меня пару лет назад внезапно возникла такая же ситуация - появлялась блокировка таблиц при работе более 5 пользователей, хотя файлы лежали на мощном сервере с Win2003. Причина оказалась весьма банальной - в стартовом модуле каким-то образом исчезла строка:
OPEN DATABASE XXXX SHARED

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

> А не указано ли у Вас ограниченное число пользователей для данной папки (или файла) при назначении общего доступа ?

Нет, это проверял, все в порядке - стоит максимально возможное.

> положите в эту папку какой-нибудь посторонний файл, например DOC

Сейчас проверяю эту идею.

> У меня пару лет назад внезапно возникла такая же ситуация - появлялась блокировка таблиц при работе более 5
> пользователей, хотя файлы лежали на мощном сервере с Win2003. Причина оказалась весьма банальной - в стартовом
> модуле каким-то образом исчезла строка:
> OPEN DATABASE XXXX SHARED

Я открываю таблицы USE путь ALIAS имя . Параметр SHARED не использую. Или надо явно прописать? Проверю конечно, но!? Сейчас в зависимости от настройки SET EXCLUSIVE файлы по разному открываются.

2 reware
В том то и дело, что первой строкой в программе стояло SET EXCLUSIVE OFF и контейнер не должен был открываться эксклюзивно. Может сисадминов нужно было допросить с пристрастием ?

LionEyE
Я открываю таблицы USE путь ALIAS имя . Параметр SHARED не использую. Или надо явно прописать? Проверю конечно, но!? Сейчас в зависимости от настройки SET EXCLUSIVE файлы по разному открываются.

А чего вы так не любите SHARED ? Или у вас в приложении где-то установлено SET EXCLUSIVE OFF ? Если явного указания SET EXCLUSIVE нет в приложении, то лучше его добавить в головной модуль или открывать таблицы по USE MyTable ALIAS MyAlias SHARED. Будет спокойнее.

Sea_Cat
В том то и дело, что первой строкой в программе стояло SET EXCLUSIVE OFF и контейнер не должен был открываться эксклюзивно.

Тогда нечего винить безобидное OPEN DATABASE XXXX SHARED.

Проверка у себя:
Я сейчас на всякий случай провел эксперимент - 10 станций зашли в систему одновременно без проблем.
ответ нашего системного администратора:
DBF находятся на кластере, состоящем из двух машин и общей системы хранения данных.
На обеих машинах установлены одинаковые операционные системы: MS Windows 2003 R2 SP2.
Никаких специальных настроек не производилось.

У клиента, там где сейчас проблема:
Винда 2003 standart edition SP2
никакого софта, кроме антивируса ESET32 - но его отключали, чтобы файлы не трогал.

Так же у нас есть та же самая прога, только под FPD DOS. Так вот досовая прога легко запустилась в 10 экземплярах у проблемного клиента (на одной машине).

Кстати, когда на компе с ХР (DBF локально) пробовал из одной папки запустить максимальное количество экзепляров. Начинало блокироваться на 5+-1 экземпляр точно так же, как у клиента.

Проверили с файлом: запустили 10 копий mp3 с сервера на своей машине. 10 штук воспроизводятся одновременно.



Исправлено 1 раз(а). Последнее : LionEyE, 24.11.09 16:46

А логах Windows ("Администрирование"-"Системные события")в момент отказа открытия файла ничего не пишется ?

SET TABLEVALIDATE ещё проверьте, хотя он не должен ТАК себя проявлять - вот если юзеры активно вносят данные, тогда да, могут быть периодические "отказы" при попытке "в N-й раз открыть таблицу" - но уж точно не "строго 6-й"
P.S. Когда указываешь версию рантайма, нужно не размер смотреть (там более "округлённый" до килобайтов!) и не дату модификации, а именно номер версии - он есть в свойствах файла.

Сейчас SET TABLEVALIDATE выставляется в 0 принудительно всегда.

Насчет версии рантайма посмотрю - отпишусь.

LionEyE
Кстати, когда на компе с ХР (DBF локально) пробовал из одной папки запустить максимальное количество экзепляров. Начинало блокироваться на 5+-1 экземпляр точно так же, как у клиента.

У себя на XP+SP3 запускаю 10 раз крохотный ЕХЕ (VFP9+SP2). В нем только форма с кнопкой, в Click кнопки -
USE c:\MyTable SHARED. Все 10 копий нормально запускаются и открывают общую таблицу.

Для сверки - у меня такие версии DLL :

foxisapi.dll 9.0.0.2412
GdiPlus.dll 5.1.3102.5512
msvcr71.dll 7.10.3052.4
vfp9r.dll 9.0.0.5815
VFP9RENU.DLL 9.0.0.5815
vfp9rrus.dll 9.0.0.5815
vfp9t.dll 9.0.0.5815

Еще раз перечитал начало темы :

Цитата:

Запускается первый пользователь, открываются все dbf файлы. Загрузка у него происходит моментально.
Запускается второй - у него это происходит медленнее на порядок.
У обоих стоит одна и таже прога. Если меняются очередностью, у второго быстро запускается, а у первого медленно.
Смигрировали на 9 и началось. Код не менялся.
В момент запуска происходит просто поочередное открытие файлов dbf в цикле
USE (path) ALIAS name

При этой самой миграции на VFP9 не могло произойти изменения кода ? Вы прямо из FPD перетащили код 1:1 в VFP9 ? Довольно странно, что по вашим словам в "той-же задаче на FPD" все ОК. Проверьте все-же этот загадочный цикл, в котором происходит "поочередное открытие файлов dbf в цикле".