Subject | Re: [firebird-support] UNC to drive letter path |
---|---|
Author | Thomas Bachinger |
Post date | 2003-09-03T10:32:37Z |
Hi Paul,
to believe that I' am missing a crucial point in the whole concept?????
... in my case, when I run the client application on the local machine and
want to communicate with the global database via the firebird server that
both reside on the same remote machine (and use the IBX components under
Delphi) I have to supply the local drive letter path of that database to the
IBX components to allow my client application to establish a connection to
the global database that is under the regime of the firebird server on the
remote machine. During the first startup of the client application process I
let the user supply the path to this global database via a windows open
dialog, then I store the path in a local database so that the client process
can access the global database directly on the next process startup.
HOW could I ever construct a user-friendly software if the user has to run
over to the remote server and find out about the local drive letter path and
run back to the client machine to supply this local drive letter path???? I
can also not hardcode the path to the global database into my application,
since it is certainly different from company to company!
Just as you presumed in your lines above I have also expected that, since I
have local insight into the server machine via the windows open dialog
(where I can freely browse all folders on the server and find my database
location) I can extract the drive letter path,... but unfortunately the
windows open dialog only returns a UNC style path from a remote machine
location, which I cannot use to connect to the database server! Somehow,
windows assumes that by having retrieved a valid UNC path you can directly
use this path to gain access to the file in question... this seems to be not
valid for the firebird server, which seems to have the same problem as I
do... he cannto resolve a UNC path and find the local path to the database
that he is governing???
... now to the crucial point that I start to believe I'am mising... I use
the IBX components to manage the global database connection and read/write
operations to it. For the IBX components to establish connection to the
global database you have to supply the local drive letter path. This works
fine if the application and the global database and the firebird server run
on the same machine (since I then can freely extract the local drive letter
path to the database)... could it be that one has to connect to the database
in a different way than supplying a drive letter path???? Is there some
other way to connect to a remote database and server????
> Aliases are new to 1.5, so unless they backported this mechanism to 1.0.3... the more info that comes in, the more I'am getting confused... I start
> - which would really surprise me - you can't use them with your current
> server. You'll have to use the full local path on the server, and as seen
> from the server.
>
> BTW: guessing a local path from a network path is dangerous, because you
> don't know how shares and share names are set up. (And if you do, you have
> "local insight" into the server machine, in which case you can probably
> also find the path to the database.)
to believe that I' am missing a crucial point in the whole concept?????
... in my case, when I run the client application on the local machine and
want to communicate with the global database via the firebird server that
both reside on the same remote machine (and use the IBX components under
Delphi) I have to supply the local drive letter path of that database to the
IBX components to allow my client application to establish a connection to
the global database that is under the regime of the firebird server on the
remote machine. During the first startup of the client application process I
let the user supply the path to this global database via a windows open
dialog, then I store the path in a local database so that the client process
can access the global database directly on the next process startup.
HOW could I ever construct a user-friendly software if the user has to run
over to the remote server and find out about the local drive letter path and
run back to the client machine to supply this local drive letter path???? I
can also not hardcode the path to the global database into my application,
since it is certainly different from company to company!
Just as you presumed in your lines above I have also expected that, since I
have local insight into the server machine via the windows open dialog
(where I can freely browse all folders on the server and find my database
location) I can extract the drive letter path,... but unfortunately the
windows open dialog only returns a UNC style path from a remote machine
location, which I cannot use to connect to the database server! Somehow,
windows assumes that by having retrieved a valid UNC path you can directly
use this path to gain access to the file in question... this seems to be not
valid for the firebird server, which seems to have the same problem as I
do... he cannto resolve a UNC path and find the local path to the database
that he is governing???
... now to the crucial point that I start to believe I'am mising... I use
the IBX components to manage the global database connection and read/write
operations to it. For the IBX components to establish connection to the
global database you have to supply the local drive letter path. This works
fine if the application and the global database and the firebird server run
on the same machine (since I then can freely extract the local drive letter
path to the database)... could it be that one has to connect to the database
in a different way than supplying a drive letter path???? Is there some
other way to connect to a remote database and server????