Subject Re: [IBO] mystery with ParamByName
Author Helen Borrie
At 11:59 AM 16/11/2004 +0000, you wrote:

> > The info you provided here is inadequate to advise you about what's
>going
> > on...but if SoID is not returned as a field by your SSP then it is not
> > valid as an input argument to your xxxxSQL statements.
>
>Helen, what additional info is needed?
>SoID is returned as a field by SSP, so I guess SoID must be valid as
>an input argument.

Oh-oh - so I see - the field that you have as a calculated field is
TuID. So there will be the same problem with your xxxxSQL, but it means we
still have to look for the cause of the SoID not found error.

Inadequate information is that you don't provide the declarations for the
SPs and you show your dataset SQL as "Select * from..." That isn't useful
when you want people to help you find a problem with a missing field.


>SoID isn't declared as calculated field - it's returned by the SSP,
>SoID is PK and set as keylinks. TuID is declared as calculated field.

It shouldn't be.

If you need to manufacture a fake key for masterlinking the set, provide it
inside the stored procedure, so that it gets returned as part of the
set. And make quite sure that each row is distinguishable as a child to
the master structure, *apart* from this fake key.


>SoID is returned as a field from the SSP.

OK.

>Correct me, if I understood wrong: TuID isn't needed to be declared as
>calculated field - it's only a argument to SP?

No, it should NOT be declared as a calculated field.

>I commented calculated field TuID declaration with the insert/delete
>SP. No errors until I uncomment for example delete SP and try to set
>DeleteSQL SoID argument: qry->ParamByName("SoID")->Assign(...) - error
> SoID is not found.
>How this could be? if SoID is not calculated field, it's returned from
>the SSP, so SoID must exist and bind.

Show the SP exactly as it is defined; and show the DeleteSQL statement. I
suspect that the problem will be found there.



> > There isn't much information provided...but possibly you are using sets
>
>I could provide detailed SSP (uses several joins to return SoID) text
>with the involved table structure if needed.

At this point, it's not necessary, except for the one that is causing the
problem, plus the declarations for all four procedures.

Helen