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]

Reply via email to