Hi Pelle,

> As of now my client application is written only using the IBO
> components. But I can see the idea of usion the IBO components for
> generating a lot of records and for populating my "Memory Tables"
> (ClientDataSets). Will I be able to also use IB_xxx components in
> the same application (without also having to use a IB_connection
> beside already using a IBOdatabase - hence endning up with each
> client application having to have 2 separate connections).

That's exactly how my application works. Also your application should
benefit from replacing your TIBOQuery to TIB_Cursor in every place
you don't need scrollable cursors (which probably will be a bonus in
Firebird 2.0), because they are faster.

> Perhaps better to ask in another way: Are there a big downside to
> let the client application have 2 connections to the database at
> once. If 300 users connect to the database using 2 connections each
> this will be 600 connections in total (I didn't sleep through all
> the Math-classes at school <G>). Will this have a major impact on
> the DB-server, or other downsides ?

From your client's speed POV you don't have to worry because with
Firebird, now the connection delay disappeared and scheme works very
well. From the server POV, it depends on the version you use; Classic
version allocates near 10 Mb per connection which requires you, for
300 simultaneous connections, to put more than 3 Gb of memory. Using
SuperServer version this is not a problem. But in my case I choose
Classic over Linux because memory is very cheap in those days.

Also I think I remember that Nickolay Samofatov said he has tried in
his local tree, probably modified, about 3000 simultaneous
connections, so we will probably see major enhancements in Classic
version 2.0, we hope.

Best regards,
Carlos Macao