SELECT MAX(VersionNumber)
FROM OPENDATASOURCE(
'SQLNCLI',
'Data Source = I.P.V.4;User ID = sa;Password = pswd;catalog=MyDB'
).MyDB.dbo.tbl_Version
results in a "speak to the red-hand" error that does not occur on over 20 other remote SQL instances inquired-of from the same source SQL instance:
Msg 7357, Level 16, State 2, Line 1 Cannot process the object ""MyDB"."dbo"."tbl_Version"". The OLE DB provider "SQLNCLI11" for linked server "(null)" indicates that either the object has no columns or the current user does not have permissions on that object.
Source is SQL 2016, targets vary from 2008R2, 2012, 2014 up to 2016 SP1 CU2, Enterprise and Standard Editions.
I used Idera's SQL Admin Toolset to get the server configurations from a working baseline instance, and compare it to 2 working instances, and 3 non-working instances.
All 3 of the latter reside in a Hong Kong Rackspace datacenter. The working instances are in either a US or a UK Rackspace datacenter.
Aside from the collation of the non-working instances being different, there are no differences of merit (MAXDOP and MAXMEM don't count).
I also used that toolset's SQL Database Configuration tool and set the baseline as a working 2016 DB, then compared it to another working instance's 2014 DB, and the not-working 2016 DB - the only difference is the SQL Compatibility Level.
Ad Hoc Distributed Queries is running "ON", on all servers.
All 3 client protocols are enabled. All TCP/IP configurations in SQL Client configs are identical.
I can connect via SSMS from my laptop using the I.P. of the not-working instance, using the same SQL login and password, and run a SELECT *
from the same table, and get all rows. I can see everything via SSMS.
I opened Server Objects/Linked Servers/Providers/SQLNCLI11 and looked at the properties on working and non-working instances - identical - the DisallowAdhocAccess
setting is "OFF".
Although BOL doesn't state that after the RECONFIGURE
to set the Ad Hoc Distributed Queries
config to "ON", one must restart SQL, is this an omission/something that is really "required"?
Having Googled for the Msg line, plus most of the error text and found just 10 hits, none of which are useful, I took out the text message and still found nothing relevant that includes the "Msg 7357" portion.
Does anyone suspect a firewall issue? I doubt that because I can get through with SSMS, as I said above...
What (else) am I missing?
Thanks for any insights.