> There might be some confusion here. If you ping SERVERNAME
> successfully, that means that the TCP/IP link to the host machine
> is working. It doesn't mean necessarily that the network layer
> between the client program (gds32.dll on a Windows client) is able
> to find and connect to a specific database on the host machine.
> IOW, SERVERNAME finds the machine and the *physical* path (local to
> the SERVERNAME) finds the database file.

Right, but there's such a thing, I've found, as "remote" connections
and "local" connections. To wit:

Pick two random Win2k boxes.
Box1 has the interbase server and gdb files.
Box2 is a client.

Box2 can connect two different ways (Assuming only TCP/IP).
First way is the way we all know and love:

box1:c:\database.gdb

The second way is by mapping a drive (Say Z) to Box1's root c.
Then, you can connect like:
z:\database.gdb

Bsically, using localhost type protocols. Box2's interbase engine is
responsible for the access in this case. Not good to mix'n'match,
definitely.
However, what I thought you were saying was that if your connection
string looked like box1:c:database.gdb, that was the same in terms of
engine access as the mapping-the-drive method. Perhaps I
misunderstood, or not.

> If your installer is setting it, should one assume your application
> uses the BDE? There's no "server configuration" that identifies
> the location of databases, unless your installer is writing it into
> some Registry key or ini file that your application program knows
> about.

Unfortunately, that's correct. We needed to get it working ASAP, and
the BDE was the easiest route to go for the time being. Our next
version (Still under development) is using Interbase Express just
fine. As a side effect, though, transactions are not explicitly done
at all (In the BDE version. Part of the rewrite involved enabling
transactions). I'm assuming that TDatabases and TQueries do their
own transactions intelligently, but you know what they say about
assuming things.
However, the connect string is stored in an ini file, not in an
actual BDE alias. We make our own connection on the fly. This is
both good and bad. Only one place to check, one setting to check,
but users feel they understand ini files more than they do
bdeadmin.exe.

> >Anyways yes we're running windows. It'd be too complicated to try

to

> >support a database system on Linux, even though we'd like to.
>
> InterBase running on a Linux server is just like a worm farm. It
> sits there doing good, unnoticed. Unlike a Win server, it doesn't
> need to be nursed, coaxed or bribed to behave.

Don't get me wrong, we would like to run Interbase on Linux, however,
if anything were to happen, our customers would not be able to deal
with anything. Windows is at least familiar to people, even those
that don't know much. Our costs are such that it's not feasible to
fly someone out in the event a linux box fails... And trying to talk
someone through a Linux install over the phone? Ugh.

> Ah. Let's be clear. Forced Writes is a DATABASE setting, not an
> OS setting. If you are using an InterBase(R) v. 6.x server on any
> Windows platform and you didn't set Forced Writes ON yourself, then
> it won't be on. (Same applies to the pre-RC1 betas of Firebird).

Hrmm.. What I had read basically said the opposite. Oh well.

> The default InterBase(R) setting for Linux/UNIX servers is Forced
> Writes ON. For any flavour of Windows, it is OFF. It's kinda
> like "double jeopardy" since Windows is very poor at honouring lazy
> writes...in fact, recent evidence seems to indicate that it simply
> never does it unless and until you shut the server down entirely.
> This could get quite interesting in a 24/7 operation...

The document re repairing a database mentioned that on NT/2K it was
on by default, on 95/98, the setting had no effect, and that the
server made it off.
I will definitely be checking the databases at the office tomorrow to
get a definitive answer.

> I would want Ann Harrison's opinion about that before I would even
> consider going in and tinkering like this with a production
> database.

Agreed, which is why I'm outlining my plan, in the hopes that someone
will say "Hey, that's a dumb idea." :)
All I can say is that the very brief bit of empirical evidence I've
seen indicates it works.

- Jason