I think there's something in this.

Historically InterBase has used the "complete path name on the server
machine" to uniquely identify a database. This key is used in the
lock manager, etc. The "complete path name" could be embedded into
the header, and then any attachment trying to use a different path
would bomb out.

There must be a way of resetting the path in the header (server dies,
move disk drive to another machine, but has new path) - which could be
done with a isc_dpb block.

The problem, in the past, arose on window* platforms, as there was no
reliable way to determine a unique path to a given file. Of course,
there may be such a way now, or in the future.

Dave

> -----Original Message-----
> From: Randal Carpenter [mailto:wade@...]
> Sent: Friday, January 28, 2000 11:51 PM
> To: interbase@...; IBDI@onelist.com
> Cc: INTERBASE@...
> Subject: [IBDI] Re: Any ideas about what is causing this database
> corruption
>
>
> From: Randal Carpenter <wade@...>
>
>
> I don't like this...we must fix
>
> OK here is a failsafe idea what we to to 6.0. We make it
> create a random
> 32 or 64bit number (probably generated by 32 bit
> timedate+32bit random) to
> indentify each rebuild of any database. That is something to
> make every
> file named bob.gdb most likely unique. As in when I create a
> new database
> or gbak and restore, I get a new 64 bit id in the new database.
>
> Now when the server opens a file, it checks for same ID open,
> and if same
> ID is present already then look at the pathless filename to
> confirm that
> it is indeed the same file being requested. I know the file
> check part is
> practically redundant, but should be there in case ID = 0 for both

...

> (which should be the case if no ID is found for backward
> compatibility,
> for instance if I open on old gdb with an older on disk
> structure). By the
> way, in the case of the ID returning 0, it should use full
> path for the
> second comparison as apposed to just the pathless filename
> check...see I
> thought about that.
>
> Now you can drink beer and type in bad paths while you code
> like mother
> nature intended, or simple wake up in a different world and do human
> things like vary the path. Of course if ID is 0, you are using an

old

> disk structure and its your own fault you did not gbak it and
> are still
> subject to path variations :).
>
>
> Randal
>
> On Fri, 28 Jan 2000, Chris O'Rourke wrote:
>
> > It is unfortunate that I did not push this topic back in
> July 1999. I sent
> > my humble description and a test application that could
> reproduce anomalies,
> > off list, to an Inprise rep (who shall remain nameless).
> Probably too busy
> > to progress a solution or did not fully understand the
> implications of this
> > problem. For whatever reason no progress has been made.
> > For that I apologise to the list and the Interbase user community.
> > I just don't have the luxury of investigating solutions for
> a third party
> > product and that is why I passed it over to Inprise (At
> least I thought I
> > had). As far as our clients were concerned the corruption
> problem was
> > resolved. (No further corruptions since enforcing
> consistent connection path
> > names via the application).
> >
> > This bug lays dormant until it "slashes out" at
> unsuspecting sites who quite
> > innocently introduce a different database path name
> connection into their
> > environment.
> > This still may not be the cause of Chris Herble's database
> corruption at the
> > start of this list entry but certainly is worth at least a
> FORMAL reply from
> > Inprise on the topic or a bug report entry on the Inprise web

site.

> >
> > Summary of information (as I know it):
> > 1. the corruption problem did not exist in V4.2 Interbase
> > (the mixed path names were already in use, for two years,
> on the clients
> > site prior to upgrading from V4.2 to V5.1)
> >
> > 2. Problem is associated with
> > a) servers resolution of REMOTE access as two local
> connections to the same
> > database using different connection strings, eg. "D:\Testdb.gdb"

and

