Subject | Re: [IBO] Error executing sp |
---|---|
Author | Helen Borrie |
Post date | 2004-06-06T22:56:35Z |
At 10:27 PM 6/06/2004 +0000, you wrote:
show us what your apps are doing with them.
because the cursor has reached the end of the set. That's the tool
itself: the DSQL tab can only handle executable statements or select
statements that return singletons (like SELECT MAX() or a select on
rdb$database. So it performs a NEXT on the result to check that the result
is a singleton, and permits it if it gets that errorcode back. You can
write exception handlers like that yourself...
Just run the SP in the DSQL tab and read the result in the Fields
tab. That is what your applications will see. If you don't see a modal
exception *DIALOG* in IB_SQL then you know that the statement works.
Get interested in the exception codes that show up in the monitor if *your
statements* are throwing exceptions.
So - your SPs are good to go.
Helen
> >You said that your executable SPs don't work in your apps. But you won't
> > That exception is a DSQL error...all of your procedures work on my
>setup
> > and don't return any exceptions. You're getting a result back,
>right? So
> > apparently the SPs are executing and then something is happening
>afterwards
> > that's causing this exception.
> >
> > So let's see the code: the exact SQL statement, your app code that
>calls
> > it and your app code that reads the result. Not a vague
>description, but
> > actual code.
> >
> > Helen
>
>Sorry, I really can't follow you when you reduce all my info as being
>vague.
show us what your apps are doing with them.
>I repeat myself:Oh, that! All that is, is IB_SQL calling FETCH NEXT and there is no NEXT
>
>SET TERM ^ ;
>/* Connect using username: SYSDBA */
>/* and server: WI-V6.3.0.4306 Firebird 1.5 */
>SET SQL DIALECT 3^
>SET AUTODDL ON^
>CREATE DATABASE 'D:\TEST.FDB'
> USER 'SYSDBA' PASSWORD 'masterkey'
> DEFAULT CHARACTER SET UNICODE_FSS^
>
>CREATE PROCEDURE SP_3
>RETURNS (
> ACCOUNTID INTEGER )
>AS
>BEGIN
> ACCOUNTID = 1;
>END^
>
>COMMIT^
>
>/* - - - - - - - - - - - - - - - -
>List of possible problems detected
> - - - - - - - - - - - - - - - - -
>None
>- - - - - - - - - - - - - - - - */
>
>Connect with IB_SQL, check all monitor groups, run SP_3 in the DSQL
>tab (EXECUTE PROCEDURE SP_3), and have a look at the monitor output.
because the cursor has reached the end of the set. That's the tool
itself: the DSQL tab can only handle executable statements or select
statements that return singletons (like SELECT MAX() or a select on
rdb$database. So it performs a NEXT on the result to check that the result
is a singleton, and permits it if it gets that errorcode back. You can
write exception handlers like that yourself...
Just run the SP in the DSQL tab and read the result in the Fields
tab. That is what your applications will see. If you don't see a modal
exception *DIALOG* in IB_SQL then you know that the statement works.
Get interested in the exception codes that show up in the monitor if *your
statements* are throwing exceptions.
So - your SPs are good to go.
Helen