Проблема в том, что недостаточно просто дать возможность работать с одной таблитцей нескольким пользователям одновременно. Это-то решается элементарными настройками в главной программе:

SET EXCLUSIVE OFF

И проверкой опции Exclusive для всех курсоров в DataEnvironemnt форм и отчетов.

Основная проблема заключается в разрешении конфликтов совестного доступа: два пользователя "одновременно" решили модифицировать запись. Если ты писал программу в расчете на одного пользователя, то будут постоянные претензии со стороны пользователей о невозможности работать. Будут идти постоянные сообщения об ошибках.

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

Кроме того, при работе в режиме EXCLUSIVE OFF невозможно использовать ряд команд и функций. Тех, которые требуют единоличного доступа к таблице.

ALTER TABLE
INDEX when creating, adding, or deleting a compound index tag.
INSERT [BLANK] - Оставлена для совместимости с FPD. Не путать с INSERT-SQL
MODIFY STRUCTURE To use this command to change a table structure, you must open the table exclusively. You can, however, use this command in read-only mode when you open the table for shared use.
PACK
REINDEX
ZAP

Вобщем, Павел правильно сказал. Придется переписывать программу. "Косметикой" здесь не отделаешся.

help123
ВладимирМВряд ли, при создании однопользовательского приложения, ты заботился о сокращении времени блокировки записей и таблиц.
А как это. Я перед изменением данных в таблице использовал оптимистическую буфферизацию, и в сами таблицы изменения подтверждал TableUpdatе-ом, окруженным транзакцией. Правильно все ли делал???
Рад за Вас. Большинство разработчиков однопользовательских приложений так не делают, поскольку для одного пользователя это не нужно.

help123 ВладимирМневозможно использовать ряд команд и функций. Тех, которые требуют единоличного доступа к таблице:
INDEX, INSERT [BLANK], MODIFY STRUCTURE
INDEX - индекси по таблицам все построены в контейнере базы данных, тоесть во время исполнения программы я их нигде не создаю по таблицам. А только использую для связывания временных курсоров для формирования отчетов... а ведь они выполняются на стороне клиента... верно???
Опять же, рад за Вас. Грамотное решение.

help123А вот INSERT [BLANK] использую конечно, а что-же тогда делать... как добавлять записи в таблицы???
Мда. Не надо было включать INSERT [BLANK] в список. Вы ее спутали с дургой командой (INSERT-SQL) несмотря на явное предупреждение.

В FoxPro есть 2 команды, внешне похожие:

INSERT [BLANK]
INSERT-SQL

INSERT-SQL - это то, что Вы пишите примерно в таком синтаксисе

INSERT INTO MyTable (Field1, Field2) VALUES (m.Var1, m.Var2)

Эту команду можно использовать в многопользовательском режиме. Никаких препятствий и ограничений нет.

INSERT [BLANK] - это наследие FPD. Что это такое я описывать не буду, чтобы не вводить в искушение. Использовать ее вообще не рекомендуется даже в однопользовательском приложении. Оставлена исключительно для обратной совместимости с FPD.

help123 Диченконе заниматься глупостями а засесть за изучение MSSQL и клиент-серверных технологий
полностью с Вами согласен, MSSQL это круто, но зачем он мне, если в моей базе буду работать: я, мой менеджер, да еще 2 начальника будут один раз в день отчеты смотреть... Да и сложновато для начала... я ведь только почти VFP не до конца освоил...
Диченко слишком привык флеймить, а стиль общения во флеймовых форумах сильно отличается от стиля общения в тематических форумах. Большинство людей в таких форумах не расположены шутить вообще, а на таком уровне, на котором шутит Диченко воспринимают это как неприкрытое хамство.

(2 Диченко : это не наезд. Я то Вас понимаю, но шутка, как и ложка, хороша к месту и ко времени.)

PS: Зачем Вы выделяете свои сообщения жирным шрифтом? Не думаю, что в этом есть необходимость. Вам ответят и в том случае, если текст будет написан обычным шрифтом.

