> Perhaps, Windows protocols (SMB) against system file based ? Yes, this was our problem we had. We just disabled SMBv2 on Vista and 7 machines that were *hosting* the files.
Enable / Disable .msi files here: http://blogs.msdn.com/robmar/archive/2009/09/23/get-microsoft-fix-it-for-smb2-issue.aspx On Tue, Mar 9, 2010 at 8:09 AM, Antonio Martinez <[email protected]>wrote: > >From Advantage: > > >>>>>>>>>>>>>>> > Hi Corinna, > I probably don't have anything to mention that you have not thought about. > In addition to what John mentioned, some potential issues that I can think > of include the following: > > Bad hard drive (or possibly a bad hard drive controller): This could > result > in bad data being written or read incorrectly. This type of thing could > lead to "random" characters appearing in fields. This type of problem can > generally be detected by running various disk utilities. > > Bad memory: This normally would result in all kinds of flaky computer > behavior but could potentially hide itself and result in garbage being > written to a table. I don't think bad memory is a very common problem, but > we have experienced it in some of our test system computers on a few rare > occasions. Again, this can be checked pretty easily with system utilities. > Power outage: This could possibly result in data not being written to the > disk. In general, I would normally expect this to be a problem only with > indexes not being updated correctly. It does not seem likely to me that > random data could end up in a record because of a power outage (at least I > am not aware of any situations like this). The record simply would not be > written normally. Sometimes it is possible for an appended record to be > blank due to a power outage (the file is physically grown for the new > record > but the actual record never gets written), but this would normally have > zeros (probably appear as NULLs). > > Crashed application: I would think this normally would have results much > like a power outage; the data simply would not get written. With an > Advantage Local Server application, any client crash (or turned-off > computer) can result in problems. With Advantage Database Server, a > crashed > client application would not result in corrupt data. If Advantage crashes, > however, it could result in data not being written (and we would want to > know about any of these cases). > > Memory overwrites: And finally there is the "bugs in the code" case. Any > bugs in Advantage that would result in corrupt data are obviously a high > priority item for us to fix. But it is possible for bugs in a client > application to result in garbage data. A memory overwrite in the client > application could trash the record buffer before it is sent to the server. > The record could end up on disk with whatever data was in it from the > client. > Probably none of this is new/useful. However if you can send an example > table with to us ([email protected]), we can possibly determine what > might have happened. Error logs from the time of the problem would also be > extremely useful. > Mark Wilkins > Advantage R&D > "Corinna" <[email protected]> wrote in message > news:[email protected]... > >I would like to know what the various causes of table corruption (not > index > >corruption) are. I have a customer who has experienced corruption in a > >couple of tables over the last few months. Are there KB articles about > >this? I didn't have much luck searching. > > > > I know one cause is a power outage-- that happened once to them, then > they > > got a UPS. Is it possible for the UPS to not deliver enough voltage (or > > whatever), and cause data corruption even if it appears that the server > is > > working fine? > > > > Mostly what we've seen is hosed date fields, and random characters in > char > > fields. > > > > -Corinna > >>>>>>>>>>>>>>> > > Regards > > > > > > > > > > > > > > > > > Antonio Martinez escribió en mensaje ... > >Hi to all, > > > >a question: > > > >Why a .dbf table goes to corrupted ? > > > >Perhaps, break energy ? > >Perhaps, shutdown computer (user) ? > >Perhaps, Clipper and Harbour using the same dbf tables ? > >Perhaps, Windows protocols (SMB) against system file based ? > >Perhaps, ....? > > > > > > > >Regards > > > > > > > > > > > > _______________________________________________ > Harbour mailing list (attachment size limit: 40KB) > [email protected] > http://lists.harbour-project.org/mailman/listinfo/harbour > -- smu johnson <[email protected]>
_______________________________________________ Harbour mailing list (attachment size limit: 40KB) [email protected] http://lists.harbour-project.org/mailman/listinfo/harbour
