At 08:32 PM 2/05/2006, you wrote:

>On 5/2/06, Helen Borrie <helebor@...> wrote:
> > At 05:47 PM 2/05/2006, you wrote:
> >
> > >I tried changing the .ini file to the following using your
> suggestions. For
> > >some reason, the Applicatoin does not give an error, and does not actually
> > >show up on the screen, however, I can see the process in Taskmanager...
> > >
> > >[Current]
> > >Database=pc340xp:C:\CasalaV32\Database\SERVDB.gdb
> > >Language=Australian English
> > >....
> > >etc
> > >
> > >I believe I don't actually know how to check the 'host name' of
> this REMOTE
> > >pc. Pinging it from a command line gave me IP: 128.250.66.197
> >
> > What did you ping = pc340xp?
>
>ping pc340xp (that is the name of the pc on the network domain). eg.
>pc****.melbuni.edu.au etc

If so, then the Database path in the ini file is OK.

>The software program is used to do speech analysis on a transcript of
>speech that is typed into a database. This database is currently local
>to the client application. The software manages client data who are
>part of the study or whose speech is analysed, therefore this data
>contains several tables.
>
>The software GUI consists of several interfaces designed in Delphi,
>and also has reporting functionality using QuickReport software. The
>inteface shows up when I use the local database, however, I am trying
>to make it possible for multiple users to use a single database over a
>network. Therefore, each user will have a separate install of the
>software, but shall access the central database, on say pc340xp.

That should work OK.

>The ini file so far has been used to store the parameters for the
>software package, as given above. Basically it contains the database
>path information, and some basic software analysis variables.
>
>I am not sure what the ExportPath and ImportPath parameters refer to.

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 --

[Current]
Database=Localhost:\\pc340xp\!CasalaV32!\Database\SERVDB.gdb
(already dealt with: localhost isn't valid to use to access a remote server)

But these two are probably the source of the problem

ExportPath=Localhost:\\pc340xp\!CasalaV32!
ImportPath=Localhost:\\pc340xp\!CasalaV32!

But I do see what this is about. Someone read an old article written
by Claudio Valderrama about an internal hack by which you used to be
able to "alias" a database path on Win NT by hiding it behind a share
name, and have the client library resolve it by providing a weird
syntax which the client library can pass to the server and the server
will parse and use to get the proper physical path from its own
Registry. However, if this still works, it's not going to work with
localhost because that provides no route to a share that's defined on
the remote machine.

In short, while it might still be possible to do the hack (assuming
that, on the server, there is a share called CasalaV32 defined on the
server that points to the full path of the database file) by
correcting the "weird path" to
Database=pc340xp:\\!CasalaV32!\Database\SERVDB.gdb.

You could try it - it either still works or it doesn't! But it's
unnecessary to do this sort of hack with Fb 1.5 and above, since the
engine itself surfaces database path aliasing. See previous posting
and release notes.

Here's another possible reason why your application is a no-show: if
the database is on an XP host machine, that ".gdb" suffix could well
be the problem. Again - read the release notes. XP will lock that
file as soon as the server tries to open it, and run a file image
copy utility called SystemRestore. The server then won't be able to
open the database until SR finishes. If it's quite a big file, that
could take some minutes. Change the database suffix!

./heLen