0
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.

| improve this question | | | | |
  • Is remote user really sa? Of course this is not "a firewall issue", the server is reached but the user does not see columns. – sepupic Nov 30 '17 at 9:44
  • >>>Aside from the collation of the non-working instances being different<<< Are you sure that you use correct object name? Maybe your "tbl_Version" is "TBL_Version" and database collation is CS? – sepupic Nov 30 '17 at 10:07
  • @sepupic it still could be. The problem is it works workstation to server but not server to server which are two different origins. I'd try to use sqlcmd on the server to try a connection to the other server. If it works, great. If not, there's the start of your issues. – Sean Gallardy - Retired User Nov 30 '17 at 15:57
  • @sepupic: 1.) Checked the collations and in this case, at the User database level, they are consistent: Latin1_General_CI_AS. The default collations are per the Windows locale, so the system DBs differ between instances, but we always deploy the same User DB Collation, irrespective of the instance settings. 2.) The remote user of sa has the same role memberships as another standard deployed SQL Login - I used both for the command and both fail with the same error. – SAinCA Nov 30 '17 at 18:11
  • @Sean: I just ran server-to-server and same results - 1 works, the other, not. On the same server, I connected via SSMS and can see everything and run queries just fine. Source is 2014, target is 2016 that fails; 2014 that succeeds. Not sure what you mean by "there's the start of your issues". Can you elucidate, please? – SAinCA Nov 30 '17 at 19:05
0

Found the issue...

The table is no longer a table - it's a SYNONYM over the same table schema that has moved to a named schema from dbo, and has a new name: SystemVersion. OLE DB provider choked! (SQLNCLI or SQLOLEDB)

| improve this answer | | | | |

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.