Subject | Re: [firebird-support] BLOB-ID |
---|---|
Author | Ann W. Harrison |
Post date | 2004-01-23T23:55:10Z |
At 12:31 PM 1/23/2004, Elmar Haneke wrote:
it is a combination of the relation id of the table, the pointer
page for the relation, and the offset on the pointed-to page that
represents the blob.
The create_blob call has no record context - it hasn't a clue
where or whether you will store a record connected to the blob.
So it returns a distinctive temporary blob id. That id is
converted to a real blob id in the process of storing the record.
locally.
well, yes it is a purely mechanical translation, but only from
the point of view of the database internals.
Regards,
Ann
>isc_create_blob does give me the 64Bit ID to write into database.The blob id you get back when you read a record with a blob in
>Writing into Database and reading it Back from there does work ok.
>But, the ID read from the database does differ from the one written
>before.
it is a combination of the relation id of the table, the pointer
page for the relation, and the offset on the pointed-to page that
represents the blob.
The create_blob call has no record context - it hasn't a clue
where or whether you will store a record connected to the blob.
So it returns a distinctive temporary blob id. That id is
converted to a real blob id in the process of storing the record.
> This is a problem for me since I intend to work with cachedYou may have to cache blobs associated with unstored records
>data which currently implys to read the blob with the ID written to
>database.
locally.
>How can I transform the ID recieved from "isc_create_blob" to beYou really can't - it's not a purely mechanical transformation -
>suitable for "isc_open_blob"?
well, yes it is a purely mechanical translation, but only from
the point of view of the database internals.
Regards,
Ann