At 07:34 PM 2/03/2005 +0000, you wrote:

>Helen,
>
>I noticed your chat about the new FB server you made from leftovers.
>
>Most of my clients are running SBS 2003 and all have extra computers
>around that could be reconfigured as an FB server. What stops them
>is the additional expense of another license for SBS. XP would be
>fine except is only allows a few clients to concurrently log in.
>
>Do you use Linux for the FB server?

I have two Linux servers for FB in this network. One is a built-from-parts
box that I use for Kylix and for Firebird field testing; the other is my
laptop. IBO applications (both Delphi and Kylix) on any machine here
connect happily to databases on any other machine.

>If so does it integrate easily with a Windows network?

Clients connect to Linux using TCP/IP, which is a more efficient protocol
than the Windows-native Named Pipes (which IBO refers to as
cpNetBEUI). TCP/IP is preferred over Named Pipes, even when your network
is Windows-only.

The ideal is to write *all* of your apps to connect to Firebird using
TCP/IP. Actually, you should find that, if you abandon cpNetBEUI for
connecting to your XP server, the connection count limit will be gone. I
can't guarantee that XP doesn't have a hard-coded governor for TCP/IP
connection, though, as I don't have it to test. Legally, the connection
limit governs Named Pipes and device-sharing clients. A recent dissection
of the Server2003 EULA in another list demonstrated that the EULA has no
control over the number of TCP/IP clients that the server can take.

Btw, don't let the M$oft help text fool you into believing that, by using
TCP/IP for database connections, you lose Windows peer-to-peer
device-sharing services. Named Pipes and TCP/IP services are two transport
layers; device-sharing is another. Device-sharing and TCP/IP run happily
side-by-side on the same physical network. Firebird clients must never
cross over and try to access database files via device-sharing, however.

Helen