Drew Jensen wrote:
Hello,
Using XP, OO.o 3.0.1 RC2 and SRB 1.0.9 (from the qa_upload site a
while back) at the moment.
It appears that the SRB will not accept a query definition as the data
source when that query includes an order by clause and Escape
Processing False.
Is this now by design? - I remember that there was an issue about
sorting and changes where made and was thinking that this might of
been the case.
Attached file has an example.
Two reports RPT_TABLE_SPECS_NO_ORDERBY and RPT_TABLE_SPECS_ORDERBY
Two queries qryBaseTableStructure_NO_orderby and
qryBaseTableStructure_orderby
If you try to run the report RPT_TABLE_SPECS_ORDERBY directly by
double clicking the report name it just silently refuses to run. (
I'll check in the issue system for this and enter if not there )
But if you open the report in edit mode and try to run it then you get
the error message dialog telling you that the query can not have an
order by clause.
To make it run all that is needed is to go back into the query
definition qryBaseTableStructure_orderby and change Escape Processing
from False to True.
So, just curious is this is now the rule.
One other item - yesterday and today is the first time in a while that
I have had a chance to work with Base at all - tonight all I did was
work on this one query and one report, OO.o has crashed more then a
dozen times. Always with the SRB open in edit mode and always (almost)
when doing something like switching windows or a copy of some item to
the clip board. The Microsoft error handler comes up and it appears to
be a problem in GDI32.dll, or rather that is is where the error
manifests anyway. Two times even this MS error handler would not kill
OO.o, it just kept running a loop bring up the MS error dialog each
time I clicked on the button to end, requiring that I go and kill the
process directly while the error dialog was being displayed. I'm
really hoping that this copy of the SRB is just a bit out of date...
Thanks
Drew
The "order by" also disqualifies queries from being used as the basis
for a DISTINCT query, I forget when that started but it's true on WinXP
in 2.4.1 and at least one earlier release. So this apparently goes
deeper than the SRB and version 3. I couldn't see why this restriction
was introduced, but I thought it was by design and just made the
unsorted versions of the queries I needed. I ran into it on a query with
a join, but it happens on an unjoined one also.
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]