| Subject | Re: [firebird-support] Re: Missing Configuration File Aliases.conf |
|---|---|
| Author | Helen Borrie |
| Post date | 2008-05-06T23:02:18Z |
At 03:39 AM 7/05/2008, ra8009 wrote:
You *can* use a WNET path to connect remotely and I HOPE that this is what your remote client has probably done in the past. If the application code has a confused set of connection parameters, IBO can sometimes cut through the crap and ultimately resolve a network path. But I get a bad feeling about this.
Now, assuming both copies of the client had the path set as \\hostname\d:\path\to\database.fdb then you have a WNET path. It is NOT an UNC path. Even if the protocol was set to cpLocal, if you actually had entered that full path into the connection's DatabaseName property (which isn't recommended, it's just legacy support for old BDE apps) then IBO would ignore the Server, Path and Protocol properties when compiling the DPB. And all of this doesn't consider the possibility that you compiled the app with some stray properties hanging around in the Params structure of the connection object.
Now, if in fact the application really did compile a DPB that supposed cpLocal, then that says that, on the old setup, you must have had a local copy of the server and database on the dead disk and your two users have been using different copies of the database all along. But surely you would have noticed that ere now...
Now that your non-local client can't find a server to connect to, the red flags are waving. You need to get into that application code and clean up whatever has brought this to the surface. By all means use the IBO list for that.
./heLen
>I'm not AT ALL suggesting "misrepresenting the facts" deliberately. I'm just sure that your belief that the client machine ever connecting using cpLocal is misplaced. Knowing IBO and Firebird as much as I do, I *am* able to state that I don't believe that it was ever as you think it was.
>> >The protocol using IB Objects is set to cpLocal for all
>> >applications. Until everything on the client machine had to be
>> >reinstalled, everything had worked fine for years.
>>
>> I don't believe you, sorry. A cpLocal connection does not work
>across a network interface and *none* of the IBO connection protocols
>makes it so.
>>
>> You still haven't provided the connection string that your
>application uses.
>>
>> ./heLen
>>
>
>If it helps and if I'm remembering correctly, the two computers are
>connected using a crossover cable. The path specified in the
>connection component is using a UNC path to the target database. It's
>roughly \\HostMachineName\drive letter\directory\mydatabase.fdb
>
>I'm not sure what you don't believe. I'm sorry if I've miscommunicated
>something, but what motivation would anyone here have for
>misrepresenting the facts?
You *can* use a WNET path to connect remotely and I HOPE that this is what your remote client has probably done in the past. If the application code has a confused set of connection parameters, IBO can sometimes cut through the crap and ultimately resolve a network path. But I get a bad feeling about this.
Now, assuming both copies of the client had the path set as \\hostname\d:\path\to\database.fdb then you have a WNET path. It is NOT an UNC path. Even if the protocol was set to cpLocal, if you actually had entered that full path into the connection's DatabaseName property (which isn't recommended, it's just legacy support for old BDE apps) then IBO would ignore the Server, Path and Protocol properties when compiling the DPB. And all of this doesn't consider the possibility that you compiled the app with some stray properties hanging around in the Params structure of the connection object.
Now, if in fact the application really did compile a DPB that supposed cpLocal, then that says that, on the old setup, you must have had a local copy of the server and database on the dead disk and your two users have been using different copies of the database all along. But surely you would have noticed that ere now...
Now that your non-local client can't find a server to connect to, the red flags are waving. You need to get into that application code and clean up whatever has brought this to the surface. By all means use the IBO list for that.
./heLen