Hi,
that option might work on client/server but is not an option on N-Tier. Die SDO client proxy (_cl.w für static sdos) does the foreign field lookup and merges them into the backend query (dataAvailable event procedure). By default this property is not replicated to the properties for the appserver half of the sdo.
You might try adding them to the list of properties replicated to the server (sdo-logic procedure _cl) and catch them in an openQuery override - using assignQuerySelection.
I faced problems a while ago and introducted my own custom properties instead of reusing the standard Properties (xForeignField, xForeignValues). I have no idea if those problems are solevd now.
HTH,
Mike
-Ursprüngliche Nachricht-
Gesendet: Dienstag, 6. Mai 2003 20:56
An: dev@dynamics.possenet.org
Betreff: Re: SDO on a temp table.
Have you tried setting a data link and mapping the
foreign fields between the SDOs? This would be the
"correct" method.
"Boisseau, Freddy" <FLB@smsgroup.com> wrote:
I am working on creating a SDO on a temp table. In
order for the procedure
that builds the temp table to work correctly I need
some information from
another SDO about the current record in the parent
SDO and also needs to
trap out when a row changes in the primary SDO. How
do I go about doing
this correctly?
>
To unsubscribe, e-mail:
dev-unsubscribe@dynamics.possenet.org
For additional commands, e-mail: dev-help@dynamics.possenet.org
=====
Rick Terrell
__________________________________
Do you Yahoo!?
The New Yahoo! Search - Faster. Easier. Bingo. http://search.yahoo.com
To unsubscribe, e-mail: dev-unsubscribe@dynamics.possenet.org
For additional commands, e-mail: dev-help@dynamics.possenet.org
To unsubscribe, e-mail: dev-unsubscribe@dynamics.possenet.org
For additional commands, e-mail: dev-help@dynamics.possenet.org
Hi,
there is an issue with the Values of the ForeignField/ForeignValues
properties being blank on AppServer:
http://www.possenet.org/issues/show_bug.cgi?id=10321
Until this is fixed, you have to either get the values from the
queryString by parsing it, or use your own properties as Mike
suggested.
Christian
that option might work on client/server but is not an option on
N-Tier. Die SDO client proxy (_cl.w für static sdos) does the
foreign field lookup and merges them into the backend query
(dataAvailable event procedure). By default this property is not
replicated to the properties for the appserver half of the sdo.
You might try adding them to the list of properties replicated to
the server (sdo-logic procedure _cl) and catch them in an openQuery
override - using assignQuerySelection.
I faced problems a while ago and introducted my own custom
properties instead of reusing the standard Properties
(xForeignField, xForeignValues). I have no idea if those problems
are solevd now.
HTH,
Mike
-Ursprüngliche Nachricht-
Gesendet: Dienstag, 6. Mai 2003 20:56
An: dev@dynamics.possenet.org
Betreff: Re: SDO on a temp table.
Have you tried setting a data link and mapping the
foreign fields between the SDOs? This would be the
"correct" method.
To unsubscribe, e-mail: dev-unsubscribe@dynamics.possenet.org
For additional commands, e-mail: dev-help@dynamics.possenet.org