Subject | Re: Embedded Server. A good option? |
---|---|
Author | Adam |
Post date | 2006-01-18T01:53:45Z |
--- In firebird-support@yahoogroups.com, "Luis Rocha" <luisfhw@t...>
wrote:
attracted by the easiness of the ES' installation, as we have many
users all along Brazil that have little or even no computer skills.
The less they have to interfere in the instalation process, the
better it will be for us.
support on these 5% multiuser clients.
with its TCP stuff pulled out. It will often be better performing
than Superserver. Only a single process can have access to the
database at one time, which rules out hot backups. There was at some
stage some comments about additional risks if your code does dodgy
things with pointers because Firebird runs the same application space
as your process, but this is the same as a UDF.
Super Server?
Yes, although the embedded server also doubles up as a normal client
if you give it a TCP connection string. You will need to change your
connection string (obviously), but you don't need to recompile. We
have an ini file that defines all that
[Firebird Connection]
HostName=localhost
DatabaseName=MyDB
EmbeddedMode=false
The internal logic goes something like
If (embeddedmode = false) then
begin
connectionstring = hostname || ':' || databasename
end
else
begin
connectionstring = databasename
end
Hostname is ignored for embedded installs. All of our current
installbase is either SS or CS, but I have a proof of concept
embedded mode with full functionality.
Adam
wrote:
>with no network. The other 5% work on a multiuser network environment.
> Hi,
>
> I have a system where 95% of the users work on a standalone basis,
> For many reasons we chose Firebird, but we're in doubt about wetherusing the Embedded Server for this 95% is the best choice. We are
attracted by the easiness of the ES' installation, as we have many
users all along Brazil that have little or even no computer skills.
The less they have to interfere in the instalation process, the
better it will be for us.
> We are planning to develop two versions: a stand-alone, with ES,and a multiuser, with Super Server, so we can concentrate tech
support on these 5% multiuser clients.
> I have two questions:Yes is seems reasonable to me. Embedded is just Superserver after all
> - Is this reasonable? Am I missing any important point?
with its TCP stuff pulled out. It will often be better performing
than Superserver. Only a single process can have access to the
database at one time, which rules out hot backups. There was at some
stage some comments about additional risks if your code does dodgy
things with pointers because Firebird runs the same application space
as your process, but this is the same as a UDF.
> - If afterwards a stand-alone user wants to migrate to a multiuserenvironment, do I just have to remove the ES files and install the
Super Server?
Yes, although the embedded server also doubles up as a normal client
if you give it a TCP connection string. You will need to change your
connection string (obviously), but you don't need to recompile. We
have an ini file that defines all that
[Firebird Connection]
HostName=localhost
DatabaseName=MyDB
EmbeddedMode=false
The internal logic goes something like
If (embeddedmode = false) then
begin
connectionstring = hostname || ':' || databasename
end
else
begin
connectionstring = databasename
end
Hostname is ignored for embedded installs. All of our current
installbase is either SS or CS, but I have a proof of concept
embedded mode with full functionality.
Adam