PaulWist
- SELECT xxx можно и не делать если используешь APPEND BLANK IN xxx, и ес-но такой же синтаксис использовать для REPLACE .... WITH ... IN xxx
Лично я наоброт, посоветовал бы по возможности всегда использовать SELECT xxx перед командами модификации. В ранних версиях FoxPro было много глюков, связанных с модификацией данных не в текущей рабочей области через опцию IN.

PaulWist
- конструкцию APPEND&REPLACE для красоты (и по идеологии) надо бы заменить на INSERT - SQL, сам понимаешь 2-е операции или одна (скорость однако)
Логика работы комады INSERT-SQL и APPEND+REPLACE достаточно отличны. Особенно это касается тех, полей, которые не указываются в списке полей для внесения значений (NULL или EMPTY). Все зависит от конкретной задачи.

Кроме того, опять же в ранних версиях были ряд глюков с командой INSERT-SQL, а вот со связкой APPEND+REPLACE никаких глюков не наблюдалось.

Поскольку автор не указал версию, то лучше перестраховаться.

help123 ВладимирМПроверка опции Exclusive для всех курсоров в DataEnvironemnt форм и отчетов. А если у меня в контейнере базы данных есть LocalView's и в DataEnvironment форм включены такие LV.
Так вот, у них свойство Exclusive установлено .Т. и изменению не поддается.
Будет ли это проблемой в многопользовательском приложении.???
Нет. Проблем не будет.

Local View - это по сути результат выполнения команды Select-SQL. Т.е. некая таблица, которая физически находится на машине клиента. Поэтому другой пользователь о ней вообще ничего не знает.

Даже если другой пользователь откроет то же самое Local View на его машине будет сформирована другая таблица, как результат команды Select-SQL.

Вообще-то, настройка по-умолчанию в DataEnvironment как форм, так и отчетов как раз и сделана в расчете на многопользовательское приложение. Т.е. если ты не менял для курсоров в DataEnvironment опцию Exclusive, то о ней можешь и не вспоминать. Там все настроено "как надо".

help123Еще вопрос: обязательно ли компилировать проэкт в *.exe, не можно ли поставить на каждую машину по Фоксу и запускать проэкт.
Просто пока будет работать только на 2-х компьютерах, и необходимо будет в процессе работы что-то корректировать в программе....
В принципе, такое сделать можно. Но! Такое ведение проекта требует слишком большой бдительности от программиста. Ведь по сути, у тебя будет даже не 2, а 6 копий:

-) 3 копии исходников (2 рабочих и 1 отладочная на твоем компе)
-) Для кажой копии исходника свои откомпилированные файлы (выполняется ведь не исходные файлы PRG, а их откомпилированная версия FXP)

А ведь возможны еще дубли файлов, как резервная копия или тестовые варианты.

Т.е. ты получаешь страшную головную боль, когда на одном компе все работает, а на другом нет. Вот и ищи, где именно расхождение!

То, что описал Диченко -это самая лучшая стратегия модификации проекта "на лету".

Отладочная копия - одна. Место для взятия нового релиза - одно. Взятие нового релиза происходит автоматически в момент запуска программы у клиента. От тебя требуется только скомпилить новый релиз и положить в нужное место. При этом количество клиентов не имеет никакого значения.

Сразу хочу предупредить еще об одной опасности такой корпоративной разработки.

Скорее всего, какой-нибудь начальник захочет чтобы в его приложении была орагнизована какая-то особенная обработка. Не такая как у "простых смертных". Тут возможны 2 принципиальных решения задачи:

-) Написать отдельную версию программы
-) Сделать ветвление в одной общей версии для всех

Так вот, я бы не советовал делать отдельную версию программы. Будет большая головная боль с модификацией: сделал модификацию в одной, но забыл в другой.

Лучше делать ветвление в одной общей версии для всех. Но еще лучше стоять до последнего на том, что такое выделение сделать очень сложно.