Zaxx Sergey Ch К сожалению VFP поддерживает только что-то среднее на уровне READ COMMITTED + SERIALIZABLE

Видимо, в VFP вообще нет понятия Isolation Level , есть только правило блокировать всё что изменено... И вы считаете что это "что-то среднее на уровне READ COMMITTED + SERIALIZABLE" ???

Sergey Ch Насчет купить "нормальную СУБД" - ни кто не спорит, что это лучше, особенно если у клиента много денег

FireBird - для тех у кого вообще нет денег.

w2wУ упомянутых здесь бесплатных СУБД -Firebird, MySql, PostgreSql, а также у не упомянутой HipersonicSQL блокировок по чтению нет.

Не знаю про HipersonicSQL и PostgreSql но в MySql - нет блокировок по чтению только в режиме READ-UNCOMMITTED. А использовать этот режим в серьёзных системах чревато проблемами с согласованностью данных. Хотя, область применения MySql далека от серьёзных систем. А для программирования сбора статистики для сайтов - даже транзакции не нужны.
Из перечисленных вами систем точно нет блокировок по чтению в Firebird.

Конечно, есть концептуальный вопрос считать ли InnoDB частью mySQL... В последнее время они сильно дружат, если не сказать больше.

16.11.2 InnoDB and TRANSACTION ISOLATION LEVEL

In terms of the SQL:1992 transaction isolation levels, the InnoDB default is REPEATABLE READ. Starting from MySQL 4.0.5, InnoDB offers all four different transaction isolation levels described by the SQL standard. You can set the default isolation level for all connections by using the --transaction-isolation option on the command line or in option files. For example, you can set the option in the [mysqld] section of `my.cnf' like this:

[mysqld]
transaction-isolation = {READ-UNCOMMITTED | READ-COMMITTED
| REPEATABLE-READ | SERIALIZABLE}

A user can change the isolation level of a single session or all new incoming connections with the SET TRANSACTION statement. Its syntax is as follows:

SET [SESSION | GLOBAL] TRANSACTION ISOLATION LEVEL
{READ UNCOMMITTED | READ COMMITTED
| REPEATABLE READ | SERIALIZABLE}

Note that there are hyphens in the level names for the --transaction-isolation option, but not for the SET TRANSACTION statement.

The default behavior is to set the isolation level for the next (not started) transaction. If you use the GLOBAL keyword, the statement sets the default transaction level globally for all new connections created from that point on (but not existing connections). You need the SUPER privilege to do this. Using the SESSION keyword sets the default transaction level for all future transactions performed on the current connection.

Any client is free to change the session isolation level (even in the middle of a transaction), or the isolation level for the next transaction.

Before MySQL 3.23.50, SET TRANSACTION had no effect on InnoDB tables. Before 4.0.5, only REPEATABLE READ and SERIALIZABLE were available.

You can query the global and session transaction isolation levels with these statements:

SELECT @@global.tx_isolation;
SELECT @@tx_isolation;

In row-level locking, InnoDB uses so-called ``next-key locking.'' That means that besides index records, InnoDB can also lock the ``gap'' before an index record to block insertions by other users immediately before the index record. A next-key lock refers to a lock that locks an index record and the gap before it. A gap lock refers to a lock that only locks a gap before some index record.

A detailed description of each isolation level in InnoDB:

* READ UNCOMMITTED SELECT statements are performed in a non-locking fashion, but a possible earlier version of a record might be used. Thus, using this isolation level, such reads are not ``consistent.'' This is also called ``dirty read.'' Other than that, this isolation level works like READ COMMITTED.
* READ COMMITTED A somewhat Oracle-like isolation level. All SELECT ... FOR UPDATE and SELECT ... LOCK IN SHARE MODE statements lock only the index records, not the gaps before them, and thus allow free inserting of new records next to locked records. UPDATE and DELETE statements that use a unique index with a unique search condition lock only the index record found, not the gap before it. In range-type UPDATE and DELETE statements, InnoDB must set next-key or gap locks and block insertions by other users to the gaps covered by the range. This is necessary because ``phantom rows'' must be blocked for MySQL replication and recovery to work. Consistent reads behave as in Oracle: Each consistent read, even within the same transaction, sets and reads its own fresh snapshot. See section 16.11.3 Consistent Non-Locking Read.
* REPEATABLE READ This is the default isolation level of InnoDB. SELECT ... FOR UPDATE, SELECT ... LOCK IN SHARE MODE, UPDATE, and DELETE statements that use a unique index with a unique search condition lock only the index record found, not the gap before it. With other search conditions, these operations employ next-key locking, locking the index range scanned with next-key or gap locks, and block new insertions by other users. In consistent reads, there is an important difference from the previous isolation level: In this level, all consistent reads within the same transaction read the same snapshot established by the first read. This convention means that if you issue several plain SELECT statements within the same transaction, these SELECT statements are consistent also with respect to each other. See section 16.11.3 Consistent Non-Locking Read.
* SERIALIZABLE This level is like REPEATABLE READ, but all plain SELECT statements are implicitly converted to SELECT ... LOCK IN SHARE MODE.

Я так понял, что файл-серверные СУБД смешали в одну кучу с серверами данных.

Проясните, плиз, что такое "десктопная СУБД". Если это что-то такое что может работать на Cel2400 512M RAM 40GB HDD IDE (в однопользовательском режиме или таки в многопользовательском?), то будьте любезны описать характеристики базы данных - объем, характер данных, темпы роста, количество и характер пользовательских запросов.

Бесплатные файл-серверные СУБД существуют, отчего нет. Поищите на sourceforge. Там же можно найти и вещи типа HSQLDB или FireBird, вот только зачем Вы их сложили вместе с FoxBase. А то можно и самому написать, небось для работы с dbf библиотеки найдутся, если лень написать их.