Hi

HB> The two options are Read Write (the default) and Read only. Read
HB> only would be isc_tpb_read in the transaction parameter block.
If
HB> you included the word 'read' in the list of transaction params,
it
HB> would at least be
consistent with the way IBX allows you to specify
IBTransaction.Params, i.e. chop off the "isc_tpb" part of the symbol
name.

Invaluable information, thank you!

>HB> (should be in a
>Concurrency transaction, for integrity of the reports, as well as
>reducing the overhead and memory usage.)

HB>OK, I didn't suggest that you should make it read committed -
that's
HB>why I went on to explain that it needed to be in a concurrency
transaction!! Since IBX doesn't have a property for transaction
isolation (which is what read_committed and concurrency are) then the
word "concurrency" in the list should do it.

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)

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

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

>And will that produce locking issues?

HB> If the transaction is read-only and concurrency, it won't produce
HB> any
locking issues.

Eeeck! They are! (See comments above)

We are still muddling along with trying to get the Services API
(Backup, Restore & No of Connections) working on Classic Server so am
sure we will be posting some more questions.

Thanks for all the help so far.


Chris Kudla