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

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

Логичным в этом случае представляется два возможных решения

1. Организация режима блокировки до завершения процесса создания и передачи файла
2. Организация стека файлов и стек передачи

Что имеется в виду

1. Организация режима блокировки до завершения процесса создания и передачи файла

Это значит, что как только пользователь нажал кнопку "Сохранить" следует взвести некий "флаг" (признак), говорящий другим пользователям о том, что начат процесс сохранения и передачи файла. И пока передача файла не будет завершена это признак не сбрасывается.

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

Но у данного способа есть ряд недостатков

1. Сложность определения момента завершения копирования. Т.е. когда именно будет завершена работа внешней (по отношению к FoxPro) программы. Вот этой самой RUN /N c:\temp\filename.exe
2. В случае, если по каким-то причинам будет аварийное завершение работы программы и флаг останется не сброшенным, придется вмешиваться вручную для его изменения


2. Организация стека файлов и стек передачи

Здесь речь идет о том, что при каждом сохранении формируется уникальное имя файла. Лучше всего формировать имя файла как префикс + порядковый номер. Ну, что-то вроде File0001.txt, File0002.txt, File0003.txt,...

Это нужно для того, чтобы получив список файлов для передачи можно было понять, в какой последовательности передавать файлы. Кто был сначала, а кто потом. В принципе, очередь можно реализовать через дополнительную таблицу с парой полей: Порядковый номер, имя файла

Ну, а далее, процедура передачи RUN /N c:\temp\filename.exe будет последовательно перебирать файлы в порядке их создания и передавать на удаленный сервер. Если нужно, переименовывая их

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

DmitryKnА можно ли как-то проверить из Fox запущена ли внешняя программа? Т.е. если filename.exe запущена - пользователю сообщат и попросят подождать, затем внешняя программа отработает, а пользователь повторит попытку сохранить и все тогда сложится наилучшим образом ?

В принципе можно. Используя API-функции получить мгновенный снимок списка процессов и сделать поиск нужного процесса. Но!

На каком компьютере Вы собираетесь искать этот процесс?

На том, где работает текущий пользователь? На "сервере"? На всех компьютерах локальной сети?

Кроме того, у Вас есть гарантия, что filename.exe запущен именно Вашим приложением? Может, кто-то просто из проводника запустил для копирования своих файлов. Также остается проблема "зависания". Ну, завис процесс. Потребуется ручное вмешательство, чтобы его "пнуть"

И это еще если процесс работает без создания процессов-диспетчеров как Acrobat-reader, например. Попробуйте открыть любой файл PDF и посмотрите список процессов. Вы с удивлением увидите, что процессов больше, чем открытых файлов PDF.

Т.е. это тупиковый путь. Использовать можно только в очень ограниченных и специфических ситуациях.