I am using the TSqlDBOleDBMSSQL2018ConnectionProperties and I believe that there is a bug in SetInternalProperties. The procedure looks like this:
{ TSqlDBOleDBMSSQL2018ConnectionProperties }
procedure TSqlDBOleDBMSSQL2018ConnectionProperties.SetInternalProperties;
begin
inherited SetInternalProperties;
fProviderName := 'MSOLEDBSQL';
end;
The procedure inherited SetInternalProperties is called before setting the fProviderName, which will result in that the base class TSqlDBOleDBMSSQLConnectionProperties, will set the fProviderName to 'SQLNCLI10'. This results in the wrong 'ConnectionString', that will uses 'SQLNCLI10' as the provider name. This connection string is generated in the base class TSqlDBOleDBConnectionProperties during SetInternalProperties.
Changing the above code to
{ TSqlDBOleDBMSSQL2018ConnectionProperties }
procedure TSqlDBOleDBMSSQL2018ConnectionProperties.SetInternalProperties;
begin
fProviderName := 'MSOLEDBSQL';
I am using the TSqlDBOleDBMSSQL2018ConnectionProperties and I believe that there is a bug in SetInternalProperties. The procedure looks like this:
{ TSqlDBOleDBMSSQL2018ConnectionProperties }
procedure TSqlDBOleDBMSSQL2018ConnectionProperties.SetInternalProperties; begin inherited SetInternalProperties; fProviderName := 'MSOLEDBSQL'; end;
The procedure inherited SetInternalProperties is called before setting the fProviderName, which will result in that the base class TSqlDBOleDBMSSQLConnectionProperties, will set the fProviderName to 'SQLNCLI10'. This results in the wrong 'ConnectionString', that will uses 'SQLNCLI10' as the provider name. This connection string is generated in the base class TSqlDBOleDBConnectionProperties during SetInternalProperties.
Changing the above code to
{ TSqlDBOleDBMSSQL2018ConnectionProperties }
procedure TSqlDBOleDBMSSQL2018ConnectionProperties.SetInternalProperties; begin fProviderName := 'MSOLEDBSQL';
inherited SetInternalProperties; end;
fixes the issue with the 'ConnectionString'.