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

>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

No, an InterBase client can't connect to a windows mapped drive.

>Bsically, using localhost type protocols. Box2's interbase engine is
>responsible for the access in this case. Not good to mix'n'match,
>definitely.

No, it is not using localhost protocols. Windows has "local connection" by which a client located on the same *physical* machine as the server + databases connects to the database through a thing called "client-mapped memory". In this case there is no SERVERNAME in the string, it is straight c:\database.gdb. Other machines can't connect to the database that way.

Then there is also tcp/ip local loopback, again, only possible for a client connecting to a server + database on the same physical machine. In this case the connection string is localhost:c:\database.gdb - or it could be box1:c:\database.gdb if you have an entry in the HOSTS file for the IP address 127.0.0.1:
127.0.0.1 box1 #local loopback incognito

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

You misunderstood. The mapped-drive "method" is not available. The bad string is permitted by Windows as an alternative to the legal tcp/ip string. The problem is, Windows doesn't realise that user A connecting with the bad string and user B connecting with the legal string are actually connecting to the same database file and so it sends the wrong message to the server. The server then treats the two connections as if they were to two different databases; so the work of the two users is not protected by record versioning nor exclusion by transaction control.

Remember - the server controls potentially many databases, even if your installation involves only one. So the server has no way to know that the two users are not working in different databases, if the operating system tells it that they are.

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

Whether you are using explicit transaction control or not is not relevant to the problem of the "bad connection string bug". It's a matter of miscommunication between the operating system and the server and it is caused by clients connecting with these mixed connection string formats. Why I asked about the BDE is that any user of any BDE application can stuff up the BDE alias for connecting to a database and become the source of corruption for the database itself.

But it's not just in BDE applications it can happen. It can happen in any situation where users are able to connect to a database using a string they designed themselves.

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

Ideally, if users go in an mess around with the connection string in their ini file, registry key or whatever, it should just prevent them from connecting. That's the assumption in the client code, too - either the string is "valid" or the connection will fail. Unfortunately, Windows has this undocumented "feature" whereby it will accept an illegal connection string but without the additional "feature" whereby it knows that the good string and the bad string should be equivalent.

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

Hmmm...it's true that Win 95/98 (and ME too, I believe) don't support delayed (lazy) writes. But that's not the point, since your server is Win2K and it does provide the option of delayed or immediate writes. Borland InterBase(R) v. 6.x for Windows installs with Forced Writes OFF by default or, to look at it from the OS's point of view, "with delayed writes enabled". (Firebird RC2 changed that to Forced Writes ON by default, btw.)

Helen