As you can see in the image bellow, my SQL Stored Procedures, somehow, my SQL Server opens Procedures like Unicode SPs.
That was not the case before, and I have no idea how this apeared now.
I have around 5.000 stored procedures so there is no chance I can edit it manualy.
My SPs starts from ALTER PROCEDURE , everything before that is somehow added.
Your SP's will still work just fine. This is just the way SQL Server Management Studio scripts the objects when you want to generate ALTER- or CREATE-statements.
To change this behavior, go to Tools > Options > SQL Server Object Explorer > Scripting
Set the option "Include IF NOT EXISTS clause" to "False".
(In other versions of SQL Server Management Studio the option might be called something like "Check for object existence")
As previously answered, changing the scripting option "Include IF NOT EXISTS clause" to false solves the problem. To add context, if this value is true, it has to be scripted by putting the entire Alter Procedure statement in an #statement variable, because the conditional logic associated with the check for existence requires the ALTER PROCEDURE statement be inside a BEGIN/END block, which is not allowed. So Microsoft's workaround is to put the entire ALTER PROCEDURE statement in the #statement variable, which is executed conditionally inside a BEGIN/END block.
Related
I need to execute a script (Informix code) in a .sql file for migration purposes. The thing is, I want to load it from a function to be able to use the exception, therefore being able to do a rollback in case of an error.
So, this is the code (still experimenting):
DROP FUNCTION IF EXISTS "informix".SCRIPT_MIGRATION();
CREATE FUNCTION "informix".SCRIPT_MIGRATION()
RETURNS BOOLEAN as RESULT;
DEFINE lv_execute lvarchar(32739);
DEFINE li_errnum, li_eisam INT;
DEFINE lv_errtxt CHAR(200);
ON EXCEPTION SET li_errnum, li_eisam, lv_errtxt
ROLLBACK;
CALL regista_log('script_migration', get_session_user(), li_errnum, lv_errtxt);
RETURN 'f';
END EXCEPTION;
CALL set_isolation_level();
BEGIN;
LET lv_execute = 'LOAD FROM ''C:\Users\Admin\Desktop\ConstaWeb_Stuff\test.sql'' DELIMITER ''+'' INSERT INTO SCRIPT_MIGRATION_TEMP_TABLE;';
DROP TABLE IF EXISTS SCRIPT_MIGRATION_TEMP_TABLE;
CREATE TABLE SCRIPT_MIGRATION_TEMP_TABLE(
STRING_TO_EXECUTE LVARCHAR(31739)
);
EXECUTE IMMEDIATE lv_execute;
COMMIT;
RETURN 't';
END FUNCTION;
CALL SCRIPT_MIGRATION();
That's because we apparently can't execute the load command inside functions. So I'm trying to execute it. But I'm not getting it right, apparently...
The objective here is to execute the script (not a shell command script! it's an Informix script, like creates, loads, unloads, drops...) on a file. I'm open to other ways of doing this.
I'm relatively new to Informix so I'm sure there is still a lot I don't know about it.
As already noted, the LOAD command is not a command recognized by the Informix server. Client products emulate an SQL statement by recognizing the syntax and reading the file and executing appropriate SQL statements. Changing the way you (try to) execute it in a function executing in the server will not help.
Using a shell script instead may help.
If you're migrating an existing Informix database to a new location (machine, version of Informix), then using DB-export and DB-Import may be a good way to go.
The DB-Access command is the 'standard' way to execute scripts from a shell script. You'd need to ensure you set the DBACCNOIGN environment variable to 1. That will then stop if there's an error during the LOAD and rollback the transaction. There's also the DB-Load command, but it will be harder to rollback DDL statements since it does not handle those.
Alternatively, you might find my SQLCMD* program useful — though it too isn't perfect. However, unlike DB-Access, it allows you to control which statements can generate errors that are ignored and which are not (continue [on|off|push|pop]; before and after as appropriate).
With careful packaging, you can use it to create your migration, assuming the DB-Export and DB-Import won't do the job for you automatically.
* You may have to subscribe to the IIUG to get at this. The registration is not onerous, and neither is the email load.
I am working on an existing SSIS package to add custom logging to it. I am trying to test it, and I have an Execute SQL Task that I didn't create that is getting the following error.
Executing the query
"ap_pfl_DropProfileTables"
failed with the following error:
"Could not find stored procedure 'ap_pfl_DropProfileTables'.".
Possible failure reasons: Problems with the query, "ResultSet"
property not set correctly, parameters not set correctly, or
connection not established correctly.
I have no idea why I'm getting this error because:
I didn't create this or change it and this package is running without error in production.
The stored proc just truncates two tables. It doesn't have a result set or parameters.
The connections are working properly because this stored proc runs at the same time as another thread running a data flow task which runs successfully and uses the only two connections in this package.
I've double and triple checked the database to make sure the stored procedure is there and spelled correctly. I even checked the case of the letters in the stored procedure.
Any ideas on how to fix this?
I know this is an old thread but I have just run into this issue when using SSIS on SQL 2008 R2.
For me with an ADO.NET connection, I actually had to set IsQueryStoredProcedure to False and then the error went away. It didn't matter whether I used EXEC or not.
Yes this is frustrating - but Do-able. The key is to NOT use ADO.NET connection manager but instead use the good old fashioned ADO connection manager. The 2nd key is to NOT use EXEC or EXECUTE in the SQLStatement property of the Execute SQL Task editor. Just type in the name of the stored procedure (also for good measure use the 3-part name convention database.schema.storedprocedure. )
I haven't tried this with params on the stored procedure. Also, I have not tried this with the OLE DB connection manager.
I ran into this myself, and here is what I did (with the ADO.NET connection)
In the SQLStatement field I put the name of my stored procedure (dbo.myStoredProc).
I then set the IsQueryStoredProcedure property to "True"
I'm thinking that when IsQueryStoredProcedure is set to true the object automatically prepends EXEC to identify that the command is a stored procedure call.
After having the same issue I did some investigation on this:
Specifically my situation is:
I need to use ADO.Net because I am running against SQL Azure
I want to capture the stored procedure return value
First I tried this:
In SQLStatement I put the proc name (without EXEC)
myschema.MyProc;
In IsQueryStoredProcedure I put False
In ResultSet I put None
In the Parameter Mapping tab I put
Variable Name Direction Data Type Parameter Name Parameter Size
User::MyVariable ReturnValue Int32 0 -1
This runs without error, but does not capture the return value.
I assume if you set IsQueryStoredProcedure to true, it should wire all this up properly. But it returns an error instead.
This https://technet.microsoft.com/en-us/library/cc280502(v=sql.110).aspx, says for capturing the return value when using ADO.Net"Set IsQueryStoreProcedure is set to True". But it returns the error that is the OP
As a workaround I did this:
DECLARE #R INT
EXEC #R = MySchema.MyProc;
SELECT #R
I left IsQueryStoredProcedure as False
I set ResultSet to singlerow
I removed the parameter mappings and instead mapped a resultset:
Result Name Variable Name
0 User::MyVariable
There are several questions on StackOverflow that seem to have answers that contradict each other on the subject of ADO/OleDB, delphi TADOQuery/TADOCommand and the subject of parameters.
Parameters can be introduced two ways, in the CommandText or SQL property of an ADO component. Named parameters, which work most of the time for me, are introduced with colons:
select a, b, c from bar where bat = :baz
This works, 99% of the time for me, just fine. Every now and then I find that ADO or Delphi's wrappers around it, won't accept ":baz" and requires that I write this instead:
select f, g, h from bar where bat = ?
This results in an unnamed parameter, instead of a named parameter. When an ADO Query or ADO Command contains only one parameter, this isn't a big deal. But that's not when ADO acts up on me. Yesterday it acted one way, and today, a different way with a dual-command in a single TADOCommand object, like this, with two commands in one CommandText string:
delete from bar where id = :id1
delete from bat where id = :id2
I had to change it to this:
delete from bar where id = ?
delete from bat where id = ?
It worked all day yesterday. Today, I had to change it back to the first version, to get it to work. The symptom was that the ADO parameters disappeared and would not come back, and when I try to execute the command I get an error, index out of range, when I try to access Parameters[0]. Nothing gives me any warning that the parameters are going away. It seems that a few connections to the ADO dataset, at designtime, jogs the TADOCommand component, in particular, and it "just breaks on me". It is particularly maddening when you're trying to write a query or a command, and you know it works, but the ADO component has decided not to accept "?" or ":x" right now. You can get around its total inability to function by switching from one to the other. But it frustrates me, and probably actually completely blocks other people. I know some people always dynamically build their SQL in code, and avoid using Parameters, and maybe this is why.
Possible answers to my question that I'm anticipating are:
ADO doesn't support multiple commands, or at least Delphi's wrappers don't. Or maybe TADOCommand just doesn't work reliably here.
Parameters are a buggy area in all of ADO, or all of Delphi's ADO wrappers?
You're doing it wrong.
I'm using Delphi XE2, but I've seen similarly dodgy behaviour in 2007, 2009, 2010, and XE.
I'm using Microsoft OLEDB Provider for SQL Server as my OLEDB Provider.
Named parameters with :? I always used it with #, even on Visual Studio (ADO.NET).
And in T-SQL parameters and variable are prefixed with #.
Do not remember having problems with that... Are you sure you doesn't choose Native Client
(installed with an SQL server client install) instead of OLEDB Provider for SQL Server (which
comes with Windows)?
Unfortunately, I've not used Delphi in awhile, so, and I don't have the means to validate this answer from the Delphi perspective.
This is the first time I've seen named parameters prefixed with a colon (:). Usually, in ADODB, the named parameters are prefixed with an at (#) and, yes, unnamed parameters are given with a question mark (?).
One significant advantage of named parameters is their ability to be reused, i.e.
INSERT INTO TABLE T VALUES (#id, #id, 'Hello World');
At the ADODB level. Once you used parameters, either named, or unnamed, you can use CommandText.Parameters.Refresh as a fast means of creating the parameters.
Yes there are some cases where parameters with ? fail. I have found sometimes I need to use :named parameters. Named parameters have an advantage for working with the DB Parameter values, since having the Name property set makes debugging the ADO query or dataset or table easier as well.
I do not understand why. If you have this problem, first check you are using the correct OLEDB provider, and check what version. Also check for potential parsing errors caused by bad SQL generated by you.
I suspect that an internal behaviour inside the OLEDB provider in code that I do not have source code for is to blame for this quirk. The Delphi ADO class wrappers are translators from Delphi's database component layer architecture to ADO's core query/table/dataset APIs all of which are under the hood wrappers around a set of COM objects that deal with ADO RecordSets.
How could we know which WLM job has picked my DB2 stored procedure call invoked. I see some set of jobs are running with DB2XWLM* where DB2X is database region. But how to check which particular job had taken my stored procedure call.
Hope I made clear, please let me know if something is not clear. Appreciate your interest.
By giving few 'unique display statements' in the Stored procedure and by making the display statements on , we can check which WLMjob has picked the Stored procedure.
Typically a stored procedure is assigned to a region when it's created.
If you are able to see the DDL for the CREATE PROCEDURE statement (perhaps through DB2 admin tool), there should be a line like:
WLM ENVIRONMENT DB2SP3
DB2SP3 would be the environment your stored procedure lives in. I'm not sure that it always works this way, but it's worth checking.
Go to the job output where you can see display statements of your SP. That JCL has WLM specified. Just search for WLM word and you can find it.
I realize this is an old post but here is the answer for future reference:
select schema ,owner ,name ,WLM_ENVIRONMENT
from SYSIBM.SYSROUTINES
where schema = 'yourschemaname'
and name = 'yourSPname'
WLM_environment is the column you are looking for.
(db2v11)
I would like to test a DB2 stored procedure running on an AS400 system.
I have the IBM System i Access for Windows installed and can run SQL commands against the DB2 database.
My question is: What is the syntax to execute a stored procedure that takes in a parameter and returns a result as an output parameter and print the value to the screen?
Just to clarify: I am not asking how to call the proc in code. I want to execute the proc and see the results in the gui tool (which is similar to SQL Enterprise Manager).
use the keyword call and pass in the parameters.
call myStoredProc(parm1, parm2, ?);
for more details see here http://www.ibm.com/developerworks/data/library/techarticle/dm-0503melnyk/. The interesting part is Figure 5. Using the Command Editor to call an SQL procedure
What you want is possible. I have done it myself many times. Unfortunaly, I'm not at the office right now so it must be from the top of my head.
Start System i Access
Go to your iSeries icons and log on to the one where your stored procedure lives
Go to the databases icons and connect to the correct one (you've one local and probably one or more remotes)
Only then, you will see the option "run SQL script" at the bottom of your screen
Start that option and you will see a SQL editor (editor on top, viewer/messages at the bottom)
Remember that you are already connected to the correct iSeries but your JDBC request will get the *LIBL of the userprofile of your connection. Therefore you must know the schema (iseries library) of your stored procedure
Enter "call YOURSCHEMA.YOURSTOREDPROCEDURE(?,?);" and use the menu or shortcut to run that statement. Notice that - depending on your JDBC settings (see menu) - the correct syntax may be "/" instead of ".". Also, notice that you can replace the first question mark with a value.
On an additional note,
In iAccess, under every schema you will see icons for the tables, views and so on. Also an icon for stored procedures is available. You will see your SP there. Use the options to see the definition and so. This information includes detailed information about the parameters
If you want to check that on your iSeries, use the system catalog (this can be done from the SQL editor too) with "select * from qsys2.sysprocedures where procedure_name (sorry, not sure about the name of this column right now) = 'YOURSTOREDPROCEDURE';"
VERY IMPORTANT: I was never able to test the SP with the SQL editor (STRSQL) on the iSeries itself. Only the iAccess SQL editor did work correctly.
You should be able to run your SP like this:
DECLARE
usr_in YOUR_TABLE.YOUR_COLM%TYPE; --Gets the correct type by looking at column type
app_in YOUR_TABLE.YOUR_OTHER_COLM%TYPE;
BEGIN
usr_in:='some value';
app_in:='another_value';
YOUR_SP_NAME(usr_in, app_in);
END;
Or you can use EXECUTE, but it can't be dynamically prepared (not run in Java) and I think there's some other disadvantages.
EXECUTE myStoredProc(parm1, parm2, ?);