> 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) ? Using Database Explorer,
or this tool, I cannot connect to the database unless I use the
localhost keyword...

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 ? (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).

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

The current ini file *changed after your first post*, doesn't contain
these path variables, as I realised they are wrong and probably
irrelevant. Therefore, the ini file is more like : *don't have it with
me atm* - Even with the above removed, I dont get the app to show
up. : -\

[Current]
Database=pc340xp:\CasalaV32\Database\SERVDB.gdb
Language=Australian English
ProcessSet=La Trobe
[Defaults]
AnalysisType=0
PercentCorrect=50
MinimumNumber=2
PrintClientNames=0
ShowHelpHints=0
Language=Australian English
ProcessSet=La Trobe

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

I get the error "Unable to open Database" with and without the
exclamation marks.

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

I get the error "Unable to open Database" using the new suffix of .FDB.


So is there something else that I can do to get the remote database to
be accessed from within this Delphi application ?

Thanks!



--



Analyst
B. Engineering, B. IT
A.N.U (2004)

M: +61 401 409 620
H: +61 3 9376 8580


"In life, always do right. This will gratify some people and astonish the rest."

— Mark Twain