>>>>>>
>>>>>>Are you really sure about the number 9051840 as a representation of {^2005-03-18}?
>>>>>
>>>>>Well it all displays ok when i run your code.
>>>>>
>>>>>Yes, i am sure about the representation for that date with the number 9051840 ( the string to be exact ).
>>>>
>>>>Can you give a few other paired examples of this discrepancy between SQL dates and their VFP values?
>>>
>>>
>>>9286560 --> 28/8/2005
>>>9329760 --> 27/9/2005
>>>9280800 --> 24/8/2005
>>>9324000 --> 23/9/2005
>>
>>Now that i put them all together i see those numbers represent minutes.
>>From 23 to 27 september, that's 4 days represented by 5760, that's 1440 / day, then number of minutes per day
>
>Exactly, and they all represent an offset from {^1988-01-01}. They are not dates, in the sense of an MSSQL date.

I thought in the beginning SQL Server saves the dates in their new DATE type field as some type of julian date or unix date, but while trying to conver those it gave me wrong results.
The way it is now it's not workable.

I did a dump of the 'table create' in sql i get something like

CREATE TABLE CPROF '‎Prop‎' 1
‎PROF (INT,13,'(ID) ‎Prop ID')
‎CPROFNUM (CHAR,16,'‎Prof Num‎')
‎CUST (INT,13,'(ID) ‎Customer ID')
‎PDATE (DATE,8,'‎Prop Date')
‎USER (INT,13,'(ID) User‎')
‎UDATE (DATE,14,'‎Sign Date‎')