Hi Lutz,
Odd indeed! The basic thing is, when a CA object is referenced "directly" ( oInvoice.oInvoiceHeader ), it will always return Date. Also, if I create a variable like so:
oInvHdr = oInvoice.oInvoiceHeader
it will also return Date.
But, if I create a variable oInvHdr returned from the following method GetCursorObject(), like so:
oInvHdr = oInvoice.GetCursorObject( "InvoiceHeader" )
Evaluating Date will return a DateTime value!
Here is the code of GetCursorObject():
LPARAMETERS tcAlias
LOCAL loCursor, loCursorObject
FOR EACH loCursor IN This.oCursors
IF UPPER( loCursor.Alias ) == UPPER( tcAlias )
loCursorObject = loCursor
EXIT
ENDIF
ENDFOR
RELEASE loCursor
RETURN loCursorObject
Regards,
Dennis
>Hi Dennis,
>
>And you can not see where the type changes? This is odd.
>
>>Hi Lutz,
>>
>>Yes, I have traced all my objects to their classes and class locations.
>>
>>Regards,
>>
>>
>>>Hi Dennis
>>>>So far, I have no problems naming fields, vars like a built-in function.
>>>
>>>This happens in some odd moments and you will lost nerves figuring it out. Because of that, the general tip.
>>>
>>>>> #2 GetCursorObject and GetFieldValue are not VFP native, this looks like some framework. So it's somewhere in the code of this framework. Even the whole idea to
>>>>> handle data through objects looks strange from a VFP POV.
>>>>
>>>>You are right. Those methods are part of my framework. It simply loops thru the collection of Cursors and returns an object reference of the CA with the specified Alias, which I have been doing for the longest time. I just wonder why the field value returned was DateTime instead of Date. Both Cursorschema property and the actual MySQL table are dates.
>>>
>>>Have you checked the actual CursorSchema? Possibly some inheritance or oddly referenced class, so that you catch something you don't expect? Sometimes a class is gathered from an unexpected folder. Just like this. Single step through opening the cursor. Check THIS.CLASS and THIS.CLASSLIB while doing so.