> > "D:Testdb.gdb" will not have problems. b) Moreover the
> problem does not
> > occur with the following connect strings: "MYPC:D:\Testdb.gdb" and
> > "D:Testdb.gdb". As soon as a host name is included on
> "D:Testdb.gdb" as in
> > "MYPC:D:Testdb.gdb" then anomalies will result (Regardless
> of whether the
> > connection is actually local or not, ie. "MYPC" is the same
> host as the
> > server to which you are connecting.)
> > c) a drive other than "C:" (system disk) must be used. ie.
> "C:Testdb.gdb"
> > will fail as a connection string; you are forced to use
> "C:\Testdb.gdb" and
> > therefore no problems can result.
> > So my apologies to Chris as it is more then the missing '\' that

is

> > important in this recipe for disaster.
> >
> > Chris wrote:
> > >>There are 2 possible solutions to this bug;
> >
> > >>1) Ibserver should reject connection strings of the form
> "d:test.gdb" as
> > >>ambiguous.
> >
> > >>2) Ibserver should resolve "d:\test.gdb" == "d:test.gdb",
> and carry on
> > with
> > >>a single database connection.
> >
> > 1) V5.6 appears to already reject "c:test.gdb" as a
> connection path so
> > perhaps the fix is easier than we could hope for.
> > 2) If the server is trying to match database paths for my
> mind this is
> > unnecessary.
> > A suggested solution:
> > a) On connecting the first session for the first database
> the server would
> > (after determining it is a valid database) write a unique
> number (perhaps a
> > GUID) into the database header and keep a list of these
> GUIDs internally.
> > b) subsequent connections would first attempt a read of the
> database on the
> > supplied path and read the GUID from the header. Given the
> file exists and
> > the read was successful then:
> > c) if the GUID is not in the current list then must be a
> new database and a
> > new GUID is written to the database header for this new database
> > - if a match is found then the database has already been
> attached and so
> > request is for the matched database. (this should work
> since an attached
> > database is accessed exclusively by the server)
> > d) when a database is released (last connection is freed)
> then the GUID is
> > dropped from the internal list. This list is also memory
> resident so a crash
> > (heaven forbid) or reboot/restart of server would rebuild
> the list the next
> > time connection requests are made. The GUID in each
> database header serves
> > no purpose other then to keep track of CURRENT attached databases.
> > Obviously an extra read of the database file header is
> required for each
> > connection which is an overhead if the database is already
> attached but one
> > extra I/O is a small price compared to corruption. If
> mechanisms such as
> > "KeepConnection=True" are not used then this may add to the
> applications
> > overall speed.
> >
> >
> >
> > >>Instead, we'll have to live with IB5.6 for the time being
> - and hope that
> > >>nobody makes a simple typing error when setting up a
> CLIENT workstation,
> > or
> > >>the database could be lost again.
> >
> > Rejecting connection strings by your application is the
> safest for the
> > moment or move the DB to "C:" system disk but not recommended

since

> > speed/disk space will become an issue.
> >
> > Regards,
> > Chris O'Rourke
> >
> >
> >
> >
> **************************************************************
> **********
> > * This message came from the list servers at
> http://www.mers.com *
> > * To remove yourself from the list: send an email to
> listproc@... *
> > * in the body of the message put: unsubscribe INTERBASE
> *
> > * InterBase Search Engine
> http://www.mers.com/searchsite.html *
> > * InterBase FAQ http://www.mers.com/faqinterbase.html
> *
> >
> **************************************************************
> **********
> >
>
>
>
>
> --------------------------- ONElist Sponsor
> ----------------------------
>
> GET A NEXTCARD VISA, in 30 seconds. Get rates as low as 0.0 percent
> Intro APR and no hidden fees. Apply NOW.
> <a href=" http://clickme.onelist.com/ad/NextcardCreativeCL
> ">Click Here</a>
>
> --------------------------------------------------------------
> ----------
>
> Community email addresses:
> Post message: IBDI@onelist.com
> Subscribe: IBDI-subscribe@onelist.com
> Unsubscribe: IBDI-unsubscribe@onelist.com
> List owner: IBDI-owner@onelist.com
>
> Shortcut URL to this page:
> http://www.onelist.com/community/IBDI
>
>

[This message contained attachments]