>---------- Original Message -----------
>From: "edward_van_h2002" <edward_van_h2002@...>
>To: firebird-support@yahoogroups.com
>Sent: Tue, 24 Feb 2004 09:09:04 -0000
>Subject: [firebird-support] Embedded version and concurrency?
>
>> Hi,
>>
>> Before I dive into how to deploy and use the embedded version of FB
>> final from VB with direct calls to the DLL... could a kind soul tell
>> me whether it provides some support for concurrency, or if it's like
>> SQLite, ie. it's really meant for stand-alone apps, and relies on the
>> OS to manage concurrent accesses?
>>
>> Most of our customers use our apps in stand-alone mode, but at some
>> bigger sites, more than one host needs to read/write data. So, since
>> FB 1.5 final just came out, I figured I should check out its embedded
>> version before hacking around SQLite.

At 10:29 PM 24/02/2004 +0100, Philip (unordained) wrote:
P> The embedded version will act just like a full-blown server as far as your app is concerned. Just make sure that your app is always programmed as if it were intended to be used in a multi-user environment, and then deploying the single-user version will simply be a special case where it seems like only one app is "connected to the server".

To focus on the database, though: the database file has to be located on the same physical system where the server is running. This is true whether the application is using the embedded server or has a "full-blown" (i.e. networking) server running. That means that, if you want remote clients to be able to access the database, you'll need to be running the full server in addition to any embedded servers that you enable on the system.

An embedded-server-client gets exclusive access to the database file - meaning that no client of the full server will be able to log in to the database while Ms Standalone is accessing it through her embedded server application.

In short, if you need concurrent access by remote users and Ms S., then Ms S, using the server machine as a client, should use the normal fbclient.dll and use local loopback (through localhost or the server's IP address). If concurrent access isn't needed, fine, use the embedded. The application code will work with either option.

P> Make sure you take all the precautions normally expected: pessimistic locking if needed, watch for concurrency "errors" that might occur if other users were on the system, etc.

In an embedded setup, there wouldn't be any "other users". However, the usual concurrency rules apply to concurrent transactions running within the same application. Pessimistic locking is a non-issue in the standalone situation.

P> One difference: username/password validation. Since the embedded server doesn't use the security database, it's going to believe you about usernames. As I recall, you still have to set up the username you want to use, and permissions, but the password isn't checked ... That might affect you, might not. (Helen should know more about that stuff.)

Let's separate "server security" from "database security". They are two separate issues. Embedded doesn't authenticate the user as a "server user", so any user name and password will do.

However, when you get attached to the database, SQL privileges kick in. To access any object in the database (except, alas, the system tables and generators!!!) there has to be a permission granted on it to the *user*. (No more passwords, as the assumption is that, if you got past the authentication, the password was OK). Every SQL privilege is "opt-in" unless the user is either SYSDBA (which has destructive access to *everything*) or is the Owner of (= "User who created") both the database AND the object.

So, if an embedded server app logs in as user aladdin password sesame, and the user aladdin doesn't have any privileges, he won't be able to see or do anything (except wreck the system tables and stuff up the generators, natch!!)

Of course, if you intended for the database to be open to a network or accessible from Ms Standalone's desktop, you wouldn't have neglected the SQL privileges, now would you? :-)

/heLen