At 09:34 AM 23/07/2009, you wrote:

>Hi guys,
>We have an application here at work that was written in the mid to late 90's that has a database server that is running on firebird 1.0.3 on redhat. The database has the borland extension (.gdb) and all the automated backup files have a .bak extension.
>
>I am trying to copy and transfer the database to firebird 2.1.2 on windows server 2008.

You'll need to restore it with some extension other than ".gdb". This suffix causes problems from Windows utilities that think ".gdb" files belong to an Outlook plugin. The common convention for Firebird database files is ".fdb" but it can be anything (or nothing).

>Things I have tried so far:
>shifting the .gdb file to the windows system and registering the new database.

Might work on compatible Intel platforms but not recommended. Put "registering the new database" aside...that has nothing to do with Firebird. It's a convention used by some third-party tools.

>restoring one of the .bak files to a new database

This is the recommended approach. However, you MUST back up the ODS 10.0 (fb 1.0) database using the gbak that comes with fb 1.0 AND use the -t[ransportable] switch. (Later versions of Fb apply this switch by default; AFAIR, Fb 1.0 doesn't).

Restore the transportable backup using the Fb 2.1 gbak.exe under the running Fb 2.1 server. On Server2008 you will more than likely have to use the -se switch. If localhost:service_mgr throws a network error, use the host machine's network name in place of localhost. (Though do first check that localhost is present in $windir$\system32\drivers\etc\hosts).

>These methods are not working.

That is not a helpful observation. When things are "not working" and you want help to make them work, describe HOW they are not working and report any error messages you see. Tip, for restoring, you should use the -v[erify] switch to get a verbose report and, if you want it to be a log, also use the -y switch to send the output to a file.

Some compatibility points:
1. Fb 1.0 created databases with a default page size of 1024 bytes. This page size is not valid for an ODS 11.1 database (v.2.1.1). Use gstat -h on the RH server to see what the page size is. Also jot down the cache buffers as this will be material to the migration (Superserver and Classic need to have quite different cache sizes.)

Specify a page_size of 4096 or more bytes in the restore command.

2. Seriously study the installation and migration guide for v.2.1. There are issues you can't avoid with the MSVC8 runtime libraries. The most up-to-date notes on this subject (vital for Server 2008) can be downloaded from the v.2.1.3 RC1 pre-release area (link through from website main page, test versions listed at top of developer news items).

3. On Server 2008 you almost certainly will have permissions issues.

>Can anyone point me in the right direction? Are there any intermediate steps?

Read documentation. Be aware of migration issues. Plan.

./heLen