> -----Ursprüngliche Nachricht-----
> Von: Michele Cannella [mailto:michele.cannella@...]
> Gesendet: Mittwoch, 1. Dezember 2004 19:22
> An: firebird-support@yahoogroups.com
> Betreff: Re: AW: [firebird-support] Firebird in automation
>
>
>
> Thanks for your answers tills now.
>
> as you mentioned the data acquisition server must work 24 h/day
>
> then the general idea is to :
> - have a cache in memory (this cache must be controlled by
> the application, not directly by firebird)

Yes. It's simply a synchronized FIFO queue. On one end, you write data into it as fast as you can get them from your AS, and if you have written some data, lets say 50 records, you signal an event to wake up the other thread which then pops the items from the queue, until ist empty, and writes them to the database.

> - using more connection to the DB to move data to the DB in
> big transactions (with more seconds of data)

As far as I can see, more connections wont give any performance gain. Simply use one single connection and commit every n seconds, so that there are no locking/concurrency issues.

> Do you know is could be better to use an embedded version of firebird
> instead of standard (super server) one for windows (I am using 1.5.0 on the plant) ?

Advantage: Faster, because no marshalling/overhead over TCP/IP. The whole engine is loaded in as a DLL into the memory space of your application

Disadvantage: If your application dies, the server also crashes. However, because Firebird is written with the possibility of crashes in mind, this shouldnt be a problem for database consistency. The worst case would be, that your database file gets damaged, and work for weeks is gone. This is, of course, very unlikely to happen. In any case, you should try to use exception-handlers and structured exception handling to get rid of any errors your code could produce, and let the database shutdown gracefully before your application dies.

Regards, Alex