At 11:13 AM 11/02/2005 +0000, you wrote:

>My queries that don't do any updates, now all use read-only
>transaction (read, concurrency) Queries that perform updates use a
>transaction whose params have been set to read_commited, rec_version,
>no_wait. (as they always have been.)
>
>I now get a locking error when trying to insert a record (as part of
>a whole process that reads, updates, inserts, etc)

Then either the report transaction is *not* read only or you are getting
conflicts between some read-write transactions.

>Removing the "concurrency" from the read-only transaction resolves
>the problem.

Don't make your report transaction isolation anything *but*
concurrency. If you try to run a report in read committed isolation, it's
pretty certain that the data at the end of the report will be inconsistent
with the data at the beginning

Make sure, too, that you didn't accidentally configure your report's
transaction with the "Read-only Table Stability" radio button
option. Table Stability is also an isolation level and, in practice, you
should consider it just "not available". It will put a table lock on all
of the tables touched by the report, i.e. actually prevent any other
transaction from even seeing those tables, in many conditions. There are
better ways to get table locks than using Table Stability isolation (a.k.a
Consistency).

>Should I be looking at modifying the read/write transaction
>parameters rather?

In a process that "reads, updates and inserts", all of those things can
happen inside the same transaction; however, if another transaction is in
read committed isolation with no_wait, and your transaction has pending
updates or inserts, then the other transaction will not be able to
insert. The boot will be on the other foot for your transaction, of
course, if it wants to insert and another transaction has inserts, updates
or deletes pending.

This little problem only affects inserts, since inserts have no previous
record version. The solution, if you want one, is to run those
transactions in concurrency and to use wait, rather that no_wait.

Be sure also, if you are running those interactive transactions in
AutoCommit, that you throw in an explicit Commit regularly. Failing to do
this is the usual source of the garbage build-up that tends to make the
system gradually get slower and slower over hours or days.

As far as the report is concerned, first be certain that the report has its
transaction all to itself. Make it read only and make its isolation
concurrency. Wait/no_wait lock resolution doesn't have any significance to
a read-only transaction; and rec_version/no_rec_version has no
significance to a concurrency transaction. Make sure that the report's
transaction gets a hard commit when it is done; although a long-running
read-only transaction doesn't degrade garbage collection. Don't set
Autocommit true.

./hb