>I am trying to write a data conversion program that moves data from a large free table to three, better normalized tables in a VFP dbc. Originally, I wrote the program to convert data directly from the old tables to the new -- and that worked fine. But since the application we are writing will support both client server and VFP backends, I am trying to update the conversion program to use remote views and the VFP ODBC connection to the new tables.
>
>The destination tables are empty when the process begins. To speed up the testing, I limited the conversion to only the first 500 source records. And I got the thing to work just file. But when I populated the source data files with "Live" data (approx. 20,000 records), I get the error:
>
>Connectivity error:[Microsoft][ODBC Visual FoxPro Driver] Variable Q121P39 is not found.
>
>This happens on the last tableupdate command issued (the 2 other updates work fine). The table with the problems is the largest of the 3 (88 columns [fields] - 450 bytes per record). All the views mirror the destination table, the primary keys are set
>
>When I used opt. row buffering, I was able to see which source record the "automatic" tableupdate failed on. It always happens on record 637. There is nothing wrong with the record. If I delete it, it just fails on the next record. If I delete the first 10 records (that successfully updated), then the failure occurs 10 records further down the list -- always at record 637.
>

An update on this issue: I am still having the problem. I've sliced the tableupdate process in just about every possible configuration and I get the Variable Q121P39 is Not Found or the fatal C0000005 error message every way I have tried. I tried connecting the conversion program to a Sybase database backend and the program still crashes on the same table.

SO I decided to use one of my free MS technical support incidents to get this issue resolved. After a few hours of trying the MS VFP engineer's tweaks, and getting no results, he had me send the entire application (data and all) to him to see if he could reproduce the errors on his machine. He can, and has been working with it for a few days now and he can't get it to work either. He feels that his is very likely a VFP bug and will try to track what is causing the problem.

At first, he was a bit optimistic and thought he would have it resolved in a day. Now he is getting as frustrated as I was and will be turning it over to MS staff will a little deeper knowledge of the subject. My guess is that it may take a VFP patch to resolve it.

One other note: I was able to get the "merge" program to work for all three files if I deleted about 1/2 the data elements out of the problem table. It may be that the source of the trouble is the record size in the table I am using.

I'll let you know if I get a working solution on this one.