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
Related
While comparing Database instance to a Database project in VS2010 using SSDT, it shows a difference in one of the Stored Procedures. The Store Procedure DDL script is exactly the same but when I expanded the Properties folder under the Store Procedure it show a difference in the DefaultExpressionScript.
The source SP shows this in the DefaultExpresionScript:
DefaultExpressionScript = at
While the destination SP has this:
DefaultExpressionScript = -1
I don't see where I can change this there is no such object called DefaultExpressionScript in my database project. where should I fix this?
This bug is still present in VS 2015 Update 3 with SSDT 14.0.61021.0. However, just scripting the stored procedure with ALTER ... in SSMS and running that query (which shouldn't change anything) fixed it for me. The schema comparison didn't show differences anymore afterwards.
The DefaultExpressionScript is the default value of one of the stored procedure's parameters. I suggest using Script As to get the TSQL definition of the stored procedure from the database and verifying that the stored procedure default values match what's in your database project.
Also, note that there have been a large number of bug fixes to schema comparison that aren't available in VS2010. Have you considered installing the latest version of Visual Studio 2015 Express with SSDT?
I finally found a workaround. You simply script the affected SP(s) for Modify and run the Alter statement, without changing anything. It corrects the values.
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!
Since SQL Server does not have a simple batch command line executor for the scripts the are auto generated from management studio, I created one.
The problem arises when delphi ado syntax and SQL Server syntax don't agree (BUT ITS THE SAME THING).
Well any how, the go I replaced with ;
Now as I declare a stored procedure alter, I hit a brick wall.
The script I'm running is :
ALTER Procedure [dbo].[procName]
as
Declare #param int
and the error i get is :
the arguments are from the wrong type,
out of range or collide with one
another.
(my free translation)
questions :
why is this happening?
what can i do to change this?
is there another udl based program that parse SQL scripts?
thanks.
edit: require login to the db with udl file.
could it be that delphi has problems with # ?
Since SQL Server does not have a
simple batch command line executer for
the scripts the are auto generated
from management studio, I created one.
Are you aware of SQLCMD ?? Seems like a command-line utility to execute SQL scripts to me... also: the SQLCMD utility has a number of additional enhancements that go beyond what the T-SQL scripts in SSMS can do.
Also check out:
SQLCMD reference
Using SQLCMD utility
Not sure about your SQL example above, but does the stored procedure actually have any parameters, or are you calling a variable inside the body #param? The usual syntax is:
ALTER Procedure [dbo].[procName]
(<#params here>)
AS
<body + variables here>
MSDN - Alter Procedure
removed the component and change the code from
ado.open;
to
ado.execute;//or something like this
solved it.
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 am trying to insert rows into a MySQL database from an Access database using SQL Server 2008 SSIS.
TITLE: Microsoft SQL Server Management Studio
------------------------------
ERROR [42000] [MySQL][ODBC 5.1 Driver][mysqld-5.0.51a-community-nt]You have
an error in your SQL syntax; check the manual that corresponds to your MySQL
server version for the right syntax to use near '"orders"' at line 1
The problem is with the delimiters. I am using the 5.1 ODBC driver, and I can connect to MySql and select a table from the ADO.Net destination data source.
The MySql tables all show up delimited with double-quotes in the SSIS package editor:
"shipto addresses"
Removing the double quotes from the "Use a table or view" text box on the ADO.NET Destination Editor or replacing them with something else does not work if there is a space in the table name.
When SSIS puts the Insert query together, it retains the double quotes and adds single quotes.
The error above is shown when I click on "Preview" in the editor, and a similar error is thrown when I run the package (albeit then from the actual insert statement).
I don't seem to have control over this behavior. Any suggestions? Other package types where I can hand-code the SQL don't have this problem.
Sorry InnerJoin, I had to take the accepted answer away from you. I found a workaround here:
The solution is to reuse the connection for all tasks, and to turn ANSI quotes on for the connection before you do any inserts, with an Execute Sql task that runs the following:
set sql_mode='STRICT_TRANS_TABLES,NO_AUTO_CREATE_USER,
NO_ENGINE_SUBSTITUTION,ANSI_QUOTES'
Try using square brackets around the table names. That may help.
EDIT: If you can, I would create views (with no spaces) based on the Access tables, and use those to export. Even if it means building another Access database with linked tables, I think this is your best bet.
I've always struggled with using SSIS with MYSQL directly. Even after installing the ODBC drivers, they just don't play well in data flows. I've always ended up creating linked ODBC connections between SQL Server and MYSQL. I then rely on linked server queries to bring over data. Instead of using a SSIS data flow task, I use an Execute SQL command, usually in the form of a stored procedure that executes an OPENQUERY.
One solution you could do is load the data into a SQL Server database and use it as a staging environment before you load it into the MYSQL database. I regularly move data between SQL Server 2008 and MYSQL and in the past I use to regularly move data between Access and SQL Server.
Another possible solution is to transform the incoming Access data before it loads into the MYSQL database. That may give you a chance to clean up the column names and the actual data that's going through to MYSQL.
Let me know if either of these work for you.
You can locate the configuration setting file my.ini at <<Drive>>:\ProgramData\MySQL\MySQL Server 5.6\my.ini and add "ANSI_QUOTES" to sql-mode.
e.g: sql-mode="STRICT_TRANS_TABLES,NO_AUTO_CREATE_USER,NO_ENGINE_SUBSTITUTION,ANSI_QUOTES". This should solve the issue while previewing in the SSIS editor.