Hi,

> 3.3 Doing everything manually
> Means probably the most work, but appears to be the safest way at the
> moment.
> 3.3.1 I could start with the final UTF8 database, i.e. with all the
> structure changes etc. included
> 3.3.2 The source database would be accessed by a connection with ISO8859_1
> as character set, the UTF8 one by a connection with UTF8 as character set

This would work if the application is able to read ISO8859_1 and write UTF8,
I think the DataPump
in Database Workbench should be able to do that for you.

Use USO8859_1, no Unicode client, for the source, and UTF8, Unicode client
for the destination.

> 3.3.3 Going through all the tables and "pump" the data manually into the
> new database, whereby the conversion to UTF8 would happen automatically (I
> hope). Good thing would be, that I could do the steps like 2.4 at the same
> time
>
> 3.4 Some other / better way(s) to accomplish what I need, you could think
> of
>
> The new version will be installed into a new folder, so that there will be
> files of two different firebird versions on the machine, until the old
> version gets uninstalled. So I also would need to know when and how the
> jump to Firebird 2.5.1 should be done, especially considering the note I
> found in one of the PDF files: "IMPORTANT: Before upgrading please pay
> attention to the files in the /misc/upgrade/metadata directory of your
> Firebird 2.1 installation as an essential step for preparing your
> databases for use under Firebird 2.1. If your databases contain metadata
> fields (like object names, comments/descriptions, computed field
> definitions, PSQL, view or constraint sources) storing non-ASCII data then
> the backup/restore upgrade cycle may not be enough to make them usable."
> This one sounds as if it's not relevant for me, as my databases are
> already used under Firebird 2.1, but I also believe having read, that
> about the same applies to blob fields and a change from Firebird 2.1 to
> Fireb
>
> Regarding 3.1.4 and 3.2.4: I've found this example on how to change the
> blob type:
> UPDATE RDB$FIELDS SET RDB$FIELD_SUB_TYPE = 0
> WHERE RDB$FIELD_NAME=(SELECT RDB$FIELD_SOURCE FROM RDB$RELATION_FIELDS
> WHERE RDB$FIELD_NAME='SOME_TEXT_BLOB_FIELD' AND
> RDB$RELATION_NAME='SOME_TABLE');
> Seems to work without the content getting lost. Sure, it's in the wrong
> format that way, but it seems to be possible to obtaint the content and
> then to save it in the new format. But depending on the choice of the way
> to go, this could be irrelevant.

You are modifying the blob to BINARY, that doesn't sound right.


With regards,

Martijn Tonies
Upscene Productions
http://www.upscene.com

Download Database Workbench for Oracle, MS SQL Server, Sybase SQL
Anywhere, MySQL, InterBase, NexusDB and Firebird!