Sorry,
When I wrote "named offer" I realize now I was referring to named shares; e.g., when a Windows user shares a folder with a given share name.

What I'm reading from your post is that named shares don't work. What's weirding us out is when we format the string as "\\Server\\ShareName\<RestOfPath (if any)\<FileName>.FDB", sometimes it works, and sometimes in doesn't. I'm just trying to find out why...

If it's necessary to prevent the user from selecting a named share (even though the dialog can find it, along with the .FDB file), we can do that. We were just hoping to provide the user with more flexibility.

Lane C.
NW Software

--- In IBObjects@yahoogroups.com, Helen Borrie <helebor@...> wrote:
>
> At 06:44 AM 5/04/2011, jlane_campbell wrote:
> >We're using IBObjects v4.8.7 with Delphi 7 under WinXP and Win7. Recently we added a dialog that lets users select a path to their .FDB file via a Delphi TOpenDialog, and if necessary, configuring the path returned, as the dialog's returned FileName (which includes the path) isn't always compatible with the TIBODatabase object's Connect method. In the case of returns via Network Neighborhood/Workgroups from a server with a named offer -- we would format the string as '\\<Server>\\<OfferName>\<Rest of Path>\<Filename>.FDB.
>
> Totally unclear what you mean by "named offer". I've never heard this expression before with respect to Firebird, InterBase or IBO. But if you are just letting users choose filepaths that are willy-nilly anywhere on the network, that's why you're getting the I/O error. The server won't open a database that is not on the same physical host machine as it is running on, nor to a location that is not *the* one and only physical location of the database file **as seen by the host machine**. It sounds as though you are letting them pick them up as network files on shares. Doesn't work.
>
> Nor do UNC paths work (like your example above). The Name Pipes protocol (called tpNetBeui in IBO) path to the SERVER-LOCAL file will work but it's not recommended, as it's a noisy protocol compared to TCP/IP (and TCP/IP is still noisy enough!). The pattern is \\<hostname>\d:\path-to-filename, where <hostname> is the actual network node name of the host machine and d:\ is the actual partition name where the path is located.
>
> Better to use tpTCP_IP as your protocol. Whats more fruitful is to take the "path" problem right out of the picture by defining aliases (in aliases.conf) for each database on the host server, thus replacing the whole d:\path-to-filename part and impossibility of having network users search. Have your app display a list of known database aliases that are accessible to the username that the user logs in as.
>
> > Here's the thing that is weirding us out ... it works for offers defined against a path on the C: drive, but not for any other (D:, E: or F: on my box). Nor is it a specific pattern, for on one office computer it worked for an offer against the F: drive.
>
> Get rid of all this. Fb and IB are not file-sharing engines.
>
> >In Debug, I can trace it to where the function isc_attach_database() is called from within the TIB_Connection.API_Connect procedure; at that point it returns the error without any inkling of what happened internally.
>
> The error message attached to 335544344 is "I/O error for file "some\file\name". That gives you somewhat more than an "inkling of what happened internally". It means the server couldn't open the file that is supposed to contain a database.
>
> >What gives? Is there some property of my drives or some condition of my computer's (or any other computer's) environment that would cause this?
>
> You could gain a lot of basic insight by reading the Firebird Quick Start Guide that's in the \doc\ folder of your Firebird server installation.
>
> HB
>