Subject | Re: [firebird-support] Firebird Service Problem |
---|---|
Author | Aage Johansen |
Post date | 2004-10-06T19:51:19Z |
Roberto Melo Cavalcante wrote:
will be a problem depends greatly on what the users do, and the hardware
that hosts the system.
My guess is that translating triggers will be some work ... (and the same
for StoredProcedures).
determined by configuration parameter on the server and on the client (host
file or connection string)).
If the client experience problems connecting to the remote server you
should check whether there is a firewall blocking the port.
--
Aage J.
> I'm in charge of research about firebird. We intend to give up oracle9GB should not be a problem for Firebird. Whether 120 concurrent users
> and we're studing Firebird for this purpose.
> Our database has about 9Gb and we make heavy use of views, triggers
> instead of, functions and stored procedures.
> We have about 120 concurrent conections to our database with medium to
> large transactions.
will be a problem depends greatly on what the users do, and the hardware
that hosts the system.
My guess is that translating triggers will be some work ... (and the same
for StoredProcedures).
> Another reason regards to availability of the service. Does firebirdAs others have mentioned, the port can be chosen "freely" (non-default port
> must appear as service listening to the 3050 port?
> We have it installed in gentoo machine and so far we haven't see 3050
> service available on machine. We do connect locally, but not from
> another machine. We have read the docs that come with it and all
> connection strings seem needing a kind of file server service to "serve"
> the database file. Is this correct? Can't I just make it be available
> through a service port just as oracle or PostgreSQL does?
determined by configuration parameter on the server and on the client (host
file or connection string)).
If the client experience problems connecting to the remote server you
should check whether there is a firewall blocking the port.
--
Aage J.