At 02:52 PM 3/05/2006, you wrote:

> > Are you the writer of the software? It seems most likely that the
> > app needs something from that ini file in order to show its main
> > screen. Several things relating to paths in the original version you
> > showed us are not valid paths...notably --
> >
>
>I am not the original write of the software, that is Paul Spain, and I
>don't know whom since his first release.
>
>However, I realised that in the TDatabase Params, I have the following
>parameters in order to connect to the local database. *within the
>software*
>
>SERVER NAME=LOCALHOST:C:/CasalaV32/Database/testing.gdb
>USER NAME=SYSDBA
>OPEN MODE=READ/WRITE
>SCHEMA CACHE SIZE=8
>LANGDRIVER=
>SQLQRYMODE=SERVER
>SQLPASSTHRU MODE=SHARED NOAUTOCOMMIT
>SCHEMA CACHE TIME=-1
>MAX ROWS=-1
>BATCH COUNT=200
>ENABLE SCHEMA CACHE=TRUE
>SCHEMA CACHE DIR=%TEMP%
>PASSWORD=masterkey
>
>Am I doing something wrong here by having the database path as the
>SERVER NAME (using the localhost keyword) ?

Yes. "localhost" is not a keyword. It is the name of a server,
specifically the "local loopback server" on the SAME physical machine
as the client ("client" = the machine that is running your
application). But WNET (Named Pipes, NetBEUI) doesn't know anything
about "localhost". It is a specifically TCP/IP thing.

>Using Database Explorer,
>or this tool, I cannot connect to the database unless I use the
>localhost keyword...

*If* there is a Fb or IB server running on the same physical machine
as Database Explorer (which is just a client application) AND there
is a database file of the given path and name on THAT same machine,
then "localhost" will find and connect to THAT database.

Note that, by having those parameters in the TDatabase Params
property, your application is hard-wired to connect to that
testing.gdb database.

>So is this causing some deeper problems in the software when accessing
>a remote database ? and should I be setting the SERVER NAME to some
>thing else and using a Database Path elsewhere ?

It would be hard to say for sure, since we have no idea what your ini
file is supposed to do. Maybe, before connecting, there is some
routine that goes through and overrides the hard-wired params and
replaces them with something from the ini file. If that is the case,
you should be able to find the routine in your source code (and clean
it up!! This is very untidy programming.)

>(The only consideration is that in designing reports at design-time
>using Quick
>Report software, I may need to access the database to preview the report).

Ummm...errr..well, it would certainly be handy, both at design time
and at runtime, to be certain you were actually connecting to the
right database, as well...

./heLen