> > I use Firebird BLOBs to store documents. My transactions could

be

> > safely split in two parts, one that stores the document, one

that

> > shows it to the 'world'. The purpose to have the long part in

the

> > first transaction which does not prevent any concurrent work and

the

> > second transaction which must lock some stuff would be very fast.
>
> Your analysis omits the fact that storing new data doesn't block
> anything, so no part of the operation prevents concurrent work.

It also

> omits the fact that copying a blob from one row to another is
> approximately as expensive as storing it in the first place. The

copy

> operation makes a new blob and copies the content to it. There's

no way

> for two records to reference the same physical blob. There could

be if

> blobs had use counts, but they don't.
>
> So, yes, you can do what you're proposing, but no, it won't buy

you

> anything.

Thank you for the info, I just omitted one thing: the document comes
from the network and may come slowly, I may also play somewhat
lengthy algorithms in this first transaction.

Will the copy occur even for big blobs that are stored out of the
table pages? (knowing that I would first remove the blob id from
first row, then only set it in second)

Regards,
Armel