[AccessD] DSNLess remote tables return 'dbo' for user_name()

Ryan W wrwehler at gmail.com
Sat Apr 10 07:17:14 CDT 2021


Thanks,

Is there a way to determine the most recent ODBC driver packages with windows ? We are mostly on Windows 10 now. But don’t have any of the SQLNCLI drivers or anything like that loaded. 

Sent from my iPhone

> On Apr 9, 2021, at 11:25 PM, Paul Wolstenholme <Paul.W at industrialcontrol.co.nz> wrote:
> 
> Ryan,
> 
> I see that the driver you specify in your connection string supports SQL
> Server 2000 and older.  That will not support features implemented in newer
> SQL Server versions (for example the old datatime data type is no longer
> recommended and the preferred datetime2 data type is presented by that old
> driver as text).  It may even be related to the problem you observe.
> You would be well advised to use a driver at least as new as your SQL
> Server (although if you choose too new a driver you might have to download
> it to each client computer).
> 
> For the ultimate on connection strings see
> https://www.connectionstrings.com/sql-server/
> MSAccess seems to require "ODBC:" at the start of the string - the website
> omits that.
> 
> Paul Wolstenholme
> 
> 
>> On Sat, 10 Apr 2021 at 15:46, Paul Wolstenholme <
>> Paul.W at industrialcontrol.co.nz> wrote:
>> 
>> Ryan,
>> 
>> Each SQL Server instance records a default database for each user in the
>> login properties.
>> You can edit this choice in SSMS or you can use the ALTER LOGIN command.
>> 
>> When your connection string does not specify the database, the default
>> database is the one you connect to.
>> I hope this helps.
>> 
>> Paul Wolstenholme
>> 
>> 
>>> On Sat, 10 Apr 2021 at 06:03, Ryan W <wrwehler at gmail.com> wrote:
>>> 
>>> I've run into a weird issue where DSN-Less ODBC connections to remote
>>> tables return 'dbo' for user_name() function instead of the actual
>>> username.
>>> 
>>> 
>>> I found this post:
>>> 
>>> https://microsoft.public.sqlserver.programming.narkive.com/mI2I7MtU/user-always-returns-dbo-when-using-ms-access-pass-thru
>>> 
>>> 
>>> Which did in fact, "fix" the issue, the problem is if I drop the
>>> DATABASE=DBNAME out of the ODBC string once I close the application and
>>> re-open it, the tables cannot be opened again (presumably because the
>>> connection does not tell which database the table is in?)
>>> 
>>> 
>>> If I convert this to a DSN connection it's fine?   What am I missing here?
>>> 
>>> 
>>> current string looks like:
>>> 
>>> ODBC;DRIVER=SQL Server;SERVER=SVR1;WSID=RYAN;DATABASE=DB1;Persist Security
>>> Info=false;TABLE=dbo.UserRoles
>>> 
>>> I've also removed the Persist Security Info option and that did not seem
>>> to
>>> make a difference (and Access seems to add that itself)
>>> 
>>> 
>>> if I do a complete passthrough query in vba and drop the DATABASE=DB1 out
>>> of the string, the function select user_name() does indeed return the
>>> connecting username instead of dbo?
>>> --
>>> AccessD mailing list
>>> AccessD at databaseadvisors.com
>>> https://databaseadvisors.com/mailman/listinfo/accessd
>>> Website: http://www.databaseadvisors.com
>>> 
>> 
> -- 
> AccessD mailing list
> AccessD at databaseadvisors.com
> https://databaseadvisors.com/mailman/listinfo/accessd
> Website: http://www.databaseadvisors.com


More information about the AccessD mailing list