Subject | Sub-Selects and calculated fields |
---|---|
Author | Herbert Senner |
Post date | 2002-02-18T19:02:10Z |
Hello all,
I am facing a problem when dealing with a query that has (a)
sub-select(s) (for lookups in details) and additionally
declared calculated fields. (W2K, D6P, FB 6.2.679, IBO 4.2.Fr)
If I want to post such queries after editing, inserting or deleting
an errormessage is raised that the key in the subquery cannot be found.
Nevertheless subsequently the dataset is posted and the changed
values in the row are stored in the table and displayed correctly.
A demo for this behavior can easily be created:
I used the Company Application in the IBO-directory. In the
qrEmp-Query I declared a calculated field "FOR_TEST VARCHAR(10)"
(The fieldtype doesn't matter; I tested it also with INTEGER).
Now changing the dataset brings up the Message
"Fieldname BRANCH.BRANCHID not found" when posting it.
Is there another way to avoid this message than not
to use calculated fields in queries with sub-selects?
Herbert Senner
I am facing a problem when dealing with a query that has (a)
sub-select(s) (for lookups in details) and additionally
declared calculated fields. (W2K, D6P, FB 6.2.679, IBO 4.2.Fr)
If I want to post such queries after editing, inserting or deleting
an errormessage is raised that the key in the subquery cannot be found.
Nevertheless subsequently the dataset is posted and the changed
values in the row are stored in the table and displayed correctly.
A demo for this behavior can easily be created:
I used the Company Application in the IBO-directory. In the
qrEmp-Query I declared a calculated field "FOR_TEST VARCHAR(10)"
(The fieldtype doesn't matter; I tested it also with INTEGER).
Now changing the dataset brings up the Message
"Fieldname BRANCH.BRANCHID not found" when posting it.
Is there another way to avoid this message than not
to use calculated fields in queries with sub-selects?
Herbert Senner