>А почему сразу не взять SQL сервер?

Все правильно. IP-сервера по скорострельности и функциональности не будут конкурировать.
Сделано для снятия проблем с надежностью в ФС-приложениях, а также для обеспечения
доступа к ним через интернет. При этом переписывать приложения почти не надо.
Но нарушается монолитность приложения - часть кода на сервере, часть на клиенте.
Поэтому я тоже думаю, что проще использовать SQL-сервер. А если стремиться сохранить
монолитность приложения - то терминал.

>лана, щаз все же загляну в описание mdb, разберемся в вашей фантазии.

Думаю, что стоит побольше знать об альтернативных технологиях, даже
если не собираешься их использовать. Тогда меньше наивных мыслей и больше
плодотворных идей... Успехов.

Выкладываю выдержку из доки и выдержку из переписки разработчиков по поводу транзакций в топспидовских таблицах. На этом завершаю обсуждение.

=======================================================
Transaction Processing--the TCF File
Speedy Logging and Automatic Recovery

TopSpeed transaction logging is very fast (about 100 times faster than the Clarion
driver). With LOGOUT, the TopSpeed engine posts all transactions to memory.
ROLLBACK simply frees the memory, while COMMIT writes out the database changes in a
stream. If a system crashes during a transaction (LOGOUT--COMMIT), the recovery is
automatically handled by the TopSpeed driver the next time the affected file is accessed.

The Transaction Control File

The transaction control file (.TCF) is used to ensure that changes to more than one DOS
file, which are grouped into a transaction, either all happen or none happen. By default
the transaction control file has the name "TOPSPEED.TCF." The TCF driver string lets you
change this. See TCF for more information.
When any workstation finds a file which is in a partially committed state, and which was involved in a multi-file transaction, it needs to access the TCF file to decide what to do. The TCF file provides "atomicity"--a single (boolean) storage location which inndicates if a multi-file transaction committed or not.

Note that the .TCF file contains very little information; it just serves to coordinate multi-file commits. The actual rollback/commit data is stored in the data (.TPS) files.

How TopSpeed Transaction Logging Works

LOGOUT gives each transaction a unique id which it stores in the .TCF file. LOGOUT also stores the .TCF file name and transaction id in each data (.TPS) file which is updated, so that after a crash, the next time the file is opened the TopSpeed driver can find the .TCF file and do any necessary recovery. COMMIT removes the unique transaction id from the .TCF file.
To be effective, the .TCF file must be accessible when any files controlled by it are accessed. Therefore, you generally should not delete or move .TCF files. If a transaction updates network files, you should specify a transaction control file on the network.

It is not necessary to use the same TCF file for all transactions; however, we strongly recommend it. The consequence of there being several TCF files with various levels of accessibility (or of a deleted or overwritten TCF file) is that some of the files within a transaction might be updated and others left unchanged.

=============================================

Здравствуйте, коллеги!

Все таки решил до конца разобраться с работой
процесса транзакции на TPS-драйвере.

Сначала некоторые уточнения и дополнения к предыдущим
моим письмам по этой теме.

- Во время выполнения оператора COMMIT() физическая запись
данных в файлы производится поочередно в порядке, обратном
порядку их задания в операторе LOGOUT().

Все это происходит в четыре этапа:
1. Создается TCF-файл и в него записывается информация о таблицах,
участвующих в транзакции.
2. Данные, накопленные в транзакционном буфере,
записываются во ВСЕ таблицы в резервные(временные) страницы.
Некоторые особенности этих страниц будут описаны ниже.
3. Происходит модификация TCF-файла.
В чем она заключается - не разбирался, но это - единственная
модификация TCF-файла в рамках транзакции. Очевидно, что
при этом записывается информация об окончании этапа N2.
4. Записи из резервных страниц во ВСЕХ таблицах переписываются
в нормальные(постоянные) страницы. Резервные страницы при
этом не удаляются. Это произойдет лишь во время закрытия
таблиц оператором CLOSE().

Особенности резервных(временных) страниц, в случае прерывания
выполнения оператора COMMIT():
- до завершения этапа N3, резервные страницы НИКАК себя
не проявляют в дальнейшем.
- после завершения этапа N3 и до завершения этапа N4:
- если до транзакции таблица была пустой, то ВСЕ записи
в резервных страницах нормально читаются ВСЕМИ операторами
типа GET/NEXT/PREVIOUS;
если в таблице уже были записи, то резервные страницы
не видны.
- если до транзакции таблица была пустой, то при первом-же
выполнении оператора модификации типа ADD/PUT/DELETE
записи из резервных страниц переводятся в нормальные
а сами резервные страницы удаляются.
- при закрытии таблицы оператором CLOSE резервные страницы
просто удаляются.

- Автоматического восстановления таблиц НЕ ПРОИСХОДИТ!!!

- если выполнение COMMIT() прервалось во время
выполнения этапа N4, то ВСЕ таблицы открываются
нормально, но резервные страницы остаются на месте со
всеми последствиями, описанными выше.
Оператор CLOSE() удаляет резервные страницы.
При этом модификация одной таблицы НЕ ЗАТРАГИВАЕТ
другие таблицы, которые участвовали в транзакции!
Таким образом, если во время этапа N4 некоторые
таблицы уже были полностью обработаны, то их
"ОТКАТА" НЕ БУДЕТ НИКОГДА!

Вот так!!!
В транзакции участвовало несколько файлов, а их восстановление
происходит РАЗДЕЛЬНО!
Т.е., НИКАКОГО СОХРАНЕНИЯ ЛОГИЧЕСКОЙ ЦЕЛОСТНОСТИ ДАННЫХ
транзакция НЕ ОБЕСПЕЧИВАЕТ!

Хотя, нет, стоп! Не столь категорично!
- Логическая целостность обеспечивается на все 100% ТОЛЬКО
ДО выполнения оператора COMMIT().
- Крах ВО ВРЕМЯ выполнения оператора COMMIT() практически
не страшен до завершения этапа N3.
- Крах ВО ВРЕМЯ этапа N4, В БОЛЬШИНСТВЕ случаев,
приводит к НАРУШЕНИЮ ЛОГИЧЕСКОЙ ЦЕЛОСТНОСТИ данных!

Короче, остается лишь уповать на надежность оборудования
в том коротком промежутке времени, когда выполняется
этап N4 оператора COMMIT()!
И, соответственно, стараться делать обьем транзакций минимальным.
Хотя, как в таком случае соблюсти логическую целостность?!

И еще остается вопрос - на кой нужен TCF-файл!?
Если он реально НЕ ОБЕСПЕЧИВАЕТ связное восстановление
таблиц, участвовавших в транзакции!

Ау, коллеги, "близкие" к SV!
Возможно разработчики из SV опровергнут мои выводы
(очень хотелось-бы!), или, хотя-бы, дадут некоторые
разьяснения!?

Кстати! Во время открытия таблицы, которая участвовала в прерванной
транзакции, определяется факт наличия незавершенной транзакции!
Но никаких действий по ее "откату" НЕ ПРОИЗВОДИТСЯ!
Почему - не стал вникать - уж слишком там "наворочено".
Поэтому хотелось-бы и по этому поводу получить разьяснения
от разработчиков SV!

=============================
С уважением, Олег А. Руденко.