Subject Re: [IBO] Problem in binding cursor?
Author sgharp
--- In, 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
> >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
> apparently not unique in the xMajor table, giving rise to mulitple
> rows having the same MajorID + GroupID. So include the PK of the
> table in the query output and add it to the Keylinks as well; and
> it as an input parameter for the InsertSQL. Unless there is more
> 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
> 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


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.