In SQL Server Management Studio, I have linked a SQL Server, sql02 to my local server as such:
sp_addlinkedserver 'sql02'
GO
I can query tables from this server:
SELECT * FROM SQL02.SomeDatabase.dbo.SomeTable
However, when I try to query a view, as in
SELECT * FROM SQL02.SomeDatabase.dbo.SomeView
I get the following error message:
Msg 7314, Level 16, State 1, Line 1
The OLE DB provider "SQLNCLI10" for linked server "SQL02" does not contain the
table ""SomeDatabase"."dbo"."SomeView"". The table either does not exist or the
current user does not have permissions on that table.
Agreed that SomeView does not exist as a table. What am I doing wrong?
Potentially relevant facts:
Local version of SQL Server is 10.50.1617
Version of linked server is 8.0.2282
I can SELECT from all the underlying tables in the view
Looks like a permission issue, have you checked the permissions on the view? There's nothing wrong with your query.
Also, have you checked what table does that view query on? Check the table permissions as well.
As a tip: Try to run the view on a specific user and if that's successful try to link the server using that specific user.
Related
I have users with datareader permission on my sql, the problem is that i noticed that the users are doing "fishing" query a lot (they don't know what exactly should be querying to get what thy need).
This is a production SQL and we started to have deadlock because of those users.
Trying to don't break their process i applied "deny view definition to [user]" so they cannot see the list of tables, view, stored procedure, so no more "fishing"
This was a great solution, it works perfect if you connect directly to the SQL Server, you can run queries (select) but you cannot see the list of tables.
However many users are using those account to connect to our SQL using linked server, and when the run a query using the linked server they are getting error:
SELECT TOP 100 *
FROM [SERVERSQL].[DATABASE].dbo.[TABLE]
Msg 7314, Level 16, State 1, Line 1
The OLE DB provider "SQLNCLI11" for linked server "SERVERSQL" does not contain the table ""[DATABASE]"."dbo"."[TABLE]"". The table either does not exist or the current user does not have permissions on that table.
Using SQL Server version 2014 (v12.0.2000.8) and 2016 (v13.0.5492.2).
What is the correct way to hide tables, view, stored procedures, etc but allow select and make it work on linked server?
Thanks
Linked server from one SQL Server to Another:
Linked server name is: PLWNSAVSQL02D which is SQL Server
This sql to linked server works:
select count(*) from [PLWNSAVSQL02D].[SFI_WMS].dbo.[TCOMPANYPALLETMESSAGES];
I have SQL Server 2008 SP4 instance accessing a linked server that is running a MediaWiki database on MariaDB (v 5.5.44). I am able to select from the table no problem:
SELECT *
FROM OPENQUERY(MEDIAWIKI,
'SELECT * FROM wiki.page WHERE page_title = ''Test''')
But when I try to update the table:
UPDATE OPENQUERY(MEDIAWIKI,
'SELECT * FROM wiki.page WHERE page_title = ''Test''')
SET page_title = 'TestChange'
I get the following error message:
OLE DB provider "MSDASQL" for linked server "MEDIAWIKI" returned message "Table 'def.page' doesn't exist".
Msg 7343, Level 16, State 4, Line 1
The OLE DB provider "MSDASQL" for linked server "MEDIAWIKI" could not UPDATE table "[MSDASQL]".
The user has full permissions, so that shouldn't be an issue. I'm also able to make updates against other linked servers running MySQL. Any help is hugely appreciated. Thanks!
EDIT: I am able to get around this by building a dynamic query string and executing it at the linked server, mostly just curious as to why this is happening at this point.
I second Vladislav here. 'def' is used as catalog value(if you look in columns metadata returned by server, or in INFORMATION_SCHEMA tables 'TABLES' or 'COLUMNS'. Both MySQL and MariaDB connectors return table's schema as catalog, and NULL as schema.
It must be that MariaDB Connector/ODBC has but and returns 'def' somewhere in metadata as schema(or catalog?). What version do you use? In fact it could be fixed in latest version. But please better proceed in the JIRA issue created by Vladislav
What kind of ODBC driver do you use? There are 2, MariaDB one, and MySQL one. This looks like a bug in one of these ODBC. Now what does "def" mean. There is a great amount of confusion in MySQL world about catalog, database and schema. MySQL result sets are returned with metadata (column info description). Column info contains several fields, among them "table catalog" (always hardcoded "def") , and also "table schema", aka database. Catalog does not have any meaning currently, and never had, but who knows maybe it could mean something in the future. "schema" on the other hand, is something that you can put into UPDATE command ( UPDATE schema.table SET field=value WHERE ...) . So the bugs seems to be is that one of the ODBC drivers incorrectly chooses "catalog" over "schema".
I am want to make the following statement:
INSERT INTO [Server_1\Instance_1].[Database].[dse].Table1
SELECT * FROM [Server_2\Instance_2].[Database].[dse].[**Table1**]
The point is the tables are on the different servers. I tried with the statement above. However, when I am on server_1 and when I run the following statement in order to retrieve the data from server 2:
SELECT * FROM [Server_2\Instance_2].[Database].[dse].[**Table1**]
... I get zero rows.
But when I run the statement above on the Server_2, I get a set of rows.
How can I transfer data from production to development server/environments?
I am using MS Management Studio.
UPDATE:
The error message I am getting when I run the select statement in order to retrieve the data from another (production) server:
The OLE DB provider "SQLNCLI10" for linked server "Prod_Server\Instance" does not contain the table ""Database"."dse"."BoxIteration"". The table either does not exist or the current user does not have permissions on that table.
Select statement is:
SELECT * FROM [Prod_Server\Instance].[Database].[dse].[BoxIteration]
Two things to take into account:
add the source server as a linked server in the destination server
verify that the credentials specified while creating the linked server have access to the data in the source server
I have a localized version of SQL Server, so the transalation may not match what you will see in your screen: open Object Explorer window in SSMS, connect to the destination server, open the tree and look for Server Objects, Linked Servers. Right click on the source linked server, and see the properties. Open the Security pane, and see which credentials are used to connect to the linked server.
Once you do so, you have to check the permissions of that credentials on the source server to verify that it can acccess the table in question.
If you don't understand, or can't do some of the steps (for lack of permissions), get help form your DBA: he will understand and solve the problem at once.
If u have access(Having credentials) to both prod and dev Db servers you can use "Import and Export Data"
1.Go to start and open "Import and Export Data"
Wizard will open give source server name, credentials and Database(For your case Prod)
Then give destination server name, credentials and Database(Dev)
Select the table , if there any identity column -->"Edit Mapping" and Enable identity insert.
Then give next--> it will start copying.
I have been trying for the past week or so to import data programmatically to a SQL Server 2008 table from a Microsoft Access .mdb file. I have been getting nothing but errors, and solving one just reveals another. I made the file into a linked server, and now when I try to query it with:
Select * from OPENQUERY(Importdata, 'Select * from [IMBPieceBC]')
I get the error:
OLE DB provider "Microsoft.Jet.OLEDB.4.0" for linked server "Importdata" returned message "Cannot open database ''. It may not be a database that your application recognizes, or the file may be corrupt.".
Msg 7303, Level 16, State 1, Line 1
Cannot initialize the data source object of OLE DB provider "Microsoft.Jet.OLEDB.4.0" for linked server "Importdata".
I've read several suggestions to relink dlls in the registry, but I've done that, and I'm still getting the error. Is there anything else I can do to fix it, or at least figure out what is wrong?
Migrating the data to a SQL Server instance is not an option. The mdb files are generated by a third-party program, so there's nothing we can do about it.
I have a similar situation at my workplace - a third party application that maintains data in MDBs, but other applications needing access to it. How I've done it is that this 'intermediary' application has links to the SQL Server tables and the MDB tables. You could use either a query or a VBA written form event to transfer information from the MDB table(s) involved into your corresponding SQL Server tables using a INSERT INTO query, fitted with a SELECT FROM subquery providing the values being inserted.
I've been trying to create a linked server in SQL Server that accesses a
remote Index Service catalog, but I can't seem to do it. Let's call
the remote server "remoteServer" and the Catalog "remoteCatalog"
I've tried this:
EXEC sp_addlinkedserver remoteIndexServer, 'Index Server', 'MSIDXS',
'query://remoteServer/remoteCatalog'
and then i did run the SQL
SELECT * FROM OPENQUERY(remoteIndexServer,'select filename from scope()') AS Q
But i got the error as
OLE DB provider "MSIDXS" for linked server "remoteIndexServer" returned message "Service is not running. ".
Msg 7320, Level 16, State 2, Line 3
Cannot execute the query "select filename from scope()" against OLE DB provider "MSIDXS" for linked server "remoteIndexServer".
I have experienced this issue before. This is from memory so excuse any errors but if I recall correctly you will need to do the following.
Install the indexing service on your local SQL Server (this is so the provider is available).
Add a linked server to this LOCAL indexing service.
You can then run you query as below
SELECT *
FROM OPENQUERY(
LocalLinkedServer,
'select filename from RemoteServer.CatalogName..scope()'
) AS Q
If that doesn't work let me know, there is a post somewhere that describes how to do this. I can look it up if necessary but I think the above is right.