On Sat, 29 Jan 2005 06:09:43 -0000, Adam wrote:

>
>
>Hi Antonio.
>
>>
>> I was reading the Interbase Docs about TRANSACTION and I have two
>question
>>
>> 1.- How can I Start a Named Transaction. Is there a ·"Begin
>Transaction" instruction?ç
>
>What environment are you developing in (Delphi / Java / etc) and what
>components are you using to connect?
>
>There is a begin transaction method on your transaction components.
>
>>
>> 2.- Can I lock a single field like SQL Server for example:
>>
>> In SQL Server:
>>
>> SELECT P.CONCOD, C.CODALT, C.TPOCON, C.TPOCAL, P.IMPORT
>> FROM PERCON P (nolock), CONCEPTOS C (nolock)
>> WHERE P.CONCOD = C.CONCOD
>>
>> Can I do that in Firebird?
>
>SELECT P.CONCOD, C.CODALT, C.TPOCON, C.TPOCAL, P.IMPORT
>FROM PERCON P
> JOIN CONCEPTOS C on (P.CONCOD = C.CONCOD)
>
>Firebird uses multiversion records. In a nutshell:
>
>Transaction A starts
>A: Select * from table1
>A: Update table2
>Transaction B starts
>B update table1
>A: Select * from table1
>B: Select * from table2
>Commit transaction B
>A: Select * from table1
>A: Select * from table2
>Transaction A commits
>Transaction C starts
>C: Select * from table2
>
>Now:
>
>1) All the table1 queries in transaction A will receive identical
>results, even though transaction B has modified them. Because
>transaction A doesn't see anyone else's changes.
>
>2) Transaction B will not see the consequence of update table2,
>because Transaction A has not committed this before transaction B was
>started.
>
>3) Transaction A will see the impact of the update table2 when it
>does the select * from table2
>
>4) Transaction C will see the impact of the update table2 because it
>doesn't start until after transaction A commits.
>
>This means that your selects will never fail because of a lock, which
>is good news. Where locks come into play, is if both transaction A
>and Transaction B attempt to modify (read: update or delete) the same
>record in the same table. It also means that your updates and deletes
>will not fail just because someone else happens to be looking at that
>record.
>
>There are different transaction types, and they are basically about
>what you want to do if your transaction is trying to modify a record
>that another transaction is modifying. I normally prefer the no wait
>style of transaction, because that suits our app better.
>

Seems he is using a dirty read select. It's not available on FB
(thanks Jim to this and Borland by not to copy this thing to
IB)....