Subject | Re: [IBO] mystery with ParamByName |
---|---|
Author | Helen Borrie |
Post date | 2004-11-16T12:39:21Z |
At 11:59 AM 16/11/2004 +0000, you wrote:
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.
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.
suspect that the problem will be found there.
problem, plus the declarations for all four procedures.
Helen
> > The info you provided here is inadequate to advise you about what'sOh-oh - so I see - the field that you have as a calculated field is
>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.
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,It shouldn't be.
>SoID is PK and set as keylinks. TuID is declared as calculated field.
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 asNo, it should NOT be declared as a calculated field.
>calculated field - it's only a argument to SP?
>I commented calculated field TuID declaration with the insert/deleteShow the SP exactly as it is defined; and show the DeleteSQL statement. I
>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.
suspect that the problem will be found there.
> > There isn't much information provided...but possibly you are using setsAt this point, it's not necessary, except for the one that is causing the
>
>I could provide detailed SSP (uses several joins to return SoID) text
>with the involved table structure if needed.
problem, plus the declarations for all four procedures.
Helen