Todd,

>
> The appserver is Apartment threaded COM object. And there is no
> bottle neck I am just trying to better understand the differences in
> classsic and superserver.

SMP is primarily useful for better dealing with *concurrent* load. It
is *not* going to help too much if you only ever issue one query at a
time.

I am having trouble understanding your environment because your
feedback seems contradictory.

You mentioned in your prior post that you only establish one
connection. Again, Firebird connections are ***NOT*** thread-safe. You
are going to run into trouble if pretend they are.

1. You maybe mean one connection per 'apartment'? This is OK, and
classic will use SMP.

2. You maybe performing your own marshaling (hence my bottleneck
comment, making every connection queue for one connection). This is
OK, but will not use SMP on either model.

3. You like taking risks ignoring thread safety (holds tongue on
possible COM risks jokes ;) ).

> Right now we are using IB 6 but it will
> not scale.

Firebird 2 should outperform IB 6 in almost all areas even excluding SMP.

> And for most of our client base the Interbase 2007 cost
> is to much. I have not tried the classic version only the
> Superserver. Superserver does fine but does not appear to take
> advantage of the multi-processor enviroment.

Correct. But neither will Classic if you have just a single connection
at a time.

> Is there a problem switching from classic to superserver or vice

versa in a production enviroment?

No, providing you are using a TCP/IP style connection string (eg
server:alias or server:c:\data\data.fdb). It only takes a minute or
two to uninstall and reinstall.

If you play around with the .conf file to optimise any caches, then
you will need to make sure they are a sensible value for Classic.

> I just want to know that we can scale with Firebird and
> take advantage of these multi core machines.

We have a couple of 2003 servers with 8 cores. Classic uses as many of
them as it needs.

Adam