Somewhere I have some sample data with some subtle corruption issues in the header. This was back in the VFP6 days and we bundled it up and reported to MS as a bug because TABLEUPDATE with row buffering inside a transaction would return .t. but records were not actually being added to the underlying table! Of course, the big issue was that we had a situation where many rows of data were not getting into the table without the user realizing it; sometimes until well after the event.
I just dug up that table (yes I was able to find a 10+year old bug report!) and tried to open it with the default TABLEVALIDATE and VFP stopped me. So I guess that at least in some way, TABLEVALIDATE was the MS response to our bug report and we are responsible for the addition of that feature to the product! BTW here's the results of attempting to use this bad table. As you can see, any setting other than 1 or 3 will allow the table to be USED: 0 - "No problem! You can open your corrupted table." 1- "Danger, Will Robinson! Danger!" 2 - "No problem! You can open your corrupted table." 3 - "Danger, Will Robinson! Danger!" 4 - "No problem! You can open your corrupted table." 8 - "No problem! You can open your corrupted table." Really, that's what the dialogs say... <vbg> -- rk -----Original Message----- From: [email protected] [mailto:[email protected]] On Behalf Of Dave Crozier Sent: Friday, March 16, 2012 9:06 AM To: [email protected] Subject: RE: 2 versions sharing same databases, one says it's corrupt, the other fine Richard, No problem on disagreeing really! My comments are purely based upon the experiences I had when VFP9 first came out and they may well be different now, many years down the line. I found that the other network users were locked out of adding records into the "validatad table" to such an extent that they actually lost the connection on the network and timed out. Obviously that was in the days of 10Mb lans and 500Mhz processors and now we are all in the 1Gb and 3.5Gb processor world with 100Gb+ looming quickly which may in fact have changed the game somewhat. So, I bow to your experience but my systems here (150+ users) don't have any tablevalidate setting other than off and it works fine .... so as the axiom goes ..."if it ain't broke ... don't fix it". Funny isn't it how old experiences sometimes cloud your judgement and lead to "repeat behaviour" ... maybe we are all a little too stuck in our ways! Tell you what, I'll give it a limited try on the next software release! Dave -----Original Message----- From: [email protected] [mailto:[email protected]] On Behalf Of Richard Kaye Sent: 16 March 2012 12:54 To: [email protected] Subject: RE: 2 versions sharing same databases, one says it's corrupt, the other fine Hi Dave, I think this may be a first for me as I'm going to respectfully disagree :) with something you wrote; specifically the "it makes multi-user applications completely unworkable " comment. My applications are all deployed in VFP9 only for years now and I've left tablevalidate set to its default value (3). Periodically I get a support request about a corrupted table and it gets fixed in a timely way. I've had way more data corruption issues thanks to MS SMB/SMB2/OpLocks fun than any pain I can attribute to TABLEVALIDATE. -- rk -----Original Message----- From: [email protected] [mailto:[email protected]] On Behalf Of Dave Crozier Sent: Friday, March 16, 2012 6:03 AM To: [email protected] Subject: RE: 2 versions sharing same databases, one says it's corrupt, the other fine As Richard says, there SHOULD be no reason to run it and I do set it off in all my apps as it makes multi-user applications completely unworkable. However, if you are getting DBF corruption then you need to find out exactly why and how it is happening. Dave [excessive quoting removed by server] _______________________________________________ Post Messages to: [email protected] Subscription Maintenance: http://leafe.com/mailman/listinfo/profox OT-free version of this list: http://leafe.com/mailman/listinfo/profoxtech Searchable Archive: http://leafe.com/archives/search/profox This message: http://leafe.com/archives/byMID/profox/DF1EEF11E586A64FB54A97F22A8BD0441D50E3A3F0@ACKBWDDQH1.artfact.local ** All postings, unless explicitly stated otherwise, are the opinions of the author, and do not constitute legal or medical advice. This statement is added to the messages for those lawyers who are too stupid to see the obvious.
