At 11:09 PM 1/05/2004 -0400, you wrote:

>I am using Firebird hooked to tIboDatabase, compiled with Delphi 6.
>
>Since my new server will have its FireBird connection at a location that is
>different from my test environment, my app needs to make a decision at
>startup (runtime) as to where to find its database. This is a webhub app and
>I set the location with a literal.

ok, if you are using Firebird 1.5, I STRONGLY advise using the database
aliasing feature. This allows you to softcode the hard path part in your
application as a Firebird alias.

>In testing, the behavior is as expected when, with the same path, the file
>name is changed, but if a new path is given (tracing confirms the new path
>is correct), it appears that the app still looks for its data in the
>original (design-time) path. I tested with no data at the new location, but
>the app made a normal startup, finding its data at the old location.

That is bound to be the case if you hard-code the databasepath into the
app. If you take that approach, you will have to compile the app for every
location.

>In addition to the code below, what else do I need to do?
>
>I am assuming that my tIboQuery objects' database name properties will
>conform to that of tIboDatabase, and do not have to be separately reassigned
>at runtime.

That depends. If you insist on using the old VCL properties, you're
limiting things to the old VCL "compile-or-die" model. If you can bear to
part with DatabaseName and embrace the IBO connection model, then you will
1) set Server, Path and Protocol properties (not DatabaseName)
and
2) use the IB_Connection property on the data access objects (not DatabaseName)

That way, all of the data access objects will make their databasename
associations directly with the IBODatabase (which I presume you are using).

>The folllowing code is executed in the FormCreate() method:
>
> with dbOcaf do begin
>
> Connected := false;
>
> DatabaseName := pWebApp.Literal[ 'DatabaseName' ];
>
> try
>
> connected := true;
>
> except on e:exception do begin
>
> (* log the error *)
>
> Application.Terminate;
>
> end; { on e:exception }
>
> end; { try...except }
>
> end; { with dbOcaf }

It's impossible to tell anything about timing from this code. We get back
to creation order. Whose FormCreate is this? Datamodule? Webmodule?

If you are going to assign connection properties you have to do it before
the connection takes place, i.e. the BeforeConnect event of the TIBODatabase.

Now, to using aliasing for softcoding...

In aliases.conf, have an alias that you use consistently for this app,
regardless of where Firebird is running. Let's say it's WebAppDB.

On your developement machine, your aliases.conf might have
WebAppDB = d:\develop\webapps\backend.fdb

On one site's webserver machine, it could be
WebAppDB = e:\backend\backend.fdb

On another it could be a different db name on a Linux server:
WebAppDB = /data/deployed.fdb

In your app, it doesn't matter. Just put WebAppDB into the Path property
of the IBODatabase. IBO compiles only the alias. At run-time, fbclient.dll
will resolve the pathname to whatever it is, on-site.

If (as you should be) you are developing with TCP/IP and localhost, then
prepare from the start for a substitutable hostname. Hard-code cpTCP_IP
into the Protocol property.

Now, the only variable is the hostname. If you are going to be running the
webapp locally, just stick with locahost and you can simply hardcode
that. If there is a chance some sites will want to run the webapp on the
webserver machine and the dbserver on its own machine, then make the
hostname a run-time assignment in BeforeConnect.

The first time you set up Server, Path and Protocol, IBO will automatically
write the current setting to DatabaseName. I STRONGLY ADVISE editing this
to a "user-friendly" name like "fluffy" or "clouds". That will ensure that
you will get an error during development if you have old code referring to
that property.

Helen