:: >If I have a bunch of select statements - if I don't care about
:: >consistency is it faster to put them all in a read
:: transaction or just
:: >run them separately?
::
:: Faster? you have to "run" each statement, whether it's in a
:: transaction on its own or with other statements.

Yes. But the question is - is there a difference between:

Begin trans
Select
Commit

Begin trans
Select
Commit

Begin trans
Select
Commit

Begin trans
Select
Commit

And

Begin trans
Select
Select
Select
Select
Commit

Is one better than the other speed/memory wise? That is assuming I don't
care about data consistency - I understand the difference between the two
regarding that.

:: >I assume if they are all in one the would create more read locks..
::
:: There are no "read locks". The choice of them being in

Yes sorry - versioning in FB which is different. But it still has to create
and track this info if updates are going.

:: >Both of the above would bein one transaction. I need it long enough
:: >just to get the PK and mark it as used.
::
:: Sorry, that doesn't make any sense. If the SELECT is in a
:: read-only transaction, then the update statement has to be
:: in a different transaction
:: - a read-write one. You can't perform updates in a read-only
:: transaction: an update is a write.

Assuming it was readcommitted, but with a write option.

:: configurations that the driver doesn't support. Both the
:: Java and ODBC drivers suffer from this inherent "dumbing
:: down", so it would be pretty amazing if the .NET driver were
:: different.

The .NET provider interfaces pretty well, although it has somewhat limited
options on the transaction level unless I override.