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.
>
It is impossible to make programs idiot proof. Idiots are too cleaver.
MCP( Tcp/Ip )