Yes, when you were reporting this error originally you said that you were getting ready to move to SP1 and you seemed to be saying that you thought SP1 fixed the 2065 error, however I could not find anything about it in the fix list for SP1. Additionally, I believe that Randy Jean reported just the opposite problem. He found the error did not occur in VFP 9, but did occur in VFP 9 SP1.

>>Earlier in this thread and in another thread you reported this error:
>>
>>2065
>>Table "C:\DOCUME~1\swill001\LOCALS~1\Temp\00003IMX00J7.TMP" has a file length / record count inconsistency. The table will need to be repaired before transactions can be committed properly.
>>C:\DOCUME~1\swill001\LOCALS~1\Temp\00003IMX00J7.TMP
>>
>>You seemed to be saying that you thought the 2065 error was fixed in VFP 9 SP1, however I have looked over the fix list for SP1 and see nothing related to the 2065 error. I am wondering about your results in squashing this error.
>>
>We're not getting this error anymore. I don't remember what did we do exactly. AFAIK, my colleague switched to view and we also upgraded to SP1 at the same time.
>
>>Also, in relation to the "Cannot insert an empty row from a view or CursorAdapter into its base table(s)" error that you reported, I find that this is a corrupted view. Specifically, if you run GenDBC, you will most likely see that the tables that are set to be updateable for the view in question contain a table that should not be there. For instance, if you have a simple two table view and one table is going to be updated and one is included because you're pulling some data from it, then the table list should only contain the first table. The second table will not be there, but sometimes VFP fouls it up and it includes the second table in the list. Remove the second table from the list and the problem should go away.
>>
>I'm not using views in the form, where the error occurs. I'm only using CAs. I believe all my CA, where I update data, are based on a single table. I'll verify this tomorrow.