| Subject | Re: [IBO] Problem in BindingCursor: Check Keylinks property Problem Ver 4.9.11 |
|---|---|
| Author | Helen Borrie |
| Post date | 2011-09-08T21:32:46Z |
At 08:13 AM 9/09/2011, you wrote:
To do what you want to do you have a couple of choices:
1. Write the block as an executable SP (the most likely solution here);
or
2. Rewrite the whole thing as a DSQL statement of the form
insert into blah b select foo, bar,.... from foobar f
where b.foo = :bfoo
and b.bar = :bbar
(simplified, but you get the gist)
Either way, you can do it with IBOQuery's UpdateSQL property, if that's what you're trying to do. If you aren't doing it that way, use a TIB_DSQL. Yes, you can use it it combination with your TIBO stuff because it is a non-visual component. Its IB_Transaction and IB_Connection will hook up happily to your IBODatabase.
But Keylinks should not be too hard to understand....basically IBO needs a group of one or more columns *in the dataset* that uniquely identifies each and every row in the dataset can match up parameters accordingly in update and delete actions. The UpdateSQL uses this combination to establish the exact record on the server that is to be updated. If it can't identify that record, you get the Binding Cursor error. Unless your live dataset is from a *single* table AND contains the PK in its field list AND there is exactly one row in the set with that PK, make it standard practice to switch off KeyLinksAutodefine and supply the column list to KeyLinks.
Joinlinks is another thing entirely and only matters if you are using selects containing inner joins in the obsolete SQL-89 syntax, viz,
select (stuff...) from foo, bar where ....
You use joinlinks to identify which columns in the WHERE clause are the join criteria. Just don't use that syntax: use explicit joins and you can forget joinlinks.
Helen
>Hi,First of all, EXECUTE BLOCK is not a valid DSQL command. It's a clause that you can use in a SELECT statement to get a value for output to a dataset.
>Details
>Windows 7Pro 64Bit,
>Delphi XE,
>IBO Ver 4.9.11,
>Firebird 2.5.0.26074 (64Bit)
>
>I have a problem using the IBOQuery component, I am trying to run this SQL, if i load it into IBExpert it works perfectly, but when i load the following sql into my IBOQuery and then issue an IBOQuery.Execute it fails with the error "Problem in BindingCursor: Check Keylinks property"
>
>I have read posts from many years ago, but i cannot see what i need to put in the keyklinks field to fix this problem, as i dont want a result dataset back am i using the correct component?
To do what you want to do you have a couple of choices:
1. Write the block as an executable SP (the most likely solution here);
or
2. Rewrite the whole thing as a DSQL statement of the form
insert into blah b select foo, bar,.... from foobar f
where b.foo = :bfoo
and b.bar = :bbar
(simplified, but you get the gist)
Either way, you can do it with IBOQuery's UpdateSQL property, if that's what you're trying to do. If you aren't doing it that way, use a TIB_DSQL. Yes, you can use it it combination with your TIBO stuff because it is a non-visual component. Its IB_Transaction and IB_Connection will hook up happily to your IBODatabase.
>I have never understood the keylinks / Joinlinks fields and feel i need to take a day off to just understand where i have gone wrong.You're getting that error as a response to the BindingCursor problem. The IBOQuery won't know why it's failing to get a cursor that it can bind to the dataset fields because this PSQL block has nothing it could even guess about from referring to metadata.
But Keylinks should not be too hard to understand....basically IBO needs a group of one or more columns *in the dataset* that uniquely identifies each and every row in the dataset can match up parameters accordingly in update and delete actions. The UpdateSQL uses this combination to establish the exact record on the server that is to be updated. If it can't identify that record, you get the Binding Cursor error. Unless your live dataset is from a *single* table AND contains the PK in its field list AND there is exactly one row in the set with that PK, make it standard practice to switch off KeyLinksAutodefine and supply the column list to KeyLinks.
Joinlinks is another thing entirely and only matters if you are using selects containing inner joins in the obsolete SQL-89 syntax, viz,
select (stuff...) from foo, bar where ....
You use joinlinks to identify which columns in the WHERE clause are the join criteria. Just don't use that syntax: use explicit joins and you can forget joinlinks.
Helen