When creating a stored procedure in Informix, it does not throw an error even if the related table does not exist..
I guess the reporting level is pretty high so how can I change it?
That is the way Informix is designed to work.
If, when you run the procedure, the table still does not exist, then you will get a more or less appropriate runtime error. But the mere fact that a table does not exist at the time the procedure is created is quite deliberately not viewed as an error; the table may be created by the time the procedure is used.
There is no setting that I know of to change this behaviour.
Related
I'm creating Stored Procedures to replace Legacy app programs for an IBM i. I'm calling the stored procedure from a Java Web App. I'm using the jt400 JDBC driver
My JDBC URL is jdbc:as400://myhost/;libraries=*LIBL,MYLIB;prompt=false
The stored procedures can call stored procedures
The initial stored procedure call completes normally if it does not make further stored procedure calls
If the stored procedure makes a call to other stored procedures it fails with
com.ibm.as400.access.AS400JDBCSQLSyntaxErrorException: [SQL0204] MY_SP in MYLIB type *N not found.
If I hard code a schema in the stored procedure call statement, the call completes normally.
I want to have the called stored procedures use the same schema as the caller
You need to SET PATH = "MYLIB"
When I am using SQuirreL to call a stored procedure, I need to use the SET PATH statement to get it to find the stored procedure. I don't know if that is because my library list is bad or what, but the current schema is not used to find an unqualified stored procedure.
I actually had this same problem, the stored procedure uses your job description library list. You need to edit that you can use TAATOOL CHGLBLJOBD. I am not in front of an iSeries at the moment but I believe the command was either EDTJOBDLIB or EDTJOBDLIBL WRKJOBDLIBL. It is some variation of that.
I just wanted to know what is the best practice to create and execute a stored procedure.
I have seen like below:-
IF EXISTS (SELECT * FROM sys.objects WHERE type = 'P' AND name = 'Foo')
DROP PROCEDURE Foo
GO
CREATE PROCEDURE dbo.Foo
But I am thinking when we execute this stored procedure, it will drop the stored procedure and create a new one. But if there is error in the create stored procedure syntax, it won't recreate the stored procedure, right? So as a result our existing stored procedure is deleted and new stored procedure is not created. So what is the real reason for adding DROP here?
The reason is so that your scripts can be run in an idempotent way - they can be run as many times as needed, with the same result. Namely, your database will have the stored procedure you desire. Your procedure will be created, and dropped beforehand if needed. If you didn't do this, then you'd need separate drop and create scripts.
If you're concerned that your scripts have errors, well, fix them. Run your scripts a few times, and fix any problems that arise. The effort is worth not having to maintain separate sets of scripts.
BECAUSE it is execute in line by line manner so when it create procedure and then error comes and again you recreate that procedure then it gives error because it is already generated in your database with error code....
so for this it want recreate that procedure again.....
you can use alter instead of create....
Hope this help you...
I wrote a procedure to update a table by deriving its data from four other tables. The procedure itself works fine, but I need the table to be up to date all the time, so I call the procedure from triggers which fire, whenever one of the four tables ist altered.
This too works fine except for one detail. The procedure derives the data from the tables BEFORE the changes, so the update/delete/insert, which fired the trigger.
The trigger is rowlevel after u/d/i but even changing it to after statement did not help.
Not using a trigger is not really an option, because of the need being in sync. Changing it to a materialized view seems to be a good idea, but neede calculations are disallowed in those and nonmaterialized views are too slow, which is why I want to change it from a nonmaterialized view to a table.
Handing all information about what was changed in which way over to the procedure would be possible, but it would make the procedure so much more complicated, that I refrain from writing this code.
Is there any way to derive my table based on the new values directly triggered by a change in the four tables?
Regards
Ramin
I have a Tadocommand on my datamodule which is connected to a MSSQL storedproc. The storedproc is used to update a table.
In my code I call the the tadocommand in the beforeupdaterecord method of one of my Tclientdatasets.
first I supply values to the tadocommand parameters using the deltads.fieldbyname().newvalue of the Tclientdataset then I call the execute procedure. It works ok for the first update but if i try to do a next update it generates "error changing varchar to datetime".
if i dynamically create the tadocommand in the beforeupdaterecord method i.e
sp1_editcontract:=Tadocommand.Create(nil);
sp1_editcontract.CommandType:=cmdStoredProc;
sp1_editcontract.Connection:=DMDBconn.DBConn;
sp1_editcontract.CommandText:='EditContract';
sp1_editcontract.Parameters.Refresh;
//assign parameter values
sp1_editcontract.execute;
sp1_editcontract.free;
it works without any errors. I think there is some problem with the parameters values when using the static Tadocommand on the datamodule.
why does multiple update generate an error when using a static created tadocommand and not for the dynamically created tadocommand?
I'm going to assume you are referring to TDatasetProvider.BeforeUpdateRecord and not TClientDataSet.BeforeUpdateRecord.
Its kinda hard to say from the information you've provided (you don't indicate the data types or order of the arguments for the stored procedure). The error message is coming from the SQL Server engine. I would make sure the values being assigned to the parameters are always being set in the correct order. Also try to identify which parameter is causing the error. If you can reliably reproduce it in your client code you may try calling the stored procedure in SSMS passing the same values that are causing the error in the client application.
Once you identify the parameter you can check that its datatype is consistent between the ADOCommand, DatasetProvider and ClientDataset. If it changes type along the way that may be the cause of the error.
One last suggestion, make sure you set TDatasetProvider.Applied := True before exiting the BeforeUpdateRecord handler. This prevents the dataset provider from trying to apply the update using dynamic sql after you've already applied the updates. If the data in the client dataset was populated by a TADOQuery it may be attempting to update the tables directly.
I had a similar problem. In order to clear all the existing parameters of the ADOCommand before adding new ones a used the following code:
while Command.Parameters.Count>0 do
Command.Parameters.Delete(0);
Parameters.Clear should had worked, but it didn´t, so I decided to remove the parameters one by one. That fixed to me.
I have a stored procedure that uses table variables to create a query and runs perfectly when executing in SQL Server Management Studio. However, the column referring to this table variable does not display when running the stored procedure in Query Designer.
I have used this method on many other reports without issue, but cannot figure out why the value will display in SSMS and not in SSRS.
After a fresh nights sleep, I realized it was how a parameter was being passed to the Sub Stored Procedures. The main stored procedure had a where clause that contained a "LIKE #Parameter" but the Sub Stored Procedure contained an "= #Parameter", so when a "%" was passed into the parameter the main Stored Procedure returned results, but nothing was displayed from the Sub Stored Procedure.
Simply just a case of making my job harder on myself...