hi,
thanks for the information. just to confirm your assessment, we modified the queries to no longer use select from (select ...) and haven't been able to produce the bug since. thanks and best regards, robert > > After some mailing and sending some log-files out of the mailing-list > it was found out, that the problem is the combination of select in the > from-clause of another select plus the usage of a complex view, for > example: > > create view vcomplex as > select distinct ta.a2 > from ta,tb > where ta.a1 = tb.b1 > > ( because of the DISTINCT the view is a complex view, see: > http://www.sapdb.org/htmhelp/c7/12ffd406ab11d3a97d00a0c9449261/frameset.htm > ) > > and some from-select (select in the from-clause) using such a complex-view, > for example: > > SELECT * > FROM tc, (SELECT * > FROM TB, vcomplex) fromsel > where ... > > Then an intermediate info is not destroyed where it should have been > destroyed and another poor statement will find out that this special info > is on disk and in cache unexpectedly. Therefore the statement finding this > is not guilty (making it a little more complicate to find the reason of the > behaviour) but is the victim. > > Until bug-fixing one has to avoid this combination, perhaps by using a > from-select in the final select instead of the complex view or changing the > complex view to a NON-complex-view. Other hints given before are not true > any more. > > Thank you for reporting (and trying such fine combination) and sorry for > the inconvenience. > > Elke > SAP Labs Berlin > _______________________________________________ > sapdb.general mailing list > [EMAIL PROTECTED] > http://listserv.sap.com/mailman/listinfo/sapdb.general _______________________________________________ sapdb.general mailing list [EMAIL PROTECTED] http://listserv.sap.com/mailman/listinfo/sapdb.general
