Subject | Re: [firebird-support] Update Blob type 2 |
---|---|
Author | Helen Borrie |
Post date | 2011-07-26T05:23:35Z |
At 02:15 PM 26/07/2011, you wrote:
Back up the database *first* and restore it to check that the backup is good.
Applications usually edit blob fields inside local structures and stream them back to the database using a special function call. Maybe nobody ever tried to "update" this particular column in this fashion, thus signalling the engine that it needs a blob filter.
You only want a sub_type 1 field for that. You don't need a filter...unless maybe (for some reason) you want to code a richtext-to-text conversion to be performed on the server. For Firebird's part, it has no idea what kind of text is in there, except that it is character set-aware - unless your database uses charset NONE. From v.2.1 onwards you can apply internal string functions to text blobs. I could see that causing grief if you tried to apply string functions to richtext but that's a different problem.
Be aware that, in Fb 3, all metadata will become read-only. I'd be prepared for life to get tougher in future if you don't deal with those misused system sub_types as a repair job you have to do.
./hb
>Yes, I meant Sub-type 2. I don't know why it was used for this field.Sounds like a designer error.
> Can I change it without losing data already in the field?If it was my database, I'd define a new sub_type 1 column and update it with the contents from the problem field; verify that the data in the new blob is good; then drop the problem field and rename the new one (all with commits in between, of course!)
Back up the database *first* and restore it to check that the backup is good.
>I did see the declaration for filters. And I can write a UDF styleYou didn't say what you wanted to do...
>function to do that.
> But was looking to see if there was something I could do within the existing system. The fields are meant to hold notes. But they may also hold rich text data. But it seemed like FB 1.5 was allowing a statement like:Maybe, maybe not. To "update" a blob, Fb deletes the old one and writes a completely new one with a new blob_id. The blob_id is stored on the data record; the actual blob data usually goes to a blob page. (Sometimes, if the blob will fit on space available on the same data pages as the record, the blob data will be stored there instead but it's not something you can predict.)
>update hdw_table set blob_notes = 'Test Notes' where hdw_id = 12345;
Applications usually edit blob fields inside local structures and stream them back to the database using a special function call. Maybe nobody ever tried to "update" this particular column in this fashion, thus signalling the engine that it needs a blob filter.
You only want a sub_type 1 field for that. You don't need a filter...unless maybe (for some reason) you want to code a richtext-to-text conversion to be performed on the server. For Firebird's part, it has no idea what kind of text is in there, except that it is character set-aware - unless your database uses charset NONE. From v.2.1 onwards you can apply internal string functions to text blobs. I could see that causing grief if you tried to apply string functions to richtext but that's a different problem.
Be aware that, in Fb 3, all metadata will become read-only. I'd be prepared for life to get tougher in future if you don't deal with those misused system sub_types as a repair job you have to do.
./hb