William, >From what I gather, this problem seems limited to text indexes. Maybe switching to integer indexes would be the lesser of evils until there a acceptable resolution. I began using them after suggestions from others on the list.
Maybe others would add to this, but his is what I do. All tables have an autonum column, except tables that are the "parent" in parent-child relationships. I typically name these columns tblSerial, and serve no purpose other than to identify individual rows as needed. In parent/child relationships (people/phone#s, check headers/check detail...) each have one common column, typically TranID, assigned at insert. I never give my users access to the R> so I don't use foreign keys and manage those relationships through code. So, using GL accounts as an example, if you wanted to query transactions by acct#, the first step is to "choose" the account which may have any size gl Acct# (text) and use the integer returned to query the transaction table(s) for that indexed integer. I doubt this is news to you... but somtimes an old idea triggers a new thought. Ben Petersen On 21 Aug 2002, at 9:50, William Mason wrote: > I'm not buying into the hardware thing. I MAY if the removal of FK's didn't > fix it (in my case) every time. Anyway, from a time/cost point of view it > is more effective to deal with the lone piece of software that is having > trouble than to check every driver and/or NIC and/or hardware component of > every workstation on a LAN. And what a thought - a printer driver could > bring a company to its knees. We operate in "mission critical" mode at > times and I for one do not like to sit and bite my nails waiting for the one > bad NIC card or rogue printer driver or loose patch cable or dusty keyboard > on one PC to trash a corporate database, stop 20 other users from working > and cost us (literally) THOUSANDS of dollars per hour. > > I can understand the frustration from both the developer and RBTI points of > view. It is an extremely difficult situation to replicate, and therefore > fix. As a developer, our apps appear fragile and/or bug-ridden, in turn > lowering the confidence in those that use (and pay for) our apps. We > address the issue with RBTI but cannot replicate the problem so they have > their hands tied. And ultimately we all end up in the conundrum of blame > without resolution (how many times has a software vendor said the problem > was with Windows and Microsoft said it was with the vendor's application?). > > However, in my opinion, something has to be done. Databases are all about > DATA, and losing data is simply not an option - having a weakness in a > "feature" is one thing, but having an Achilles heel in the core > functionality is another (what if Excel did math wrong if some other user's > CD ROM driver was bad?). Treating the symptoms and not the disease is a > shortsighted answer that only provides a temporary and false sense of > security. I can't run a RELOAD every minute of the day and I can't tell a > business to stop functioning while I "fix a problem". I will continue to do > what I can to diagnose the problem and find the source of it, so that I may > one day share that information with this community and RBTI, who I am sure > would do their best to fix it. But, I would hope that RBTI would also > realize that this is a problem that is only occurring with their software > (to my knowledge) and that it is very costly to me and those that I serve, > both from a financial and confidence perspective. And without that > confidence, those that control the purse strings may be more apt to consider > other products/developers for the reliability that they pay for. > > RBTI has always gone the extra mile, and I'm sure that this case is no > different. I would very much enjoy the continuance of this dialog, > hopefully with the input of both experienced developers and RBTI staff to > see if there is indeed a way to remedy the issue that is feasible from both > sides, yielding an even greater product. > > My $0.04 > > William Mason > > > > > > ----- Original Message ----- > From: "Anthony Schmidt" <[EMAIL PROTECTED]> > To: <[EMAIL PROTECTED]> > Sent: Wednesday, August 21, 2002 7:52 AM > Subject: Re: Corrupt Indexes > > > > Bernie: > > > > The response I received from RBTI tech support was that the corruption > > (data and indexes) that my client was experiencing was related to network > > problems. > > > > It appears that they were right. > > > > Our problems seemed to be related to a bad printer driver on the Terminal > > Server. The bad printer driver would cause short and intermittent database > > disconnects. Since we deleted and reinstalled the printer driver > > (beginning of this July), we haven't experienced any data or index > > corruption. I'm not suggesting that your problem is due to a bad printer > > driver, but rather that it can be something totally unrelated to R:Base. > > > > I discovered that the RBase 6.5++ database is open for corruption not only > > during write operations, but also whenever an "Edit" or "Enter using" form > > merely accesses and displays data. I think this is due to the concurrency > > control that's part of these forms. > > > > This susceptibility to corruption due to network interruptions is > > something that seems that file server based databases are subject to. I > > think that client/server databases might be more forgiving since the > > connection can be established by and on the server. > > > > I also would think that the use of disconnected record sets would limit > > the exposure to such corruption. > > > > I hope that the RBTI dream team improves the "industrial strength" of > > R:Base to address these types of data and index corruption. > > > > My $.02 > > > > Tony > > > > Anthony Schmidt, JD > > President > > The Computery Ltd. > > One East Main Street > > Bay Shore, NY 11706 > > > > 631-665-8100 Voice > > 6310969-5988 Fax > > > > http://www.computeryltd.com > > > > > > > > > > > > > > [EMAIL PROTECTED] > > 08/21/2002 10:06 AM > > Please respond to rbase-l > > > > To: [EMAIL PROTECTED] > > cc: (bcc: Anthony Schmidt/BayShore/SGU_LN) > > Subject: Re: Corrupt Indexes > > > > > > David, > > Why do you feel that it is necessary to pack keys every day. Is this a > > signal that you suspect the "Industrial Strength" engine has a problem? > > I have one customer that has corruption repeatedly and I can't get to the > > bottom of it. I tried Pack Keys once and it didn't help. They are > > running > > dos and win 6.5++ 1.851 > > We've tried rotating the unuse (if there is such a word) of workstations > > to > > see if one of them is causing the problem. > > No positive results so far. > > > > Bernie Lis > > Megabytes, Inc. > > > > ----- Original Message ----- > > From: "David M. Blocker" <[EMAIL PROTECTED]> > > To: <[EMAIL PROTECTED]> > > Sent: Wednesday, August 21, 2002 9:07 AM > > Subject: Re: Corrupt Indexes > > > > > > > Because of the importance of indexes, the DAILY backup routine that I > > have > > > all my clients do does the following: > > > > > > SET MULTI OFF > > > CONNECT dbname > > > - abort if you can't connect > > > AUTOCHK dbname > > > - abort if problem > > > PACK KEYS (rebuilds all indexes) > > > COPY .... (backup) > > > > > > David Blocker > > > > > > ================================================ > > TO SEE MESSAGE POSTING GUIDELINES: > > Send a plain text email to [EMAIL PROTECTED] > > In the message body, put just two words: INTRO rbase-l > > ================================================ > > TO UNSUBSCRIBE: send a plain text email to [EMAIL PROTECTED] > > In the message body, put just two words: UNSUBSCRIBE rbase-l > > ================================================ > > TO SEARCH ARCHIVES: > > http://www.mail-archive.com/rbase-l%40sonetmail.com/ > > > > > > ================================================ > > TO SEE MESSAGE POSTING GUIDELINES: > > Send a plain text email to [EMAIL PROTECTED] > > In the message body, put just two words: INTRO rbase-l > > ================================================ > > TO UNSUBSCRIBE: send a plain text email to [EMAIL PROTECTED] > > In the message body, put just two words: UNSUBSCRIBE rbase-l > > ================================================ > > TO SEARCH ARCHIVES: > > http://www.mail-archive.com/rbase-l%40sonetmail.com/ > > > > ================================================ > TO SEE MESSAGE POSTING GUIDELINES: > Send a plain text email to [EMAIL PROTECTED] > In the message body, put just two words: INTRO rbase-l > ================================================ > TO UNSUBSCRIBE: send a plain text email to [EMAIL PROTECTED] > In the message body, put just two words: UNSUBSCRIBE rbase-l > ================================================ > TO SEARCH ARCHIVES: > http://www.mail-archive.com/rbase-l%40sonetmail.com/ > ================================================ TO SEE MESSAGE POSTING GUIDELINES: Send a plain text email to [EMAIL PROTECTED] In the message body, put just two words: INTRO rbase-l ================================================ TO UNSUBSCRIBE: send a plain text email to [EMAIL PROTECTED] In the message body, put just two words: UNSUBSCRIBE rbase-l ================================================ TO SEARCH ARCHIVES: http://www.mail-archive.com/rbase-l%40sonetmail.com/
