| Subject | Re: Using the Embedded Server |
|---|---|
| Author | Adam |
| Post date | 2005-05-29T21:16:27Z |
--- In firebird-support@yahoogroups.com, "csiagent029"
<csiagent029@y...> wrote:
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
<csiagent029@y...> wrote:
> Hello,issue.
>
> I'm considering using the Embedded server in the deployment of an app
> I've been working on. I've been working with Firebird quite well with
> it. My question is for anyone who has any experience in using the
> embedded firebird on a production application. Has there been any
> issues with it? Any problems the final user might have that with the
> full server it wouldn't?
>
> Thanks in advance to anyone who shares their experience about this
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