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.
Related
I'm working to make some fact tables (taking some data from some resources, doing some transformations and putting them in a table). My main dilemma is that I can't run any SQL query other than select, update, and insertion. As soon as i try:
exec someProcedure
or a conditional statement (if #part1 ...) or even (create table ...) I take errors. Opening the task to build my SQL statements and find problems it gives errors ranging from (The Set SQL construct or statement is not supported.) to (The EXEC SQL construct or statement is not supported.).
I looked for numerous topics here on stackoverflow but none were actually addressing me problem.
Thanks,
You can see a view of what I'm facing in this picture :
I expect to run my SQL commands as usual in SSIS.
Try changing the SQL Source Type from Direct Input to Stored Procedure and just specify the stored procedure name instead of Exec stored procedure
Also make sure that you have selected the relevant TargetServerVersion from the project configuration:
How to change TargetServerVersion of my SSIS Project
Based on your comments, you are using SQL Server 2012 with Visual Studio 2010 which are not compatible.
You have to use Visual Studio 2012 or 2015+ (backward compatibility added). You can refer to the SSIS tag wiki for more info:
https://stackoverflow.com/tags/ssis/info
The title pretty much says it all.
How can I view the original SQL that created a stored procedure in SQL Server 2008?
Is this possible? I've been searching online for some leads, but I'm either missing correct vernacular or I'm just looking for something that can be found by some other means.
My basic problem is that I've got a SQL Server 2008 db here with a couple hundred stored procedures and I want to see what they are doing. I need to copy one and modify it slightly and then use it.
Open up management studio and expand the database you are after. Inside of there is a programmability folder, expand that and you will see the stored procedures. Right click on one of them and select modify.
From a query window on the db you can execute sp_helptext YOURPROCEDURENAME It's a shorthand for what Martin described.
To get the definition
select object_definition(object_id('sp_help'))
Or in management studio right click the procedure and choose a scripting option.
As long as it was not encrypted sp_helptext is the stored procured you want to show the text of any stored procedure
Of course if you were storing your sps in your source control as you should be doing, you would go there and look at it and even be able to see previous versions.
For any of the answers given so far, if there was any set up done - to create a #temp table that the proc depends on, for example - that won't exist in the results because SS stores the functional code for the proc definition, not all of the SQL used in the creation. Some things you might have to infer.
I need to export database from SQL Server 2005 to SQL scripts (like we can easily do in MySQL). So I want to get generated file with scripts like this
INSERT INTO ... [row 1]
INSERT INTO ... [row 2]
INSERT INTO ... [row 3]
...
Can anybody explain how can I do this step-by-step?
Actually, one of the easist ways to export data from a MSSQL 2005 database is to use the SQL Server Database Publishing Toolkit which is described in length on Scott Guthrie's blog.
In addition, the SQL Database Publishing toolkit was derived from the tools already builtin to SQL 2005. The article Create Script to Copy Database Schema and All The Objects – Stored Procedure, Functions, Triggers, Tables, Views, Constraints and All Other Database Objects walks you through the different steps to script out the items that make up a database.
Another tool derived from the SQL 2005 tools is the Database Publishing Wizard which is a command line tool which scripts out all items of a database.
A final link to read tells how to Use the Database Publishing Wizard to script your table data.
Good luck and hope this helps you.
If you need to take an entire database, including schema, objects and data, I find the easiest way is to create a full backup and then restore it elsewhere. SQL Server Management Studio includes lots of different options to generate backups, including options to include users and to script object level permissions etc.. Detailed instructions for creating a backup and restoring from a backup from SQL Server Management Studi are available on MSDN.
If you just want to script insert statements to copy the data somewhere else, I've had success with this stored procedure. There are detailed instructions in the comments at the top of that script (scroll down past the NOTE to the examples). Basically once you've executed the stored procedure once, you can call the proc using a command like:
EXEC sp_generate_inserts 'tableName'
SQL Server Management Studio does not have this feature. You need some third party tool.
Eg. RedGate or SQLDumper.
Or you can write your own.
Try this
SELECT 'EXEC sp_generate_inserts ' +
'[' + name + ']' +
',#owner = ' +
'[' + RTRIM(USER_NAME(uid)) + '],' +
'#ommit_images = 1, #disable_constraints = 1'
FROM sysobjects
WHERE type = 'U' AND
OBJECTPROPERTY(id,'ismsshipped') = 0
Obtained from My code library . Just go a bit down in the page and you will find
Hope this helps
I dealt with this a while ago by writing a script (VBScript) to do it. Handles most data types, including blobs.
Get it from my site.
HTH.
This feature doesn't exist in SQL 2005. However, it was added in SQL 2008, so one solution is to upgrade. You might use the free SQL Express or the low-cost SQL Developer, if they meet your requirements.
Otherwise, you would need to write a program to do it, or use a third-party solution.
i want to extract specific database tables & stored procedures into one master script. Do you know any software that can help me do this faster? I've tried using the SQL Database publishing tool, but it's not that efficient since its gathering tables that I didn't select.
In SQL Server 2005, right click on the database, then select Tasks, and then select Generate Scripts.
Generating SQL Scripts in SQL Server 2005
As mentioned in that link, I'm fairly sure you have to generate the DROP and CREATE statements separately.
Try DBSourceTools. http://dbsourcetools.codeplex.com
Its open source, and specifically designed to script databases - tables, views, procs to disk.
It also allows you to select which tables, views, db-objects to script.
I use Redgate SQL compare for this (by comparing to an empty DB), as well as for doing upgrades between all my DB versions (I save a copy of the DB for each released version, and then just do a compare between current and previous to get a change script for that version).
I have found the "Generate Scripts" does a bad job in some cases with dependencies - eg, it will try to create a stored procedure that uses a table before the table is created, causing the script to fail. I'll accept I'm possibly using it wrong, but SQL Compare "just works". The scripts it generates are also enclosed in a transaction -- so if something fails, the whole change is rolled back. You don't end up with a half-populated or half-upgraded database.
Downside is that this is a commercial tool, but IMHO worth the money.
I know that you can do this in SQL Server 2005, but I'm at a loss for 2000.
Not to my knowledge.
To get around this, I manage my stored procedures in a Visual Studio database project. Every stored procedure is in its own file and has a drop command at the top of the file. When I update the stored through Visual Studio, the database's created date is updated in the database because of the drop/create statement. I am able to use the created date in SQL Server 2000 as the last modified date in this manner.
From all the research I've done on this in the past, I unfortunately have to say no. SQL Server 2000 simply does not store this information, and I've never seen any solution for retrieving it.
There are a few alternative methods, but they all involve user intervention. Besides keeping stored procedure scripts in a source control system, I think the next best approach is to use comments inside the stored procedure. Not ideal, but it's better than nothing if you want to track what gets updated.
SELECT crdate
FROM sysobjects
WHERE name = 'proc name here'
AND type = 'P'
It looks like you could use : SELECT * FROM INFORMATION_SCHEMA.ROUTINES
Found here : Date object last modified