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.

Adam