FireDAC Date Handling – FireDAC Date Mystery Part II
As it turns out, the mystery was not fully solved.
After adding map rules (see old post) to FireDAC for how to handle dtTime and dtDate, I removed the old ADO special case handling and just did
Result := FieldByName(FieldName).AsDateTime;
Which worked well – or – so I thought. I had done all my testing on machines that had the SQL Server Native Client installed, and it showed no problems.
But – when I ran on a machine without SQLNCLI installed, the date format issue reared it’s ugly head again.
So – this is the “final” workaround which so far appears to handle every date/time format that I have tossed at it.
function TPSDRecordset.GetAsDateTime(const FieldName: string): TDateTime;
F := FieldByName(FieldName);
case F.DataType of
ftDateTime: Result := F.AsDateTime;
ftTime: Result := StrToTime(F.AsString);
ftDate: Result := StrToDate(F.AsString);
OutputDebugString(‘GetAsDateTime(‘+FieldName+’).DataType=’ + IntToStr(Ord(F.DataType)));
Result := StrToDateTime(F.AsString);
s := FieldByName(FieldName).AsString;
OutputDebugString(Self.ClassName + ‘.GetAsDateTime(‘ + FieldName + ‘) = ‘ + s + ‘: ‘ + E.ClassName +’ – ‘ + E.Message);
#FireDAC #SQLServer #NativeClient
Originally shared by Lars Fosdal
A FireDAC Date Mystery
I have an app that connects to a MSSQL db through FireDAC and retrives a selection of log data, including the date and time of the logging in a datetime field.
I leave the app open for a longer period of time (about an hour, I think), then I refresh the view.
BAM! The dates show up as 1899. For some reason, FireDAC has decided to forget how to get the datetime in the right format.
I suspect that is is related to a connection object that has lost it’s connection, but why can it reconnect and get data, and yet get the date format wrong?
You must be logged in to post a comment.