Thanks for your reply.

And you got me thinking about stuff I hadn't considered really.
The thing would be, how do you run a script to initialize the database
at setup? Or on an existing firebird database for that matter?
Do you use a particular installer for that?
Thanks for any insight you can give me on this. It's the first time
I'm trying to deploy an app that should install everything on its own.
Before I've installed the apps myself for the most part.

Thanks again.

> I think that you need to consider the primary differences between
> embedded and say superserver. ie. Which application space Firebird
> runs in. Because it essentially runs in the same space as your
> application, bad code in your application can in theory crash
> firebird. (Of course never writing bad code myself, I couldn't
> possibly prove this ;) ).
>
> Seriously though, one one application can access the database at a
> time. This may be significant if you intend on having a service
> running in the background and your main application as a separate
> application to this. Also, connections from other workstations are off
> limits.
>
> On the security front, forget about it. You obviously need to
> distribute the fdb file for it to work, which means that they can copy
> it to another firebird installation and connect as SYSDBA, do whatever
> they want, then copy it back over the top of the real one.
>
> These are obvious when you think about how it works for more than 10
> seconds. We do not use embedded server in our production environment
> because generally speaking we have multiple users from multiple
> workstations, and we have a service in the background doing amongst
> other things imports and exports to and from other systems. We have
> however created an embedded version of our product mainly for sales.
> They can stick our app on a USB key, and run it on a potential
> customers desktop without installing or uninstalling anything, or
> worrying about their firewall or virus scanners.
>
> If you intend on releasing an embedded version, then a data
> abstraction layer is probably the way to go. This could run as a
> service, and you could then write as many other services and
> applications as you needed that talk to the data abstraction layer
> rather than the database directly, but you would need to test this for
> yourself to see if it is feasible.
>
> Hope that helps
> Adam