Thank you, Adam.

As you can see, I am not enough acquainted of the database engine details.
I suppose that maybe in some computers where the Delphi application can work with both the local and remote databases (I mean the .gdb files) the Firebird installation produced a Firebird server to run on those machines, allowing the program to access both physical files (is it so?) and in the others, the client software won't grant access to the local .gdb file, but yes to the remote one.
Should I uninstall the engine on the critical PCs and try to re-install it with a new feature, in order to have all the computers with a Firebird server running on it? Is there another better solution?
Sorry, I try to explain myself clearly, but remember that I speak in Spanish.
Thank you.

----- Original Message -----
From: Adam
To: firebird-support@yahoogroups.com
Sent: Monday, December 22, 2008 12:56 AM
Subject: [firebird-support] Re: Problems with local drive


--- In firebird-support@yahoogroups.com, "Manuel Aragoneses"
<exactsoft@...> wrote:
>
> Doug, thanks a lot for your prompt answer.
>
> The facts are: about 12 PC in a Windows 2000 Lan, accessing a
Database file on a file server through a Delphi application, which
also needs to access (in some special cases) another database file
that resides on a folder in the C: (local) disk.

Firstly, databases <> files. In the Windows world, a database resides
within one or more files (from the OSes perspective), but thinking
about a database as a document is very unhelpful.

Clients *NEVER* directly read and write to your database file.
Instead, they ask a Firebird server to read and write to that file on
their behalf by issuing (usually) SQL statements. If the server is
satisfied about the credentials of the client, it will perform the
necessary actions.

So the Firebird server (ie, fbserver.exe or fb_inet_server.exe under
Windows) must be installed and running on the machine where the
database "file" resides. Furthermore, it should *NEVER* be located in
a shared folder where its security is entirely compromised and
potential for corruption exists.

There are several supported protocols, but TCP/IP is the most common
and recommended. The Firebird server listens to TCP 3050. The Firebird
client library communicates with the Firebird server on your behalf.
The client library is called fbclient.dll (must be renamed to
gds32.dll if you use certain Delphi components).

So your application interacts with fbclient.dll, which in turn
interacts with the Firebird server. The Firebird server may be running
on either the same or on a different physical machine. The connection
string informs the client library of the interface, the server name
and the database. So to use TCP, it would look something like

MyServer:MyDatabase

where MyDatabase is configured inside aliases.conf to point to the
physical location of your file.

You should see by now that there is NO possibility for a "typical"
Firebird client to directly write a database file, so if indeed you do
have another database file on the local drive, then either:

a) There is a Firebird server ALSO installed on that client in order
to handle that; or
b) The client is actually the embedded database engine, a special
version of the client library which "embeds" the entire database
server into your client application. The embedded database engine acts
just like a normal client library when you pass it a TCP/IP connection
string, so this is possibly your situation.

You need to find out how your deployment has been done.

Adam





__________ Información de NOD32, revisión 3709 (20081220) __________

Este mensaje ha sido analizado con NOD32 antivirus system
http://www.nod32.com


[Non-text portions of this message have been removed]