1. It seems to me that "as little code changes as possible" (as I wrote) is not equal "no changes" as you translated part of my sentence.
I simply did not what to look for commands like IFF( EMPTY(orderdate),..,..) that return opposite values in case of using NULL and empty date. I did not what to change an retest many places of my applications ? I prefer to make changes in two places (while reading and saving data)
2. My applications are accouting type - surely not historical or human resorces - trust me, in case of my application user NEVER enters date that equals "1900-01-01" . For me VFP lacks such commands as SET TREAT_19000101_EXACTLY_AS_EMPTYDATE ON or SET AUTOCONEVERT_NULL_TO_EMPTYDATE ON. Such commands or similar cursoradapter properties would save time of many people IMHO.
3. Your example with an user that wants create CR report is very good. But still reasonable seems to be a solution that converts empty dates to NULL dates before savig data into SQLServer database(SET AUTOCONEVERT__EMPTYDATE_TO_NULL ON)
4. The way with using NULL on both sides seems (also to me) the best way to go today. But it is still just one of possible solutions. In this thread I am looking for other ideas how can it be done, and also in such way, I want to say that VFP should more suport developers in such common to many people task (maybe someone from MS is watching).

Thanks Wayne I appreciate your input

>You are saying that you don't want to make any code changes, yet you will have to make changes to see if the value is 1900-01-01.
>
>Some questions to ponder... What happens when you really have a valid date for something that is 1900-01-01? What happens when someone wants access to the data - say to report in crystal, or export to excel, or whatever? Then you will have to either 1) try and explain the date, or 2) always do the reports/exports/etc yourself and remove them.
>
>You will save yourself a lot of trouble by doing it right and making the dates null.
>
>
>
>>Thanks Wayne !
>>The lack of empty date concept in SQLServer, is what I've mean writing about incompatibility. I try to find solution that I will can use also in my other appllications when I decide to port databases from VFP DBC to SQLServer. The solution has to require as little code changes as possible. My existing VFP databases has NOT NULL date type fields. It seems to me that entering NULL date values will call for code changes in many places and it is the reason why I'm looking for another solutions. I can replace field with "1900-01-01" values or NULL values with empty date after filling cursoradapter and I am looking for solution that let me to do it in possible best/quick way.
>>
>>>It's not that they are incompatible, it's just that SQL Server has no concept of what an empty date is. You should make the tables accept nulls and program accordingly.
>>>
>>>
>>>>I have an almost completed application that uses SQLServer to store data and VFP8 cursoradapters to edit the data. I solved all problems with one exception - VFP and SQL Server date/datetime data types incompatibility.
>>>>VFP empty dates are converted to "1900-01-01" values while saving. When I refresh the cursor user can see "1900-01-01".
>>>>I can use NULL values on both sides (VFP and SQLServer) but it leads to additional more complicated VFP code ( ISNULL, NVL() etc... inside forms and reports methods).
>>>>For me the best way would be to convert SQL Server "1900-01-01" and NULL values to empty VFP dates and vice versa but I can find the good idea how to make it happen without hurting application performance and without writing too much additional code. All ideas are welcome.