Time to go to bed. I totally missed a date in the year 209 (current era, I guess).

Thank you both for your ideas. You made me take a second look at the data and run a query not just for empty dates but for dates before 1900, which found the offending record (yes, the one where it stopped).

Have fun!

Alex

>>Hi everybody,
>>
>>Looks like it's crazy time here at the tas labs. SQL Server's version 8.00.2039 (SP4), in case you want to know.
>>
>>Here's a recap of what I'm doing and what's happening:
>>
>>I have a remote view (document_rv) that points to the Document table in my sql server database.
>>I truncate Document, then open document_rv.
>>I populate document_rv with 488,386 records.
>>
>>I issue a tableupdate(.t., .t.), which returns a value of .f. and the record pointer in document_rv is ALWAYS left at record No. 421,376.
>>
>>I look in sql server, and the document table appears with 421,375 records.
>>
>>Aerror() returns the following values:
>> 1526
>>Connectivity error: [Microsoft][ODBC SQL Server Driver]Datetime field overflow
>>[Microsoft][ODBC SQL Server Driver]Datetime field overflow
>>22008
>> 0
>>
>>Record No. 421,376 in document_rv has nothing wrong.
>
>But is there any wrong date on that record? VFP can store dates it can't display, specially in datetime fields, which can store dates far beyond year 9999, but VFP will error out on those. Maybe there's a limitation on the date fields SQL side? It could be a shortdate there (or whatever the new type is)... too bad ODBC won't say which field it was.
>
>You could run the SQL profiler and catch the exact command SQL server has received for that record, and see what's in it. One of the date fields has a value SQL doesn't like.