This group of parameters is what will change the level of isolation. As @Arioch said in his compact comment, you can change the isolation level by changing the Options property, which is of type TTransParams . This is a set of TTransParam as shown below.
// Transaction parameters TTransParam = ( { prevents a transaction from accessing tables if they are written to by other transactions.} tpConsistency, { allows concurrent transactions to read and write shared data. } tpConcurrency, { Concurrent, shared access of a specified table among all transactions. } {$IFNDEF FB_21UP} tpShared, { Concurrent, restricted access of a specified table. } tpProtected, tpExclusive, {$ENDIF} { Specifies that the transaction is to wait until the conflicting resource is released before retrying an operation [Default]. } tpWait, { Specifies that the transaction is not to wait for the resource to be released, but instead, should return an update conflict error immediately. } tpNowait, { Read-only access mode that allows a transaction only to select data from tables. } tpRead, { Read-write access mode of that allows a transaction to select, insert, update, and delete table data [Default]. } tpWrite, { Read-only access of a specified table. Use in conjunction with tpShared, tpProtected, and tpExclusive to establish the lock option. } tpLockRead, { Read-write access of a specified table. Use in conjunction with tpShared, tpProtected, and tpExclusive to establish the lock option [Default]. } tpLockWrite, tpVerbTime, tpCommitTime, tpIgnoreLimbo, { Unlike a concurrency transaction, a read committed transaction sees changes made and committed by transactions that were active after this transaction started. } tpReadCommitted, tpAutoCommit, { Enables an tpReadCommitted transaction to read only the latest committed version of a record. } tpRecVersion, tpNoRecVersion, tpRestartRequests, tpNoAutoUndo {$IFDEF FB20_UP} ,tpLockTimeout {$ENDIF} );
Since the Interbase 6.0 code is "opensourced", the documentation for the API has not changed much. Therefore, if you want an explanation about any of these, the documents you are looking for are in the Interbase manuals.
You can get them here http://www.firebirdsql.org/en/reference-manuals/
Below I quote Anne Harrison in this link for a quick explanation of the usual options used:
isc_tpb_consistency can cause performance problems due to the fact that it locks tables and possibly rules out concurrent access. isc_tpb_concurrency is the design center for Firebird. Readers are not block writers, authors do not block readers, and both represent a database.
isc_tpb_read_committed + isc_tpb_rec_version + isc_tbp_read_only give inconsistent results and sometimes cause an error on the read blob *, but unlike other modes, it does not block garbage collection, so this is a good mode for long read transactions that should not get the "correct" answer.
isc_tpb_read_committeed + isc_tpb_rec_version has the same performance as isc_tpb_concurrency, but gets conflicting results - the same request can return different rows twice in a row in the same transaction.
isc_tpb_read_committed + isc_tpb_no_rec_version + isc_tpb_wait is slower than in other modes, because it will wait for a change sooner than reading the last completed version. Like all variants of isc_tpb_read_committed, it does not create consistent results.
isc_tpb_read_committed + isc_tpb_no_rec_version + isc_tpb_no_wait gives many, many errors in the deadlock, because every time the reader encounters a record that changes, it returns an error.
NOTE. I hope that you will see that next to the parameters are not specified equally, it is not so difficult to understand if you delete the "isc_tpb_" part.