Den 2012-03-15 22:22 skrev Marc Gilels såhär:

>
> Thank you for supplying the options for "Viewing". I never realized
> how different Firebird is
> than the Access database I was used to. I finaly got a hold of my
> IT/programmer and he
> claims that this new software has FB imbedded and that every version
> is the same version
> for server and client......he is going to get back to me with help. It
> will be interesting
> to see since he indicated that it should connect the same way Access
> did, with
> full permissions and a path to the server FDB.
> ~-|**|PrettyHtmlEnd|**|-~ end group email -->
>

Please don't top post (read here: http://en.wikipedia.org/wiki/Top_posting).

Sorry, but your IT/programmer is wrong. In fact, he's so wrong that it
proves he doesn't have a clue.

Firebird, like Oracle, MS SQL Server and IBM DB2 is a client/server
database. The database file (the FDB) is accessed by a server process
only, and the database file and server process have to be located on the
same machine (the server machine). Anyone wanting to do work with the
database connect to the server process, not to the FDB itself. In fact,
the client doesn't even need to know that a FDB exists. The server
process does all the work and reads and writes to the FDB LOCALLY ON THE
SERVER as needed. Then it sends the results back to the client of the
nettwork connection.

Repeat: the client talks to a server process = a server software program
that communicates with the client over the network. This is NOT a file
share.

To confuse things, there is something called Firebird embedded, which
others have described to you. This is just a Firebird client and a
Firebird server baked into a single dll. This is intended to work with a
client local FDB only, i.e. an application embedded database. Helen
wrote that the client portion of the dll can actually operate as a
regular client, and make connections to a remote dabase SERVER PROCESS
(NOT, repeat NOT, a remote FDB file made available on a network share).

So, it seems your client application has been developed for an embedded
database. That's fine as long as the data is usen only locally for one
single installation of the client application. If it needs to share data
with other client installations you would need one of these:

1. Modify the application to be able to connect to a "real server", i.e.
don't use embedded Firebird. This would also require a complete overhaul
of the sourcecode to make sure it handle concurrency and update
conflicts correctly. In other words: if client A loads some data and
modifies it, during which client B also loads the same data and modifies
it in a different manner and saves it, what should then happen when
client A tries to save its modification, in conflict with B's changes?
This may or may not be a lot of work.

2. Add some kind of data interchange mechanism into the application,
that doesn't really work with Firebird, but just sends data over the
network to whatever other client needs it. The FDB:s will not be in
sync, but it would allow the client apps to fetch and send data to other
client apps. This may or may not fit your requirements.

3. Keep using embedded Firebird but add replication to keep all the
local FDB files in sync. This seems like a lot of replication... What if
there are 200 clients? The amount of replication that would be
required... Whew!!! Not really an option is it? Furthermore, it would
still require the app to be able to handle the cases where the data
suddenly changes in the FDB because the replicator did some updates
while the client app was working with the same data.

I'd go with option 1. It's the correct way to work with a database like
FB if data is to be shared by multiple clients.

Good luck!
Kjell

--
--------------------------------------
Kjell Rilbe
DataDIA AB
E-post: kjell@...
Telefon: 08-761 06 55
Mobil: 0733-44 24 64



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