Was the workaround recommended by MS or did you figure it out yourself?

Microsoft figured out part of the workaround of adding the integer dummy field, but it also required the character field first. It is not corrected in service pack 5 since it still occurs today with this pack installed. The below solution was not entirely correct:

CASE_ID_NUM: SRX010112603439
MESSAGE:
********************** The message for you follows ************************
Hi Mark,
It was my pleasure to work with you on your Visual FoxPro 6 issue. I am providing you with a summary of the problem and the solution. I went back a looked at the information that I found concerning your problem and the bug that was entered for this was fixed in service pack 3. The notes in the case state that you are using sp3, so going to the latest service pack shouldn't help the problem.

PROBLEM:
Corruption in the primary key field.

SOLUTION:
Add a dummy integer field to the beginning of the table.

Based on our last conversation, it appears that this case is ready to be closed. If this is pre-mature or you are not very satisfied with all aspects of this case, please let me know as soon as possible. Otherwise, I will close this case at the close of business on Friday March 9th. Thank you for choosing Microsoft.

Thanks and have a great day,
Mark Barnard
MS Developer Support
MS Certified Systems Engineer + Internet
mbarnard@microsoft.com
704.423.6486
Hours: 9 AM - 6 PM EST


CASE_ID_NUM: SRX010112603439
MESSAGE:
********************** The message for you follows ************************
Hi Mark,
I have done more research into your problem. There was one other case that I have found so far with what appears to be the same problem. The main OS used in this case was Windows 95 OSR. According to the notes in the case you are using NT 4. Are any of the client machines Windows 95? There was a bug entered for this and it was fixed in Visusal Studio sp 3 which, according the notes, you are using. Service pack 5 was just released to our web site. I would install this just to make sure you have the latest fixes. It can be downloaded from http://mshn.microsoft.com/vstudio. The fix for the case I found was to add an extra dummy field to the beginning of the table. It was an integer field that was added to the tables with the problem. The dummy field needs to be the first field in the table. It seems that a CHR(26) was getting into the field along with the normal data. They were seeing a pattern to the id's that were being added to the table. It was similar to 26+(n*256). I am not sure what n is. Adding a dummy field caused the CHR(26) to end up in there instead of a field that is needed.

Here is a link to the VFP article that talks about the fix.
http://support.microsoft.com/support/kb/articles/q221/6/24.asp

There was also a fix for the redirector in Windows 95 OSR 2 and 2.1. Of course this won't apply if you are only using NT 4.
http://support.microsoft.com/support/kb/articles/q174/3/71.asp

If you can give this a try. I will give you a call tomorrow to discuss this.
Mark Barnard
MS Developer Support
MS Certified Systems Engineer + Internet
mbarnard@microsoft.com
704.423.6486
Hours: 9 AM - 6 PM EST


Am I correct in interpreting that the workaround consists of a total of two new (and unused) fields, one character and one integer?

Yes.

Do they appear at the beginning of the record, or anywhere as long as it's before the primary key?

As long as they are before the primary key.


In what order do you put those workaround fields? Is the char. field field#1 or is the integer field field#1.

Character field#1, integer field#2.

What length is used for the char. field?

Character field was 10 in length.

Does this happen outside of BEGIN/END TRANSACTION only, or only within TRANSACTIONs, or either way?

Either way.

Do you have any idea as to whether the "dummy" fields could actually be legitimate data but non-key fields?

I was not putting any data in real data in these dummy fields. They were non-key fields.