At 03:58 AM 03-01-02 +0000, you wrote:

>> 2. If the server is on a Windows host, are you certain that all
>> users (including those accessing the database with ad hoc client ???
>> tools like IBConsole) are using the same, correct connection string
>> EVERY TIME?
>>
>> This is correct (for TCP/IP):
>>
>> SERVERNAME:DISK:\path\ourdata.gdb
>>
>> This is incorrect but Windows will let you do it:
>>
>> SERVERNAME:DISK:path\ourdata.gdb
>>
>> If you have users mixing these two connection string formats, the
>> server treats each client as if it were connecting to its own
>> database and irreparable corruption ensues as night follows day.
>
>Really? I thought all that was needed was SERVERNAME: to make the
>dclient make the connection to the remote machine's Interbase engine
>as a "remote" client.

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.

>Very interesting... I have no idea if our installer is setting this
>correctly (I'd bet it is, but I'm not 100% sure).

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.

>Then again, it's
>also difficult to rule out the possbility that Joe Schmoe user
>changed something after the software got installed, either.

If you are using the BDE, then Joe Schmoe could certainly go in and mess up the alias setting in idapi.cfg on his or anyone's machine. Likewise, if Joe S. or anyone else is accessing the database file either locally on the server or from a remote workstation, using IBConsole, DBExplorer, Database Desktop, any of the numerous free or commercial "database manager" tools out there (including the command-line tools that ship with InterBase) and uses that bad connection string, even just once in a while when others are logged in to the database, then the corruption will surely follow.

>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.

>> Next: do you have Forced Writes enabled? If you are using a
>> Windows server with Forced Writes disabled, you are skydiving
>> without a parachute and hoping to land in a big fat haystack.
>
>I would guess we do, because according to the link posted below,
>default on NT/2k machines is forced writes on. The machines that do
>all database creation are 2k machines.

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).

>However, being as this gdb gets installed on multiple platforms,
>depending on the customer (Win98, NT, 2K), it kind of depends on what
>the server decides based on it's OS, correct?

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...

>We figured out at the end of the day that we could roll the
>transaction counters back in the gdb's header and at some point (We
>were going by a large number of transactions at a time), the database
>became "openable", with more data than we had before. We're going to
>be writing a program tomorrow to decrement the counters by one,
>attempt to open the gdb file, and then repeat until it can open. The
>idea is we can recover as much data as possible using this approach.
>I don't suppose anyone else has written this already, or tried, and
>figured out that it's not the right thing to do? :)

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

>In any event, thank you for your input. I'm hoping after a night's
>sleep everything will somehow magically work itself out. :)

My retirement plan consists of buying an autopick in State Lotto every Monday and Wednesday. Some day before I'm 65 I'm just BOUND to land the big one :))

cheers,
Helen