A FireDAC Date Mystery

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?

#FireDAC  

17 thoughts on “A FireDAC Date Mystery


  1. Yes.  The time part is correct, though.


    It’s like it has forgotten how to deal with the date value.  I suspect something related to ymd,dmy,mdy – but I can’t figure out where it happens.  I do not touch FormatSettings anywhere, and the code works when I use ADO, instead of FireDAC.

    Like


  2. Different databases may have different date formats, but I don’t know if the returned value is a binary or a string.  I suspect a string, though.  I worry that FireDAC reverts to some sort of default instead of fetching the db format.

    Like


  3. When converting ADO > FireDAC to MSSQL, I used  FormatOptions of connection   with FormatOptions do


      begin


        OwnMapRules := True;


        with MapRules.Add do


        begin


          SourceDataType := dtDateTimeStamp;


          TargetDataType := dtDateTime;


        end;


        with MapRules.Add do


        begin


          SourceDataType := dtTime;


          TargetDataType := dtDateTime;


        end;


        with MapRules.Add do


        begin


          SourceDataType := dtFmtBCD;


          TargetDataType := dtCurrency;


        end;


        with MapRules.Add do


        begin


          SourceDataType := dtBCD;


          TargetDataType := dtCurrency;


        end;


      end;

    Like


  4. Maybe when reconnect, Firedac create new Connection object without some parameters.  Maybe depends on how you handle    oConnection.OnRestored := mOnRestored;


     oConnection.OnRecover := mOnRecover;


     oConnection.OnLosted := mOnLosted;  Do you handle this specially, or you  leave for FireDAC?

    Like


  5. Lars Fosdal


    Rules remap some datatypes to another datatypes, some DBcomponents has problems with some date types – this was my problem, i don’t remember details. I do this on connection, so every dataset get this rules.

    Like


  6. Radek Červinka – I have adopted your approach, and it solved the problem.  In addition I could replace that ugly workaround with one line of code 🙂  


    Thank you so much for your input!


    It does look like there is some sort of state change issue with regards to reconnects in FireDAC though, but I’ll leave that to Dmitry to figure out.

    Like


  7. Lars Fosdal 🙂


    Please, share this information “…one line of code 🙂 ”


     😦


    One of my projects include simultaneously working with MSSQL and  with Firebird  database. I choose FireDAC for that but now I’m a little fidgety.

    Like

Leave a Reply

Please log in using one of these methods to post your comment:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

This site uses Akismet to reduce spam. Learn how your comment data is processed.