Luis,

At 02:13 AM 8/09/2007, you wrote:

>Hello again and first of all let me apologize for not signing my name
>in the last post, it was in fact rude of me!

You are forgiven. :-)

>In fact i think i really do need to use a SSP to get the data because
>there are some manipulations and validations on the data to be made
>and i find it quite impossible to do it directly on the SQL property,
>and also its easier to maintain the code on the server. That way i
>can just change the SQL code on the server and all the client
>applications reflect that same change. If i had the code on the
>application i would have to recompile and update all the clients. And
>with that comes alot of headhaches.

That is indeed where a SSP comes in useful - as long as you
understand that there is no way to reach the underlying data by
reference to the output fields of this contrived set.

>So basicly what you advising me to do, is to use some ESP on the
>UpdateSQL properties and inside that perform appropriate instructions.

Yes.

>So far so good. But i have on question, imagine the ESP as some
>output parameters, with error codes for examples, am i still able to
>return those parameters along with the SSP params?

I don't quite understand what you have in mind here. You will have
one stored procedure - a SSP - that returns a multiple-row set to the
client buffer. You will have one, two or three DIFFERENT procedures
- executable - that will accept input parameters linked in the client
to the output parameters of the SSP, i.e., to the fields you receive
when the SSP is executed.

Executable procedures return a single row of output. An ESP that
contains a FOR loop that returns multiple rows won't work - it will
cause an exception.

If you execute an ESP in its own distinct TIb_DSQL object, you can
read the RETURNS set after execution, by referring to the Fields[]
array of that object. The XxxxSQL properties of a TIb_BDataset are
actually TIb_DSQL objects embedded in the InternalDataset of the
TIBOStoredProxc InternalDataset is a TIb_BDataset, but I don't know
of any way to access the return fields of the embedded IB_DSQL
object. Jason might be able to enlighten on this to the contrary, however...

In practice, in any case, you should not be depending on stored
procedure output to verify whether or not an action has
succeeded. If an ESP fails to execute, and you don't handle the
error in your PSQL, the whole transaction will fail, including the
one that is creating the output for your dataset. A failed ESP does
not return output, it returns an exception. It is preferable for
your client code to anticipate the possible exceptions and handle
them as and when they occur.

> > Note, setting RequestLive has no effect whatsoever on non-updatable
> > datasets. IBO makes the dataset "live" if there are valid XxxSQL
> > statements provided.
> >
>
>Thanks for the hint because i thought that RequestLive was the
>property that made my data editable. (newbie)

What RequestLive does is to automatically construct prepared
statements for updatable sets, based on the KeyLinks of the
dataset. It can ONLY work on updatable sets. SSP sets and selects
with joins are not updatable sets...so RequestLive is limited to
natural selects on single tables. IBO *can* manipulate a set that
has only inner joins and make such a set "live" without XxxxSQL, by
targetting the automatic DML statements at one participating table
(see the help for the KeyRelation property).

>By the way Helen, let me compliment on your work on the Firebird
>Book, its a excellent book! Im been using it for some time, and it
>has been a precious help!

Well some day - when I win Lotto - there might be an IBO book as
well. Hope springs eternal! :-)

Helen