--- In IBObjects@yahoogroups.com, Helen Borrie <helebor@t...> wrote:

> At 08:56 PM 10/09/2004 +0000, you wrote:
>
> >Hi All,
> >
> >I'm using a TIBOQuery's DeleteSQL property to delete a record and
> >getting the error "Problem in BindingCursor". The systax of the
> >DeleteSQL is
> >
> >execute procedure spUpdateMajorSetup
> >(:MajorID, :MajorName, :GroupID, 'Y');
> >
> >where it's calling a stored procedure. The stored procedure works
> >fine in IBExpert.
> >
> >The SQL statement for the query is
> >
> >select ma.MajorID, ma.MajorName, ma.GroupID, gr.GroupName
> >from xMajor ma
> >join xGroup gr on gr.GroupID = ma.GroupID
> >where ma.MajorID = :MajorID
> >
> >My KeyLinks is set to xMajor.MajorID which is the primary key of

the

> >xMajor table.
> >
> >The strange thing is that I'm using essentially the same type of
> >process with another query object and a different (but similar)
> >stored procedure in another part of the program and it works fine.
> >
> >What am I missing?
>
> The Keylinks here have to be enough to uniquely identify each row

in the

> set. MajorID is not enough, since multiple rows will potentially

have the

> same MajorID. Adding GroupID is not enough either, since GroupID

is

> apparently not unique in the xMajor table, giving rise to mulitple

output

> rows having the same MajorID + GroupID. So include the PK of the

xGroup

> table in the query output and add it to the Keylinks as well; and

include

> it as an input parameter for the InsertSQL. Unless there is more

that

> you're not telling, that should be sufficient to uniquely identify

the rows

> that the DeleteSQL's parameters will target.
>
> Note, you don't have to display xGroup's PK - you can set its

Visiible

> ColumnAttribute to False.
>

Since the MajorID is the primary key for the xMajor table, it
uniquely identifies a record (see the where clause). The GroupID is
the primary key for the xGroup table. I've changed the query to

select ma.MajorID, ma.MajorName, gr.GroupID, gr.GroupName
from xMajor ma
join xGroup gr on gr.GroupID = ma.GroupID
where ma.MajorID = :MajorID

which is almost the same as it was. I've changed the KeyLinks to

xMajor.MajorID
xGroup.GroupID

Again, these are the primary keys for both tables involved in the
query although the only one needed to uniquely identify a record is
the xMajor.MajorID.

I'm still getting the same error.

Steve