Jump to content

Lars Fosdal

Administrators
 View Profile  See their activity

  • Content Count

    3521

  • Joined

  • Last visited

  • Days Won

    116

Posts posted by Lars Fosdal

  5. Posted

    EMBT placed the above constants in the implementation section of the FireDAC.Phys.MSSQL, which I guess is good for hiding implementation details, but not so good for doing overrides... hello, new literal.

     

    Initial benchmarks indicate that C_2016_ODBC = 'ODBC DRIVER 13 FOR SQL SERVER' is about the same speed as SQLNCLI 11, which is good news.

      

    class function TPSDFireDatabasePoolMSSQL.FindBestDriver(const Link: TFDPhysMSSQLDriverLink): String;
const // Constants copied from implementation section of FireDAC.Phys.MSSQL
  C_2017_ODBC = 'ODBC DRIVER 17 FOR SQL SERVER';
  C_2016_ODBC = 'ODBC DRIVER 13 FOR SQL SERVER';
  C_2012_ODBC = 'ODBC DRIVER 11 FOR SQL SERVER';
{$IFDEF POSIX}
  C_FreeTDS = 'FreeTDS';
{$ENDIF}
{$IFDEF MSWINDOWS}
  C_2012_NC = 'SQL SERVER NATIVE CLIENT 11.0';
{$ENDIF}
var
  DriverList TStringList;
  WantedList : TArray<String>;
begin
  Result := '';
  WantedList := {$IFDEF MSWINDOWS} [C_2017_ODBC, C_2016_ODBC, C_2012_NC, C_2012_ODBC] {$ENDIF}
               {$IFDEF POSIX} [C_2017_ODBC, C_2016_ODBC, C_2012_ODBC, C_FreeTDS] {$ENDIF};

  DriverList := TStringList.Create;
  try
    Link.GetDrivers(DriverList);
    for var Wanted in WantedList
     do for var Driver in DriverList
      do if CompareText(Wanted , Driver) = 0
       then Exit(Wanted);
  finally
    DriverList.Free;
  end;
end;

class function TPSDFireDatabasePoolMSSQL.CreateDriverLink(const aOwner: TComponent): TFDPhysDriverLink;
var
  Res: TFDPhysMSSQLDriverLink;
begin
  Res := TFDPhysMSSQLDriverLink.Create(aOwner);
  Res.ODBCDriver := FindBestDriver(Res);
  Result := Res;
end;

     

  6. Posted

    Oddly enough, FireDAC seems to prefer SQLNCLI over everything else, and I can't find a way to override that priority, apart from explicitly setting the ODBCDriver on Create, which makes it harder to handle it not being installed
      

    procedure TFDPhysMSSQLDriver.InternalLoad;
begin
  inherited InternalLoad;
  if ODBCDriver = '' then
    ODBCDriver := FindBestDriver(
      {$IFDEF MSWINDOWS} [C_2012_NC, C_2016_ODBC, C_2012_ODBC, C_2017_ODBC, C_2008, C_2005, C_2000] {$ENDIF}
      {$IFDEF POSIX} [C_2016_ODBC, C_2012_ODBC, C_2017_ODBC, C_FreeTDS], C_FreeTDSLib {$ENDIF}
    );
end;

     

  13. Posted

    5 hours ago, Ondrej Kelle said:

    Not really when writing my own code, I try to avoid them if possible.

    Sometimes for interop with an API, e.g. when translating C headers where enums are already declared that way.

    Or when you need to support a binary format which uses some specific ordinal values, then it depends - you might still prefer to use an enum but avoid conversion.

    I still prefer using regular constants for bit-fiddling.

  18. Posted

    19 hours ago, Stefan Glienke said:

    When used in a set, the ordinal value of the enum is basically the index of the bit used within the set and as they can only be 256 bit in size any ordinal value above 255 prevents an enum being used as a set.

    Personally I think you should rather avoid giving enums any ordinal values and only ever use them when using some interop with another system where they are used for.

    Isn't there something weird about RTTI for enums that have manually set ordinal values as well?

  20. Posted · Edited by Lars Fosdal
    Corrected open array to dynamic array.

    Off-topic: There is another oddity with enumerations with explicit ordinal values.


    TEnum = (plough = 5, foo = 9, bar = 14, wtf = 1000);
    The above is valid, but wtf can't be used in a set.

    Makes me wonder if it would be better to generally do sets as dynamic arrays, instead of today's implementation of sets.
    I guess it would be more expensive.

  24. Posted

    I think it could be fantastic if it was possible to design custom property lists per class.  The first time a class is seen, it could be added to a list of class property configs, with all the props present.  In a config dialog somewhere, it could be possible to enable/disable each prop.  The filter could even use digits 0..9 to select one of multiple configurations per class. Naturally, if it could be installed with default filters for many of the standard components, that would be nice. I really like the idea - more than I like quick edit. Nice work!

    • Thanks 1
×