On Sat, 29 Jan 2000, David Schnepper wrote:

> From: "David Schnepper" <dave@...>
>
>
> 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.

That is why the ID is good. You see you can move the file, and it don't
make two cents difference if it even has same ID when you move it. The
key is when you start the server, the id will or wont match when you start
a new connection.

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