search

microsoft / ODBC-Specification

Microsoft ODBC Specification
Other
121 stars 40 forks source link

Private Driver Location #34

Closed mikepizzo closed 7 years ago

mikepizzo commented 8 years ago

1) Should we make the default location "ODBCDVRS" to support 8.3 paths? 2) Should we provide a SQL_ATTR_PRIVATE_DRIVER_LOCATION environment attribute for setting an alternate location for private drivers?

lpillar commented 7 years ago

We actually need to come up with a more explicit strategy for setting the Private Driver location.

-If we implicitly look for private drivers relative to the running process or executable location, then private drivers can't be used for libraries that are called by another application or by test harnesses. -If we implicitly look for private drivers relative to the ODBC libraries, then even after 4.0 ships, anyone who wants private driver support will need to ship the ODBC libraries with their application, rather then using the ones in System32/SysWOW64.

An environment attribute could work, but it could result in weird (or malicious) behavior if the variable is set globally (it would be very simple for a malicious script to set a global private driver path, and it would be just as easy for someone to accidentally make a path meant for one application global.)

It would be simpler and safer to just add a new ODBC 4.0 API to set the private driver path (SQLSetPrivateDrvPath?) We could make the default behavior check relative to the ODBC32.dll file or running executable, which would enable drag-and-drop functionality for applications that don't knowingly use private drivers if we want to support this scenario.

mikepizzo commented 7 years ago

Agree that we should add SQL_ATTR_PRIVATE_DRIVER_LOCATION environment attribute for setting an absolute path as an alternate location for private drivers.

Doesn't seem to be a reason to rename the default location to ODBCDVRS...

lpillar commented 7 years ago

I added updates to the spec to resolve this issue.