At 04:46 PM 22/04/2008, you wrote:

>Helen Borrie wrote:
>>
>> SQL> connect r:\scratchme.fdb;
>> Statement failed, SQLCODE = -902
>> SQL> connect \\shorty\deskstar\scratchme.fdb;
>> Statement failed, SQLCODE = -902
>
>I think that those two commands cause ISQL try to setup
>a) an IP connection to port 3050 of a DNS host called "r"
>b) a NETBIOS session to SHORTY
>each without touching the locally running FB server at all
>(and expecting a FB server "on the other side").

It couldn't make a Named Pipes connection with this string. The NP string would have to be:

\\shorty\d:\scratchme.fdb, i.e., the server-local path.

>> Meaning...I think...that the Y-valve is resolving the mapping to a straight network address and is reporting that it can't find a Firebird server there - not what we are trying to achieve. So - RemoteFileOpenAbility seems to be unavailable on a Windows network. Probably only works on NFS. Sorry to raise your hopes. Back to the flashdrive... ;-)
>
>You could try to use an alias. Write something like
>scratchme = \\shorty\deskstar\scratchme.fdb
>into your local aliases.conf and try "connect localhost:scratchme"
>in ISQL. Of course, this only works if your local computer
>has the ability to log into "shorty" without further credentials
>- no way to ask the user for a username and/or password here.

No, you miss the point I think. \\shorty\deskstar is a WNET mapping, i.e., it is ALREADY a Share. If RemoteFileOpenAbility were able to work on Windows, then the Firebird server on this machine (dev) should be able to attach to it as though it were a local drive. And BTW, the alias trick has the same effect as using the share path.

>And don't write
>scratchme = R:\scratchme.fdb
>because drive letter mappings only exist for the foreground user -
>if FB runs as a service, it doesn't know at all about any remote
>drive letters. (You could, maybe, succeed with "R:" when running
>FB as an application.)
>
>In any case, it's not _that_ simple... :-)

Indeed, WNET is a whole different story to NFS.

./heLen