Assume a query that contains something like
set #x = max([column]) from [table]
insert into [table]
select * from [linkedserver].[database].dbo.[table] where [column]>#x
Is there an advantage to using OPENQUERY here instead of the 'direct' approach?
I'm running this on SQL Server 2016, data is being migrated from the linked server which is an old SQL Server 2005.
It works, I'm just wondering if it would be better to use OPENQUERY or not.
I have a function in [MHL1P].[x].dbo.udf_Admin_GetNameByID(t3.StaffID)
I want to execute this function from another server in a store procedure like this:
select [MHL1P].[x].dbo.udf_Admin_GetNameByID(StaffID)
from StaffIdTable
Is there a configuration in SQL server to execute functions cross servers?
Look at sp_addlinkedserver
Note that this is usually a bad idea, as certain things don't work as well on linked servers (the query optimizer doesn't have good information about statistics or indexes, for example).
Assuming you have a linked server you may need to use OPENQUERY to call a UDF as this article suggests.
I'm not sure if they fixed this in 2005 or 2008.
I am using Oracle SQL Developer in a linux environment to connect to an SQL Server 2005.
I don't seem to be able to make a sp_help [table_name] call. Previously, I found it quite useful when I was on a Windows environment using SQL Server management, and could make that call.
Is there any way to do this?
[edit] error message returned is the following:
Error starting at line 1 in command:
sp_help city
Error report:
Unknown Command
Have you considered using the information_schema views instead.
E.g.
Select *
from information_schema.columns
where table_name = 'City'
Have you tried exec sp_helptable [table_name]?
this works: exec sp_helptable 'table_name'
Sorry to say this, but SQL Server won't care about the string it's sent in the batch so it's problem with the client or the driver.
If you have to use Linux, try SQuirreL instead which is a vey nice tool
exec sp_help [db.schema.table] works
I have a project that requires me to do development in SQL Server 2005, but do deployments to a SQL Server 2000 box.
For 99% of the SQL code, I have no problems, everything appears to be backwards compatible.
Now I am just about to start adding all the Stored Procedures (SPs) to source control, and I like the idea of doing a drop-add each time the query is executed. I.E. If the SP already exists, first drop it. Then create/re-create the SP.
How do I do this in a single script, in a manner that is compatible with both SQL 2000 and SQL 2005, so that my scripts will just work during Development (2000) AND Production (2005)? I believe the syntax is slightly different, and the SP metadata is stored in different system tables.
Please assist with a working SQL script.
This works for both SQL 2000 and SQL 2005. I have tested it right now.
USE databasename
GO
IF object_id('schema.StoredProcedureName') IS NOT NULL
DROP PROCEDURE schema.StoredProcedureName
GO
CREATE PROCEDURE schema.StoredProcedureName
.. your code
Don't use system tables: use OBJECT_ID
I would also deploy using ALTER but maintain source control using CREATE. That is, I only ever use differential deployment scripts (with ALTER) but compare to my source control folder after release (which as CREATE)
I have both code history and simpler deployments: there is no need to drop/create all procs. What if you forget a permission for example?
I use Red Gate/SVN BTW
I think
IF OBJECT_ID('your_sp_name') IS NOT NULL
will tell you if it is there, although I can't test on 2000 at the mo...
FWIW
select * from sysobjects where type = 'p'
still works in SQL 2008, so am guessing that this is still acceptable as the lowest common denominator. DMV's weren't available in 2000.
You best option is staill the compatibility views, sysobects, syscolumns, etc
Check out the following link
http://msdn.microsoft.com/en-us/library/ms187376.aspx
Many of the system tables from earlier
releases of SQL Server are now
implemented as a set of views. These
views are known as compatibility
views, and they are meant for backward
compatibility only. The compatibility
views expose the same metadata that
was available in SQL Server 2000.
It seems to me that you recreate all STORED PROCEDUREs with respect of sys.sp_refreshsqlmodule like if is described in my old answer I'm looking for a reliable way to verify T-SQL stored procedures. Anybody got one?. The code of STORED PROCEDUREs will be one more time verified inclusive off dependencies.
Using the INFORMATION_SCHEMA.ROUTINES view should work in SQL Server 2000, 2005, and 2008. The only downside is that the view is no longer a viable means of determining the object's schema.
But if that is not a concern, try a script like this:
USE YourDB
GO
IF EXISTS (
SELECT *
FROM INFORMATION_SCHEMA.ROUTINES
WHERE ROUTINE_NAME = 'usp_test'
) DROP PROCEDURE usp_test
GO
CREATE PROCEDURE usp_test AS
SELECT 1 AS val
GO
EXEC usp_test
GO
In most cases, I'd try to run SQL2000 TSQL on the 2005 box, as I'd expect it to be largely backward-compatible. That said, you ought to finish upgrading your production box so you can use newer TSQL.
In cases where you can't find compatibility between the versions, you could first detect the version.
To determine which version of SQL Server 2000/2005 is running, connect to SQL Server 2000/2005 by using Query Analyzer, and then run the following code:
SELECT
SERVERPROPERTY('productversion'),
SERVERPROPERTY ('productlevel'),
SERVERPROPERTY ('edition')
The results are:
The product version (for example, 8.00.534).
The product level (for example, “RTM” or “SP2″).
The edition (for example, “Standard Edition”).
For example, the result looks similar to:
8.00.534 RTM Standard Edition
Source: http://blog.sqlauthority.com/2007/03/07/sql-server-script-to-determine-which-version-of-sql-server-2000-2005-is-running/
Once you determine the version, you can execute the proper level of code.
In SQL Server, how can I execute a piece of tsql against all databases in an instance?
Great thanks.
There is an undocumented stored procedure sp_MSForEachDB which if you call passing in a string as a parameter, it will execute that string, substituting a ? for the database name.
E.g.:
exec sp_MSForEachDB 'use ?; select * from INFORMATION_SCHEMA.TABLES'
For SQl Server 2005, the excellent SSMS Tools pack contains this functionality.
[This functionality is available natively in SQL Server 2008].