> you ARE talking about LIBS here, right? If so, it's contrary to what your

user support people would say - and I'm talking here not about 16-bit v.4
but 32-bit v.4.x and 5.x.

Yup.

> The understanding I had was that the IB licensing that installed from the

Delphi disks limited the number of LIBS connections to four. The slowness
of LIBS as >compared with a localhost or remote connection was demonstrable.
The flakiness of LIBS when threading is involved (e.g. when *legally* using
unlimited >multiple LIBS threads from a web application) didn't really come
to the surface until open source removed the licensing limitations.

The license linited the no. of connections and only allowed local not remote
connections. The Local Interface (Inter Process Communication) was
implemented into SuperServer, so that we would see the same kind of
performance for local connections on windows for SuperServer as we
originally did for Classic. The IPC mechanism was then meant to be rolled
out to other platforms. It didn't happen for a number of reasons.

> Charlie Caro attributed the LIBS blow-ups with multiple threads to the

fact that, with local connections, the client and the server share the same
inter-process >communication space. IOW, additional threads overwrite and
corrupt one another's messages, or try to and cause GPFs. He commented to
the effect that >LIBS was designed that way and it wasn't likely to be fixed
because it wasn't broke. My inference: now I understood why IB support
would say "LIBS wasn't >intended for deployment".

1. If Borland are saying that LIBS isn't for deployment, then the message
has changed :-)
2. LIBS uses the same IPC mechanism as the full server, no difference, so
you could argue that you shouldn't use local connections on the full Server
version as well as LIBS, if you can't deploy LIBS for local access, you
shouldn't deploy the full server :-)
3. The IPC implementation as Charlie correctly identifies, does have its
flaws.
4. The main issue re. threads etc was because the local gds32.dll wasn't
thread safe, on analysis you can write decent threaded routines for LIBS so
long as you put the relevant (non thread safe code) into critical sections.
5. The issue re. threading and non thread safe InterBase, seems to now come
down to a botched implementation of gds32.dll, and the fact that arrays are
not handled properly. Threading seems to work, unless your database happens
to have arrays. Ann has more details on this. Something we need to look at
in more detail and fix.

> >The only difference, tended to be the license key :-)
>
> ..when licensing was in effect, yes; once licensing was gone, the REAL

differences surfaced and caused problems. Is this not the case?

The only difference between LIBS and Full Server is the license key. The
same local connection problems would exist on LIBS and Full Server.

Regards
Paul