I am trying to call a stored procedure in SSIS OLE- DB DataSource (My Datasource would be SQL Server 2012).
I tried a procedure call SQL statement under SQL Command option but when I click the preview button I am getting an error.
Please guide me how to resolve this error. I goolged but nothing works for me.
I think the issue you are having is in SSIS often takes the first Select statement it finds and tries to validate it for column names, this happens especially with very big procedures. The trick I have found to get this to work is, right off the bat throw something like :
IF 1 = 0
Begin
Select all columns you want
END
This code will never get execute but it hints SSIS to make those columns the ones in the data flow. Just be sure to update this list as you update your last select.
Related
I have a Microsoft Access frontend database that interfaces with an Oracle backend. I have a variety of PL/SQL procedures that get triggered through processes in the application and I have never had an issue like this. This particular procedure does not seem to execute some of the DML statements in the procedure when the procedure is run through the app (the Access database interface); HOWEVER, when I run the same procedure from my SQL Developer environment it runs perfectly every time. More specifically, it does not seem to execute some delete statements that I have in the procedure despite the fact that I have COMMIT after all of them.
Here are a few other details that may be making the difference:
The table that gets modified by the PL/SQL procedure initially gets data from a SQL Loader replace job that moves data from the client back to this staging table
This stage table has an auto increment primary key that is created from a before insert trigger on the table. There does not seem to be any issue moving records back to this table with SQL Loader or any kind of integrity constraint failure. This all happens in the application BEFORE the stored procedure is called.
This particular table is also linked through the ODBC connection in the Access database, as it is used by a bound form after the above procedure is run. I have tested to see whether the form is just somehow not reflecting the data in the backend table, but it is correctly reflecting.
Again, if I run the process in the application I get the incorrect results. Immediately after I do this I run the same exact procedure from my SQL Developer and it corrects it every time.
So I believe I finally figured this out. The issue was a timing issue between SQL Loader moving the data back to the Oracle staging table and the PL/SQL procedure getting triggered in the application. Since I have a trigger before insert on my stage table in this case, I could not use direct load (direct = true) in the bat file that kicks off my SQL Loader job. As a result, the records take longer to move to the backend and in this case my PL/SQL procedure was getting triggered prior to all of the records getting moved to the staging table. This explains the intermittent nature of the problem that was driving me nuts. I solved it by making sure the record counts in my delimited file that SQL Loader was moving back matched the record count on my stage table before I triggered the procedure to run. Lesson learned.
I'm working on several reports for SSRS written in MySQL via ODBC Adapter. For some reason, Stored Procedures only return a single row of data instead of an expected set of data.
Below is the same stored procedure when ran on an SQL Editor:
And below is the stored procedure's execution result when SSRS tries to run it (both on Query Designer and Report Viewer):
I have also set parameters properly as far as i can tell:
so i wasn't able to find an exact answer as to why this happens on SSRS with MySQL via ODBC. What i was able to find was a workaround:
by executing the command as an Expression rather than as a raw query via the Query Editor:
Now the only caveat for this is that the DataSet Fields wouldn't be automatically generated, and that you have to plot them all manually. A good workaround for this is to first run a blank/null query with only the column names (i.e.: SELECT NULL 'column_name_1', NULL 'column_name_2') then later change the query source to Expression. The good thing about using expression is that you only need minor knowledge about how it works and it reduces the confusion with ODBC '?' Parameters.
Cheers!
I am just getting started in SSIS for SQL Server 2016. I am trying to simply DROP TABLE before I create a new one, and I am using an Execute SQL Task as a first step before the Data Flow task to create the new table. I am getting an error that the object does not exist. It seems like this would be a very common thing to do in SSIS, and I have been reading through many SO posts on this particular task, but so far nothing on how to ignore an error. I was expecting to see a property for Execute SQL that allows ignoring errors, or an error connector, or something similar. Is there something in this task I missed, or is this the wrong way to make sure a table does not exist before trying to create a new one?
You could use drop if exists syntax inside EXECUTE SQL task:
DROP TABLE IF EXISTS tab_name; -- supported starting from SQL Server 2016
Alternatively, Change the Control Flow Arrow from Success to Completion:
Right Click the Green Arrow coming from the Execute T-SQL Task that drops the table.
Click Completion. Arrow will turn to black.
I am getting the following message while creating a stored procedure in MySQL Workbench:
"Review the SQL script to be applied on the database"
I have several tables inside the database but the stored procedure I am writing will be
used only for one table. Since, the SQL script of stored procedure is gonna apply on the whole database, I am wondering if it's gonna affect other tables as well? I don't want other tables to get disturbed because of this script.
Please provide your inputs as I am doing this for the first time.
Question #2:
Why do I see "DELIMITER $$" as the first statement while creating a routine before the following statement?
CREATE PROCEDURE `mydatabase`.`myfirstroutine` ()
BEGIN
Thanks
1) MySQL Workbench offers the option to review the generated SQL script before it is sent to the server. This way you can check it for possible problems.
2) The DELIMITER command is usually necessary to switch the current delimiter that ends a single statement (which is by default a semicolon) to something else because the stored procedure code itself needs the semicolon to separate individual commands. However the sp code must be sent as a whole to the server.
A few more details: the DELIMITER keywword is a client keyword only, that means the server doesn't know it and doesn't need it. It's an invention for clients to properly separate sql commands before sending them to the server (you cannot send a list of commands to a server, only individual statements).
In MySQL Workbench however, especially in the object editors where you edit e.g. the sp text, adding the DELIMITER command is essentially nonsense, because there's only this sp code, hence nothing to separate. This might disappear in future version but for now just ignore it.
We have a SSIS package that calls a stored procedure through an EXECUTE SQL TASK component. The stored procedure contains a LOT of different pieces of sql code that gets build dynamically and then executed via exec strSQL within the stored procedure. The whole system is built that way and we cannot redesigned at this point. The problem is that when something fails within the stored procedure is hard to figure out from SSIS what SQL statement from the stored procedure caused the exception/failure. What we have right now and is working is the package onError event with code to read the System::ErrorDescription which is helpful to display the error in SSIS and then send an email with the error, this is working. What I'm looking for to add is to have a System Variable or some other way to display the actual SQL (the one that caused the exception within the stored procedure) in SSIS to I can include that in the email. Any ideas? Thanks.
I have a solution. Table variables are not roled back in a catch block and rollback statement.
So put the sql statements before they run into a table varaible with an nvarchar (max) datatype. Make sure your proc uses try catch blocks and transactions. In the catch block, perform a rollback if need be and then insert the contents of the table variable and a datetime to a logging table. NOw you have a record of exactly what queries were run. You can also create a separate table varaible to store the data you are attempting to insert or update if that is also an issue.
When you run a package by using F5 and a SQL statement fails you can check the execution results tab, but unfortunately this only shows the first line or two of your SQL statement.
Instead of running the package by using F5, run it using Crtl+F5. This will open a terminal window and run the package as though it was called from the command line. As each task runs it will output log information, if the task uses a SQL statement and it fails it will output the full SQL statement.
Ctrl+F5 is called 'Start Without Debugging' yet I always think it is a better to debug a package.