I'm writing a script that is supposed to run around a bunch of servers and select a bunch of data out of them, including the local server. The SQL needed to SELECT the data I need is pretty complicated, so I'm writing sort of an ad-hoc view, and using an OPENQUERY statement to get the data, so ultimately I end up looping over a statement like this:
exec('INSERT INTO tabl SELECT * FROM OPENQUERY(@Server, @AdHocView)')
However, I've heard that using OPENQUERY on the local server is frowned upon. Could someone elaborate as to why?
Problem #2: linked servers don't cache data. Even worse, it penalizes both servers involved with the linked server query. It's hard on the local server, and it's hard on the remote server that holds the single source of truth for the table.
Executes the specified pass-through query on the specified linked server. This server is an OLE DB data source. OPENQUERY can be referenced in the FROM clause of a query as if it were a table name. OPENQUERY can also be referenced as the target table of an INSERT, UPDATE, or DELETE statement.
Depending on the permissions that such a remote login has at the linked server, this could potentially pose a serious security threat. It is especially dangerous if your linked servers use a login that has the sysadmin role at the remote server.
The OPENQUERY function is used to specify that a distributed query be processed on the remote server instead of the local server. Linked servers (four part queries); are also called distributed queries. Distributed queries create an execution plan by looking at the query and breaking it into remote and local queries.
sp_addlinkedserver
stored procedure is used within same script, the credentials used on the remote server are hardcoded into the script, visible to anyone who has a copyReference:
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With