Hi!

As I suggested. I did not known about other solutions for this ODBC/ADO/other stuff problem. VFP dates are of some sort unique data type. This, as you see, cause a lot of changes. Now, imagine the feeling of developers that move something to SQL Server... ARRGGGGHHH!!!

>Unfortunately, I spoke too soon. I feel like my endusers re. "Honest, I didn't do anything. It was working before and now it's all blowedup." I moved on to ADO as advertised and recreated the remote connection to work with a nother test table (dbf). I was carefull not to let the system check the null box and I ran the view. Bang 12/30/1899 again. Sorry, about the bad "solution" thread.
>
>I then tried placing an IIF in a remote view SQL statement and to my dismay I have found that the remote view connection will not deal with a blank data in any form. ie IIF(EMPTY(datefield), {} or CTOD("") ...., datefield) always sends back 12/31/1899 on blanks. The only way I was able to make it work was to force it to a null date ie IIF(EMPTY(datefield), DTOD(.NULL.), datefield). This I find to be an unacceptable amount of typing.
>
>I have decided that I am going to let the bogus dates come over and translate them when I pass them to my local cursor.
>
>I am probably going to spend the rest of today bummed though :(
>
>Terry
>>Vlad
>>
>>I found it! I was fooling around in the ODBC Connection screen and saw a NULL check box. I unchecked it and all the dates work perfectly. Maybe the NULL date was being sent back as -1 and the code was therefore interpreting it as 12/31/1899 - 1 = 12/30/1899.
>>