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/
