Thanks for your response(s) Markus. Very enlightening, and it makes a
lot of sense. I will have to try that (the DELETE with subquery) to
see how it responds... Probably very similar to MaxDB.
Wayne
On 10/14/06, Markus KARG <markus.karg_at_gmx.net> wrote:
> Wayne,
> > I won't claim to be a SQL spec guru, but it seems like this should be
> > OK... I'd expect the identity params would be internally removed by
> > the sql planning tools etc before the select is performed against the
> > table, so in effect, they would have no effect at all on the sql
> > results.
>
> regarding my assumption that the problem is the need to update the
> cached subquery result: This seems to be true actually, since I found a
> tip in the MaxDB manual how to handle updates on DELETE with subquery:
>
> "In the case of the correlated subquery, the desired effect can be
> achieved by generating a named result table which is then used in the
> subquery."
>
> So if MaxDB wants us to temporarily store the result on our own, the
> problem actually seems that MaxDB is unable or unwilling to store the
> result on their own. Seems my assumption is true.
>
> Markus
>
>
>