:: This is another instance of "ISAM think". In an ISAM table
:: based system you save time by looking, locking, and then
:: updating in you application.

No - its not a matter of ISAM think. In fact I started working with SQL DBs
before I started working with ISAM DBs about 20 years ago. I fully
understand whats going on. Maybe I didn't state the question clearly.

The problem is between steps one and two:

1) Find an available row (FK = null)
2) Assing the FK.

Now the problem is if two transactions hit item 1 before the other hits item
2, they will both have the same row for step 2 and one will bounce the
other. Yes I can detect this but I was simply looking for possible
alternatives to reduce this possibilty or integrate 1+2 into one step. I
don't see any that I can think of.

But the problem is bigger. I could wrap 1+2 in a transaction. BUT the
problem is they are part of a bigger transaction. So now I have to break
this one out and program in my own transaction handling if this one fails
for another reason, or somehow isolate this one otherwise. If I put this in
its own, and it commits, but then the bigger one fails, now I have to
manully rollback this one... And vice versa..

I know I can detect it without committing, but the problem is until I
commit, every transaction that performs step 1 will no conflict unless I
commit...

:: Since much of the .NET framework was actually architected by
:: the same gentleman who architected Delphi, error handling in
:: the .NET framework can be expected to have a lot in common
:: with Delphi error handling.

I think you totally missed my point on this one too... It had nothing to do
with the .NET framework, but the .NET FB provider and whether or not there
was a way to detect this specific error and separate it out. I still have to
dig into its properties of its exception class.