Record helpers can do wonders for code clarity.

Record helpers can do wonders for code clarity.

// Never mind the silly example

TResult = (CompletedOK, PartiallyPerformed, NothingHappened, HorriblyWrong);

function DoSomething:TResult;


Result := PartiallyPerformed;


How do we determine failure vs success?

if not DoSomething = CompletedOK then …?

What about Partially performed and nothing happened?

Enter the helper:

TResultHelper = record helper for TResult

function Failed:Boolean;

function Success:Boolean;


function TResultHelper.Failed: Boolean;


Result := (Self = HorriblyWrong);


function TResultHelper.Success:Boolean;


Result := not Failed;


Now we can write

if DoSomething.Failed then …

Note that you also can enter the murky waters of obfuscation through helpers, but at least the murkiness will be consistent ūüėõ

Reclaim that space!

Reclaim that space!

RAD Studio uninstall is not all inclusive, it seems. After uninstalling XE6 and XE8, the shared samples and kits still linger.


14.0 3Gb in 58k files (XE6 uninstalled)

15.0 3Gb 56k files (XE7.x Installed)

16.0 2Gb 51k files (XE8.x uninstalled)

17.0 2.8gb 60k files (10 Seattle installed)

So, that’s just above 5Gb reclaimed by removing the two dead directories.

Something safe for New Year’s Eve :)

Something safe for New Year’s Eve ūüôā

Jan Horn wrote this, December the 29th in 2001! Just add Variants to the uses clause in the .dpr file to get past the “NULL not found” error.

Someone should port this to FireMonkey ūüôā

Update: Upon trying to find Jan’s current whereabouts, I sadly learned that Jan Horn no longer is among us. ¬†May he rest in peace, and be remembered fondly.

#opengl     #sourcecode  

FireDAC Date Handling – FireDAC Date Mystery Part II

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: TField;

  s: String;


    F := FieldByName(FieldName);


    case F.DataType of

      ftDateTime: Result := F.AsDateTime;

      ftTime: Result := StrToTime(F.AsString);

      ftDate: Result := StrToDate(F.AsString);

      else begin

¬† ¬† ¬† ¬† OutputDebugString(‘GetAsDateTime(‘+FieldName+’).DataType=’ + IntToStr(Ord(F.DataType)));

        Result := StrToDateTime(F.AsString);




    on E:Exception

    do begin

      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?