Well, give me an example of using a connection string, I'd guess checking the Connection object Provider property after making the connection you'll find "MSDASQL" used, the generic Microsoft OLEDB Provider for ODBC, even if you don't specify a provider in the connection string but use an ODBC driver connection string.
If you're using OLEDB you better use OLEDB Providers than ODBC drivers, you only add another layer of marshalling ODBC data types to the OLEDB layer, that's unnecessary.
Microsoft stopped further development of the whole OLEDB Provider branch, so in the long run I'd opt out of classic ADO overall and use direct ways to ODBC, but currently there are the Native Client OLEDB Provider variants similar to the Native Client ODBC drivers, also capable to connect and support SQL2014.
Bye, Olaf.
PS: I just did so with the conceptual connection string "Driver={ODBC Driver 11 for SQL Server};Server=MyServer;Database=MyDatabase;Trusted_Connection=Yes;MARS_Connection=yes;" taylored to my server/db, of course, and the used provider reported is indeed "MSDASQL.1".
When you already use an OLEDB Provider, you better use one, that directly connects to the database and avoid an additional layer, or you avoid the OLEDB layer overall by not using (classic) ADO.
The only advantage of MSDASQL is, you can use ODBC drivers later than the newest OLEDB providers, but that will play a role from SQL2016 onwards, not for SQL2014, the disadvantage is, you always go through MSDASQL and the ODBC driver specified and have an additonal layer you don't have using ODBC directly. I'm no Access VBA or VB6 expert, but I'd say DAO or RDO are data access variants not using an OLE layer.
