Steve, I fully concur with your "due diligence".
In the early stages of developing the database for the NZ Police we had broken pointers coming out of our ears (version 4.5). Since we have been using version 6.5 we haven't had any problems, except when we do a major job and the building manager decides to run a power-off / generator test. R:Scope; We have it, but we never use it. I find it a bit dangerous fiddling directly with the data. There is limited control over what you are doing and there are no audit trails. I would always be concerned about the integrity of the database if I had to fix it with these kind of utilities. What do we do: We have a very strong backup regime in place. If autochck indicates a problem we immediately reload and check the recordnumbers and totals against our documentation. If that doesn't fix the problem, we copy the last backup in. We have a very strong change management regime in place. We have a production, backup of the production, pre-production and development system online. In addition this we do the daily tape backups. We learned the hard way. So, having the technology is one thing, but you must also have good IT governance processes in place if you want to run a successful operation. ;) Frank -----Original Message----- From: J. Stephen Wills [mailto:[EMAIL PROTECTED] Sent: Thursday, 18 September 2003 08:40 To: [EMAIL PROTECTED] Subject: [RBASE-L] - Re: Note Fields - Razzak's Reply Steve, have you ever used R:Scope in the past? I ask because I didn't really understand the role of "pointers" or the impact of broken ones until I had need to use it, ca. 1988(?). Pointers are, as far as I know, ABSOLUTELY VITAL, f/the internal maintenance of the data in the tables of a DBMS, and that means any DBMS. However, and please don't hold it against me, I won't go into any more detail at the moment, as I'm sure my effort would be unworthy of the topic. However, I'd be happy to find some relevant and reliable info on-line and send the URL's to you. Additionally, let me add, the only time I recall having had broken pointers was when the system that was "hosting" a PACK/RELOAD/INSERT/ETC operation was powered off before the operation was complete ; I'm sure there are other scenarios wherein this can happen, as well. However, it seems to be rather a rare thing, w/for the most part, known causes. Moreover, having a good and enforced policy and process f/backups/archives mitigates the impact of such a failure. So, I wouldn't worry (much) about broken pointers, I'd recommend that you just analyze, design, and implement as you think is appropriate and around that do all your "due diligence" stuff, like backing up ... Later, Steve in Memphis ----- Original Message ----- From: "Fogelson, Steve" <[EMAIL PROTECTED]> To: "RBASE-L Mailing List" <[EMAIL PROTECTED]> Sent: Wednesday, September 17, 2003 3:26 PM Subject: [RBASE-L] - Re: Note Fields - Razzak's Reply > Thanks again for the responses. > > After reading Razzak's articles, I have come to the conclusion that by > designing the DB structure with Note tables for each table that need note > fields: > > 1) That the "Note table" doesn't really need previous and next pointers > (even though it normally does have them) as this table is only referenced by > the primary key from the parent table. > > 2) We would probably not even notice that there was a broken pointer in a > "Note table". Would Autochk pick this up? > > I still am not sure if R:Scope would fix a broken pointer in a "Note Table". > > Thanks > > Steve > > -----Original Message----- > From: A. Razzak Memon [mailto:[EMAIL PROTECTED] > Sent: Wednesday, September 17, 2003 1:54 PM > To: [EMAIL PROTECTED] > Subject: [RBASE-L] - Re: Note Fields - Razzak's Reply > > > > At 11:09 AM 9/17/2003 -0500, Steve Fogelson wrote: > > >A while back I had asked about Text vs. Note fields. > > > >A few responses indicated that they keep all "note"s in a separate table. > >Evidently problems with broken pointers. > > > >I assume you design your DBs with a table for ALL notes. And all the other > >tables contain Note_ID fields where appropriate, that point to that note in > >the note table. Then use a view to read a row including the note. > > > >Are these assumptions correct? > > > >Could someone elaborate on this design and problems with broken pointers. > >How is this design strategy easier to fix broken pointers? > > > Steve, > > Take a look at the following two articles: > > From The Edge: http://www.razzak.com/fte > > Understanding and Using VARCHAR Data Type (07/18/2002) > > Finding and Fixing Broken Indexes (04/30/2002) > > Hope that helps! > > Very Best R:egards, > > Razzak. > ____________________________________________________________________ CAUTION - This message may contain privileged and confidential information intended only for the use of the addressee named above. If you are not the intended recipient of this message you are hereby notified that any use, dissemination, distribution or reproduction of this message is prohibited. If you have received this message in error please notify Air New Zealand immediately. Any views expressed in this message are those of the individual sender and may not necessarily reflect the views of Air New Zealand. _____________________________________________________________________ For more information on the Air New Zealand Group, visit us online at http://www.airnewzealand.com _____________________________________________________________________
