Alan,

A> Some one else here tried it the other day
A> and couldn't work out why it won't work.

so you're basing your answer on hearsay, which is not always safe.
BTW I read those messages (even though when I did it the thread was
already done); AFAIU that person was trying to use a TCP/IP connection
string which obviously doesn't work with the embedded server.

A> ISAPI has always wanted a TCP connection string - it won't work with a local
A> connection string...
A> why? because it needs to make trheaded connections.

That's not exactly the reason (IIS couldn't care less that Fb's client
library is not thread-safe for the local protocol <g>), but it has
been a lucky coincidence.

A> Try it, you'll find out how quickly it locks up.

No need to try, it's clear enough.
But I keep finding myself repeating that *a connection
to the embedded server is not a local connection*. It doesn't use the
local IPC protocol! It uses direct exported function calls. It's safe!

I had a long argument with Dmitry Y. once re. the opportunity to
recycle the local connection syntax for embedded connections. At the
time I preferred something like "embedded:somealias" to distinguish
local and embedded and to be able to use the embedded server as a
client for a local server (no TCP involved), and also to avoid
confusion in users <g>. In the end Dmitry convinced me thta from an
architectural POV it was appropriate to do that (and anyway it was he
who had to do the work so he had the well deserved right to decide,
not to mention that he knows better for sure). My objections were
based mostly on instinct; perhaps I should have insisted. :-(

I am growing tired of having to state this over and over because
people not only haven't even tried (which is fine if they don't need
it), but feel they need to export their misconceptions to others. :-)
You're not alone in spreading this kind of incomplete information,
that's why I jumped up. Sorry but I have a strong feeling about it:
the embedded server has a great potential that should be recognized at
large.

We need a clear statement: embedded supports multiple connections;
embedded supports multi-threading. While I write this I am
stress-tesing a server application I developed myself with Fb embedded that
is happily serving 100 concurrent threads; something it wouldn't be
able to as fast and stable had I used TCP/IP.

A> I can only imagine that people are tempted to use the embedded server
A> because it means they can deploy on a hosted server without need for there
A> provider to set them up with FB.

which is a killer! It allows to inject Firebird, without all its
security problems, in a hosted machine. Saldy not many hosting
providers allow ISAPI tout court. :-(

A> Great idea but it won't work.

I'm not in the ISAPI business so I won't say it works: I haven't
tried. But there appears to be *nothing* that prevents doing it, except
perhaps newer versions of IIS using multiple processes to host a
single ISAPI dll (for whatever purpose), which seems unlikely to me.
Mind you, IIS *does* use a separate process ro host ISAPI dlls (which
makes it possible to unload a specific DLL and other nice things), but
as long as it's a single process then the embedded server requirements
are met.

Se people try it, stress-test it and come back with the results. I
foresee they'll be positive.

Ciao
--
Nando Dessena
mailto:nandod@...