I have not tried an alias. Based on the information supplied I have probably not identified the server name and database name on the client correctly. I will get rid of the share.

The Database "CoPilot" is live and is Abbot's current version. The data I have input is also live. It is not a trial database.

FireBird and Guardian are installed by default when installing CoPilot, the application. There is a client and server install.

I will give the ideas a try.
Thanks,
M. Evan

--- In firebird-support@yahoogroups.com, Helen Borrie <helebor@...> wrote:
>
> At 02:44 AM 29/09/2009, you wrote:
> >I am working on configuring Firebird to run over my home network. The application and the database that i am trying to share are called CoPilot. It is made by Abbott Labs and is used to track diabetes data.
> >
> >My server is XP professional. I am running Firebire 2.0.1 at startup. When I launch the "CoPilot" server softweare on my machine it loads the Firebird Guardian.
>
> How are you determining this? If Firebird is running at startup *and* it is configured to use Guardian, then Guardian will be running at startup too. Did you choose to run Firebird with Guardian yourself, or did the Abbott Labs installer do it?
>
>
> >I map a drive from my workstation, which is running Windows 7 RC,
>
> If you mean an actual Windows mapped drive then this is almost certainly the main source of any problems you encounter with client connections. Firebird is client/server software, not file-sharing. The first thing to do is delete that mapping. Firebird databases must be on the same *physical* host machine as the running server and clients must access them by way of the physical path to the database file. Although client apps can access a database using the actual path in their connection string, e.g., 'MyServer:C:\data\MyDatabase.fdb', a properly deployed Firebird-backed system should use database aliases, which are configured on the server. That makes it so that the client apps don't have to know the actual path, only the alias, and connect instead with 'MyServer:MyDBAlias'.
>
> "MyServer" is the host name of the server: you can discover this by reading the Properties sheet from right-clicking on My Computer. An off-the-shelf deployment won't know the server name, so one supposes that the configuration routine for the *client software* is going to ask you for it. Thus, for the client installation, you would supply 'MyServer:MyDBAlias' (if the alias exists) or 'MyServer:C:\data\MyDatabase.fdb' if it doesn't.
>
> On the server, go to Firebird's root directory (by default, that would be C:\Program Files\Firebird\Firebird_2_0) and open the file "aliases.conf" in a text editor, such as Notepad. If aliases are used, then the vendor will have listed them there. Using our example above, you would see an entry like this:
>
> MyDBAlias = C:\data\MyDatabase.fdb
>
> If database aliasing has *not* been used, then you can put one in. Decide a simple name for your alias (case-insensitive, but only unaccented letters, the underline character or digits are valid, and no spaces), for example, 'copilotDB'.
>
> Find the exact path to the database file, copy it, and paste it next to the alias, e.g.,
>
> copilotDB = [the pasted full path string]. Remember, it must NOT be a mapped drive location or a share.
>
> Save the changed file. You won't need to restart Firebird: the alias will be available to the next client connection request.
>
> >I can connect to the database view and update the information. The connection is made thru the CoPilot software. In CoPilot on the workstation you change the data directory for the database to your mapped drive.
>
> NOT mapped drive. Give it the HostServerName:alias string, e.g., MyServer:MyDBAlias or 'Server:C:\data\MyDatabase.fdb.
>
> As a comment, by-the-by: if you are using a trial version, it is possible that the vendors have deliberately set this up to use a mapped drive to *prevent* you from doing anything with their software except view some sample data.
>
> >When I go to close the database I get an I/O error and am not able to exit the program. It gets hung.
>
> The i/o error is occurring because of the mapped drive, amongst probably more things if you are using a trial version intended to prevent you from operating a fully functional system.
>
> Possibly in your session you tried to write something to the database which, as explained before, won't work if the database is in a mapped location. This is *by design*. The disk space where Firebird databases live is controlled by the Firebird server (unlike file-served data storage systems, where data are managed in separate files under the control of the file system of the OS).
>
> Firebird can be configured to *read* a database in a mapped location but the database itself would need to be deployed as a "read-only" database. This is not the same as a "read-only file": it is an attribute that is set and unset in the header page of the database by a utility call initiated by the database owner.
>
> Tip: you can use the gstat tool to inspect the header attributes of a database. You don't have to be the database owner to do gstat -h. gstat.exe would need to be present in the \bin directory beneath the Firebird root. The attributes are listed near the end of the output:
>
> c:\Program Files\Firebird\Firebird_2_0\bin>gstat -h MyDBAlias
>
> Database "C:\data\MyDatabase.fdb"
> Database header page information:
> Flags 0
> Checksum 12345
> Generation 10652
> Page size 8192
> ODS version 11.0
> Oldest transaction 9118
> Oldest active 9119
> Oldest snapshot 9119
> Next transaction 9125
> Bumped transaction 1
> Sequence number 0
> Next attachment ID 10
> Implementation ID 16
> Shadow count 0
> Page buffers 4092
> Next header page 0
> Database dialect 3
> Creation date May 7, 2008 11:13:56
> Attributes force write, read only
>
> Variable header data:
> Sweep interval: 20000
> *END*
>
> "Close database" sounds like an application-specific thing. Clients *connect* (a.k.a. "attach") to the server, which then processes client requests. When a client wants to close the session, the application sends a "detach" request (a.k.a. "disconnect"). If that client is the only attachment, the server will put the database into a "shut down" state and listen for the next connection request. If there are other attachments, they won't be affected, i.e., one client's disconnection doesn't "close the database".
>
> >I am not sure what I am Missing.
>
> Well - all of that said, if you are a customer of the vendor, you should consult their support desk to fix up any problems. Noting also that you are using a free, pre-release trial version of Windows 7 on the workstation, it would not be a surprise to find that some key network component needed by the client application is lacking or disabled, either...
>
> ./heLen
>