> From: "Markus Kemper" <mkemper@...>

Hi,

> > I certainly think that if you could combine the 'best' bits of both
> > architectures into one version, that would be the way to go.
>
> I think (others may confirm or deny) that this is what
> we are trying to answer. Can we accomplish this or does
> the Classic need to continue on.

In my opinion, if you can get the 'pros' of both in one version, that is
what should be done. That should suit 99% of people, the other 1% can 'roll
their own' version.

[Killing a Client Process]

> > In production, it is very useful not only for those bad
> > queries you have missed :-), but for 'users' who disconnect
> > badly (using the on/off switch).
>
> If using TCP, this is already implemented (as of v5.6 maybe
> v5.5 -- I forget -- Charlie??) in SuperServer.

I tend to stick with the Linux version, so I am not sure. 'Idle' client
connections seamed to disconnect OK, it was the clients that were in the
middle of doing something big or long when they disconnected that caused the
problem.

> The Crystal
> reports / adhoc query issue is a killer. I think that improving
> our join performance could likely lessen the impact of many
> of those CR generated queries.

Yes the OLAP side of Interbase is probably its weakest feature, but its OLTP
blows the competitors products into the ground. The problem is, if you are
storing data, somebody always wants to 'do something in Access' with it etc.
I personally don't thing this side of things should be top of priorities
list, but any improvement would be great.

> > You could implement some extra triggers for 'users', AfterLogin,
> > BeforeLogout, AfterCrash, AfterTimeOut.
>
> I'm not sure that these would solve this problem but they are
> interesting to think about. Many things could be handled
> already with the Events in IBX/IBO.

Yes they do, but not everybody is going to be using Borland tools, there are
millions of (love them or hate them) Visual Basic developers out there that
could be using IB, not forgetting all the Linux/Perl/Python etc. people. I
am currently developing an application that has three different flavours of
client 'app' (Delphi, Java and IBPerl), and I need to write different code
for each one, where I would of preferred to do it as one stored procedure.

> > I did not think Superserver scaled at all on SMP machines, I
> > thought it took a performance hit?
>
> I suspect that if a performance hit is seen, its likely
> due to the OS' processor scheduling mechanisms. I've only
> heard troubles with NT and SMP with IB SS, thus IB_Affinity
> exists.

I meant NT, sorry. There must be a way round it, dare I say it, but M$SQL
Server nearly doubles its performance (to not quite as slow :-) ),with an
extra processor.

Cheers

Phil