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
I am trying to export the tables [around 40] and stored procedures [around 120+] in SQL Server 2008 R2 from dev server to prod server.
I have created a .sql file [right clicking on the database in SSMS, choosing Tasks -> Generate Scripts], but when I am trying to import the table and stored procedures into the prod server [right clicking on the database in SSMS, New Query then copying the content in] it is giving me a long list of errors
Mostly
There is already an object named 'tblMyTable' in the database
Violation of PRIMARY KEY constraint 'PK_MyTable'. Cannot insert
duplicate key in object 'dbo.tblMyTable'
Any idea what I am doing wrong or what should be done? Thanks in advance.
The problem with your current technique is that assumes your target is an empty database. So it will reinsert everything with no attempt at merging data and this is what causes your duplicate primary keys. If you use Management Studio you have to do all the merging of data yourself.
My recommendation is first to look into redgate it's not free but all the time you will save it will be worth it. You will need to use both SQL Compare and Data Compare ( http://www.red-gate.com/products/sql-development/sql-data-compare/ ).
Another alternative is to use Visual Studio 2010 premium if you have it( http://msdn.microsoft.com/en-us/library/aa833435.aspx and http://msdn.microsoft.com/en-us/library/dd193261.aspx). This gives both a data compare and a schema compare option. It is not as good as redgate but I found it works most of the time.
If you are looking for free alternatives check out this stack post https://stackoverflow.com/questions/377388/are-there-any-free-alternatives-to-red-gates-tools-like-sql-compare.
if you are importing the whole database to production you might as well do a restore with replace to the production database.
120 SPs and 20 tables seemed to be the whole database. so Restore with replace should be done.
When trying to automate reading out constraint information using sp_helpconstraint I got the bright idea of pulling out the source code of the built-in SP directly and run it myself (since it returns multiple result sets so those can't be stored in a temp table). So I ran exec sp_helptext 'sp_helpconstraint' (on SQL Azure) to generate the source code, and copied it into a new query window.
However, when I run the SP (on SQL Azure), I get lot's of error messages -- for example, that object syscomments doesn't exist even though I am using the exact same source that runs perfectly when calling sp_helpconstraint directly. Just to make sure it wasn't an anomaly with the procedure or a mistake in my copy/paste execution, I tested the exact same procedure on SQL Server 2008, and if I directly copy the SP source into a new query window, it runs perfectly (obviously after removing the return statements and manually setting the input parameters).
What gives?? Do built-in SP's run in a special context where more commands are available than normal on SQL Azure version? Is sp_helptext not returning the actual source that is being run on SQL Azure?
If you want me to try anything out, give a suggestion and I can try it on our SQL Azure Development instance. Thanks!
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.
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