10-20-2011 02:20 PM
I found it!!!
APP=<put your USERID GUID here>
in provider string instead of
Application Name= <put your USERID GUID here>
10-21-2011 01:53 PM
Accessing SQL in this way gives you user contextual access to SQL tables/views,etc...
You should be able to access the OLEDB2 SQL views in a manner similar to using the provider. Be aware this is an unsupported access method (you're really using SQL OLEDB or ODBC but gaining access with user context ala OLEDB2). We do have some internal documentation on this, and I use it to write statements against OLEDB views, but there are some implementation concerns with doing this:
1. Your conduit (ODBC) accesses the DB with what ever DB user permissions you use (I presume you're using SA?)
2. Not all SQL resources or methods will behave properly when accessing through this method - if you're trying to hit anything other than our OLEDB views or core tables - I think you'll have issues.
3. Even through technically you're in the DB as whatever SQL user you choose - I STRONGLY suggest you don't try to Update/Create or Delete from the DB through this interface. Along with this being a violation of the EULA, you're likely to create data problems or data loss by doing so - Select statements should be OK.
As to your Linked Server question - technically you should be able to add a linked server using this connection interface. For those who haven't done this before lookup T-SQL OPENQUERY - it's much faster than running a distributed query.
10-21-2011 02:15 PM
11-22-2011 07:16 AM
I created a post as to why the OLEDB provider isn't showing up on 64 bit OS - you have to explicitly run the 32 bit version of the MS OLEDB interface to see any 32 bity providers: