At 04:07 PM 03-01-02 +0000, you wrote:

>1. We're using the latest OpenSource Interbase (6.0.1.6 Open
>Edition)...

That "latest" Open Source InterBase binary is more than six months old. It was (is) the last free binary you will see from Borland. Furthermore, Borland's InterBase general manager Jon Arthur recently announced that the Open Edition won't be receiving any of the changes that they put into their commercial editions. So even if you build your own from source code, it's going to be the same old thing with perhaps a few bugs fixed that were already fixed in Firebird long ago. InterBase(R) Open Edition has no apparent future. Are you prepared to buy commercial licensing? That's what InterBase(R) is all about. Borland isn't a charitable institution, after all.

>Moving to Firebird is definitely an option in the
>future, however for right now, we're trying to fix the bugs we have
>(The devil we know, versus the devil we don't, and all that..
>Possibly in the new IBX rewrite of our software).

If you are going to rewrite your software with IBX then count on commercial InterBase(R) in your future. IBX is locked into commercial InterBase. Alternatively, move to Firebird and do your future development with IB Objects (which will directly convert your BDE app, a sub-five-minute job) or FIB-Plus.

>> That said, your analysis is enough to tell me what happened - with
>> a 90% probability. You're running on a windows operating system and
>> you're using different connect strings for different clients. That
>> causes InterBase V4, V5, & V6 to attach the database once for each
>> connect string, breaking the lowest level of concurrency control -
>> the part that maintains the on-disk consistency.
>
>After discussing more with our support people, I've found that we are
>definitely doing this.
>All of the "remote"/"client" workstations (IE machines that the
>server is not on) are using the same connect string (As set by our
>installer, which does do a proper connect string, ie
>SERVERNAME:c:\data\database.gdb).
>However, the machine that the server does reside on, the connect
>string is just c:\data\database.gdb... No SERVERNAME, etc. This has
>been remedied this morning in our install program, so that the server
>machine's connect string for our application is exactly the same as
>the client's connect string.

A local connect on the server won't be the source of your corruption; and the change you have done won't fix it. The bad path bug is not caused by mixing a local connection with remote connections, it's caused by the anomalous strings as already described to you by Ann and me.

It's probably insufficient just to ask your support people. You need to go to the users who reported the problems and find out who is using IBConsole, DBExplorer, Database Desktop, etc. to make ad hoc connections to their databases using the bad string. Look at everyone's BDE setup individually, too. It just takes one.

>Solution 1 is something we'll be discussing. However, our concern is
>when Interbase and Firebird diverge enough that components to access
>one won't work to access the other (Specifically Interbase Express).
>If there are going to be IBX components to do the same job, with at
>least the same performace, then we're fine.

Your options are: Borland InterBase commercial editions + IBX (or, better, IBO or FIB-Plus)

or

Firebird + IBO or FIBPlus.

Don't count on IBX keeping up with Firebird.

(Or you could, of course, just stick with poor old untested IB Open Edition 6.0.0.0.0.0.0.1.6 for ever more and spend weeks converting your BDE app to IBX...)

HB


All for Open and Open for All
Firebird Open SQL Database · http://firebirdsql.org
_______________________________________________________