At 06:53 AM 13/03/2008, Gustavo wrote:

>Adam:
>
>I can´t find the way to work with this!
>
>Now I have the following:
>
>In the server PC (PC1):
>C:\Program Files\Firebird\Firebird_2_0\... {FireBird superserver
>installation)
>C:\Program Files\MyApp\MyApp.exe (and other files not related with
>FireBird)
>C:\Program Files\MyApp\DataBases\PC1DB1.FDB
>
>In the client PC (PC2):
>C:\Program Files\Firebird\Firebird_2_0\... {FireBird client installation)
>c:\PC2DataBases\PC2DB1.FDB
>
>If I understand what you are saying,

-- on a PC client machine that wants to access its own local copy of
the database

>I have to put the following files in
>the folder C:\Program Files\MyApp\ (the same where is MyApp.exe):
>
>fbembedd.dll (renamed to gds32.dll)
>icudt30.dll
>icuin30.dll
>icuuc30.dll
>firebird.conf
>firebird.msg

-- and don't forget to include the msv* runtimes somewhere in the system path, if they are not already present on this machine

>I did that (and I deleted the file gds32.dll from C:\Windows\System32 in
>PC2) and then, from PC2 (the client), I can run MyApp.exe (installed in PC1,
>the server) and I can access both PC1DB1 (which is in PC1) and PC2DB1 (which
>is in PC2) but... if I do this, a user in PC1 can´t access at the same time
>PC1DB1 because the embedded server has exclusive access.

Something is wrong in your perception of the models, then. The embedded server on PC2 cannot (should not) attach to a database that is on some other physical machine. On Windows there is one and only one way that this is physically possible AND YOU MUST NOT DO IT....that is by fooling the embedded server into believing the database is local, by way of a network mapping. REPEAT REPEAT REPEAT !! DO NOT DO THIS !!

Reason: The Firebird database engine is not a file-served system. The "database file" is actually a logical chunk of disk that the DB engine itself manages. In the course of doing so, it makes calls with respect to the physical file system manager on the *same* physical* system it runs on itself.

If you create conditions where it is possible for a Fb server (embedded or not) to open a read-write database on a different physical host machine then you are preparing to corrupt your database. Please tattoo this on a piece of your anatomy that you cannot avoid looking at.

[A "read-only database", which is NOT equivalent to a read-only file, is a special case, not addressed here...]

Actually Windows offers more than one way for you to maim and murder your databases. The exclusive write lock whose symptoms you describe above is a protection that Firebird Superserver applies to prevent a different Windows feature from corrupting databases. The embedded server is a Superserver instance.

OK - so - kill that mapping. The fbembed.dll that you have on PC 2 can be a server only for a database that is physically located on PC2. You need a plain-jane local connection path and, prior to the Fb 2 servers, it must use the IPServer "local connection", sometimes called "serverless connection", not the TCP/IP local loopback server "localhost". So this is the stand-alone situation that embedded is designed for.

The tip that Adam gave you is that the ****client portion**** of the fbembed library can *also* be used to make a connection to a server running on a remote host. You must use a remote connection string to do this, i.e. remote_server_hostname:d:\physical\path\to\database_file, where the entire path is the one as seen ***by the remote server***. PLEASE READ THE PRECEDING SENTENCE AS MANY TIMES AS IT TAKES TO UNDERSTAND IT.

>What I need is the following:
>
>1. With MyApp.exe, a user in PC1 (the server) can access PC1DB1 and at the
>same time, another user in PC2 (a client) can also access PC1DB1 and at the
>same time, another user in PC3 (a client) can also access PC1DB1 and so on.

Yes, this is the perfectly normal client/server situation - as long as you have fully internalised the difference between the physical path to the database file and the forbidden Windows path to a mapped drive or logical server.

>2. With MyApp.exe, a user in PC2 (the client) can access PC1DB1 (which is in
>the server) (at the same time the user in Pc1 and the user in PC3 are
>accessing this database too),

connection string for all clients, including the one located on PC2, is:
PC1DB1:C:\Progr~01\MyApp\DataBases\PC1DB1.FDB

or, if you must use Windoze native networking protocol, not recommended because of its bad s2n ratio:
\\PC1DB1\C:\Progr~01\MyApp\DataBases\PC1DB1.FDB

>and at the same time the user in PC2 can acess
>PC2DB1 (which for him is a local database). This access to PC2DB1 can be
>exclusive.

Yes, this is OK.

connection string for an embedded server connection:
IPServer local
c:\PC2DataBases\PC2DB1.FDB

In fact, the access to PC2DB1 **is exclusive by design** and you cannot make it otherwise.

>I know is a bit confusing. I hope you can understand. Is it possible to do
>what I need?

Yes, it is possible. It will be less confusing when your mind begins to accept that Firebird, being designed for cross-platform use, must approach the client/server relationship with extreme purity.

Windows tempts you with a number of non-portable features that can destroy databases designed for multiple platforms. The Firebird engine tries its best to protect you from these features by giving you lots of problems if you try to employ them. If you don't want problems, don't try...

./heLen