Ben - Thanks for the input, however the R:Base database shares data with a SQL Server database, which uses globally unique GUIDS (36 character text strings). But, Alastair Burr made a noteworthy comment in that his corruption is preceded by a crash from a multi-row form. All of the areas that we have been hit in are areas in which the data is manipulated on a form with tiers as well. Our users are pretty used to frequent crashes, so they tend not to let us know every time it happens, but it very well may be the case that a crash is occuring, and maybe somehow responsible for, the corruption.
Again though, I hate to consider workarounds when dealing with the core functionality of a product. Workarounds allow for an elevated number of points of failure, and when it comes to a customer's data, loss can be highly costly! Thanks for the feedback. William Mason ----- Original Message ----- From: "Ben Petersen" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Wednesday, August 21, 2002 5:07 AM Subject: Re: Corrupt Indexes > 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/ > ================================================ 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/
