At 05:13 PM 07-08-01 -0700, you wrote:

> > You are right to be worried about it if your applications have not been built with a recent version of IB Objects or if multiple users have interactive access to your database through any tool that connects using any means other than those recent IBO components.
>
>So, why is it that IBO was able to fix it, but it seems so difficult to fix in IB?

Those working with the source code can explain it to you, or you can find it for yourself in the archives at news://news.atkin.com.

>Here's what I don't understand: Why doesn't IB simply open the physical file in exclusive mode? Wouldn't that prevent it from re-opening the file a second time, regardless of the connection path? Perhaps I'm not understanding something about Windows.

IB isn't a file-based database. Connecting to the database isn't a matter of "opening a file", it gives an authorised user access to the database file via the server. A Windows client can connect to a database on any supported platform via TCP/IP. Each OS platform has its own implementation of the access process. Some platforms (e.g. Windows) support connection protocols other than TCP/IP. The Windows OS expands and passes a connection string which it verifies as "OK for Windows". It just so happens that Windows can pass a connection string which is "not OK for the InterBase server". Therefore there is a bug in the connection code for Windows insofar as the server "expects" to get a valid path string from the OS.

> > You should check the BDE alias setup on every client installation and in every part of your application. If your BDE application lets users enter the path in the login dialog, then fix it so that they can only use an alias to connect.
>
>Since my application is installed by the users, I can't personally check every user's system. They do not use paths directly in my software. They all use BDE aliases. But, each client could have the BDE alias specified slightly different. Does that still present a problem?

Let's be clear that, if you instruct your users to follow the connection syntax recommended in the OpGuide, these problems won't occur. If you deploy your software in such a way that users can mess about with the connection syntax, you are deploying at risk.

>What about if some users specify the server by host name, and others by IP address, but the rest of the physical path is the same?
>
>Say, one client specifies it:
>
>myserver:C:\myprog\data\mydata.gdb
>
>and another one says:
>
>192.168.0.2:C:\myprog\data\mydata.gdb
>
>And the client running on the server machine simply has
>
>C:\myprog\data\mydata.gdb
>
>Would those be considered 3 different connection strings and cause problems? I'm sure that I have users doing exactly that, and I haven't seen any problems.

The absolute physical path to the database is the same - and valid - in all of these examples, so none of them contains the bad path string.

The matter of using an IP address (against recommendations) to identify the SERVER is a different question. It's not recommended and it is known to be unreliable. However, to date, I haven't heard of any cases where connecting via an IP address instead of a server name causes corruption. There is no obvious reason why it would cause anything but a delay in name resolution or, in some cases, an inability to connect to the server at all.

-- helen

All for Open and Open for All
InterBase Developer Initiative · http://www.interbase2000.org
_______________________________________________________