Несколько пользователей получают доступ к базе данных VFP App / dbase по сети — медленные проблемы

Может быть много вещей, и это может быть совершенно нормально. У вас есть исходный код приложения?

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

Сообщение «Попытка блокировки» просто означает, что несколько человек пытаются получить доступ к одной и той же записи (или файлу при грубой блокировке).

Увеличилось ли в последнее время количество пользователей?
Была ли система рассчитана на такой объем? Влияет ли это на одну конкретную функцию программного обеспечения (скорее всего, должно быть) или это затрагивает всю систему в нескольких функциях?

Технические ограничения для VFP (я думаю, 2 ГБ на одну таблицу), и практически это становится медленным, когда есть миллионы записей (огромное обобщение). Хорошая индексация поможет, когда таблицы станут большими

Является ли это прерывистым сигналом в системе (например, в обеденное и вечернее время) или это непрерывная или более частая нагрузка на систему?

Если у вас есть исходный код, вы можете многое сделать, если нет, вам нужно выяснить, какие DBF заблокированы (это будут те, в которых много записей и, возможно, файлы большого размера, когда вы смотрите на каталог)

У вас есть сам VFP или это скомпилированный EXE?

У вас есть много вариантов и вещей, которые вы можете сделать, но нужно больше информации.

Ник

Что касается медлительности приложения, я знаю одну вещь, которая может быть проблемой, особенно если у вас есть 50 пользователей, работающих с приложением VFP. Запускается ли приложение с СЕРВЕРА... Я имею в виду, у каждого пользователя есть ярлык, указывающий на что-то вроде

S:\SomeShare\YourVFPApp.exe

Если это так, то это может ЗНАЧИТЕЛЬНО снизить производительность. Это тянет приложение вниз по сети для каждого пользователя, высасывающего трафик. Что я сделал с клиентами, так это следующее. Выберите место на локальном диске C: машины... например: C:\NetworkApps и скопируйте файл YourVFPApp.exe в эту папку C:\NetworkApps.

Затем создайте новый ярлык, указывающий на C:\NetworkApps\YourVFPApp.exe, и сохраните его.

Затем измените ярлык, но на этот раз измените папку «Начать в» на исходное местоположение, например «S:\SomeShare\». Сохраните изменения и запустите ЭТУ версию ярлыка.

То, что это в основном делает, - это запуск приложения ЛОКАЛЬНО, но начиная с того же конечного местоположения, которое используется совместно (особенно если пути жесткого кода были реализованы и с ними ужасно иметь дело). Это предотвращает потребность всех пользователей получать приложения по сети и просто иметь дело с фактическими таблицами и трафиком данных.

Да, это может быть немного больно, когда есть обновления приложений, но для этого я написал еще одно простое приложение VFP, которое смотрит на локальный диск, сравнивает exe с «последней версией», как в сети доля. Если версия сервера новее, скопируйте ее локально, ЗАТЕМ запустите ее, начиная с ожидаемой папки «S:\SomeShare\».

Что касается блокировки, если вы используете блокировку TABLE вместо блокировки RECORD, вы, очевидно, увидите больше проблем с задержкой ожидания сообщений блокировки, но устранение возможных узких мест в сети на стороне приложения может помочь вам решить эту проблему.