ORDER BY will not work in report's Me.RecordSource (1 Viewer)

The_Doc_Man

Immoderate Moderator
Staff member
Local time
Today, 15:58
Joined
Feb 28, 2001
Messages
27,146
Since you are not doing a report grouping, you have essentially at most five sections: Report Header and Footer, Page Header and Footer, and Detail. None of those headers and footers care about order, so all you want is that the Detail section appears in a particular order. In theory, if you set the report's .OrderBy to the fields you want sorted in the priority order you desire, that should work.

However, here is my question: When will you know the correct order that you wanted to use? This is crucial to making it easier or harder to accomplish your task. I will explain.

If you cannot know until the report is already open, something is wrong because that means you are doing your logic inside a report event. That is just WRONG. Way too late in the binding. BUT if you know the right order just a few steps earlier, you can impose a sort order when you issue the DoCmd.OpenReport command that launches the report. And from there, you can perhaps use a fixed .Recordsource that doesn't change across multiple iterations - but you can use a dynamically defined .OrderBy to choose the order. Will that work?

The reason I ask this is that report definitions are bound to the .Recordsource by field names, so the query you are using HAS to be at least THAT predictable - i.e. that you have the field definitions already bound. The order? That can be dynamic. But the field bindings? That is a whole other ball of wax.
 

smig

Registered User.
Local time
Today, 23:58
Joined
Nov 25, 2009
Messages
2,209
Since you are not doing a report grouping, you have essentially at most five sections: Report Header and Footer, Page Header and Footer, and Detail. None of those headers and footers care about order, so all you want is that the Detail section appears in a particular order. In theory, if you set the report's .OrderBy to the fields you want sorted in the priority order you desire, that should work.

However, here is my question: When will you know the correct order that you wanted to use? This is crucial to making it easier or harder to accomplish your task. I will explain.

If you cannot know until the report is already open, something is wrong because that means you are doing your logic inside a report event. That is just WRONG. Way too late in the binding. BUT if you know the right order just a few steps earlier, you can impose a sort order when you issue the DoCmd.OpenReport command that launches the report. And from there, you can perhaps use a fixed .Recordsource that doesn't change across multiple iterations - but you can use a dynamically defined .OrderBy to choose the order. Will that work?

The reason I ask this is that report definitions are bound to the .Recordsource by field names, so the query you are using HAS to be at least THAT predictable - i.e. that you have the field definitions already bound. The order? That can be dynamic. But the field bindings? That is a whole other ball of wax.

Thank you for your reply
As I wrote in reply No.16 I sorted it out, as you suggested, using the Report.OrderBy :)
 

smig

Registered User.
Local time
Today, 23:58
Joined
Nov 25, 2009
Messages
2,209
To close this issue :)

Thank you all for all the help :)

It seems reports will ignore the ""ORDER BY" part of the .RecordSource either set in code or in the report properties :eek:

Using the .OrderBy will sort it correctly (Don't forget to set .OrderByOn = True)
As other pointed all Grouping and Sorting must be removed for the .OrderBy to work (They will take priorty)
 

Uncle Gizmo

Nifty Access Guy
Staff member
Local time
Today, 21:58
Joined
Jul 9, 2003
Messages
16,273
It seems reports will ignore the ""ORDER BY" part of the .RecordSource either set in code or in the report properties

I think if that were the case, then I would know about it.

I just can't see how the report can ignore something that's passed through in the record source. It doesn't make any sense to me.

However, I don't know for sure. When I get the few minutes I will knock up a sample and see if I can duplicate your experience.

Sent from my SM-G925F using Tapatalk
 

The_Doc_Man

Immoderate Moderator
Staff member
Local time
Today, 15:58
Joined
Feb 28, 2001
Messages
27,146
For later readers whose search leads here, this is what Microsoft says about sort order in a report:

https://support.office.com/en-us/ar...r-report-4f255441-7326-486a-97ad-7760e8b0880b

https://docs.microsoft.com/en-us/office/vba/api/access.report.orderby

In the above link, there is an interesting note that might be a bit more revealing about the issues noted by smig. I have highlighted the interesting part:

When a new object is created, it inherits the RecordSource, Filter, OrderBy, and OrderByOn properties of the table or query that it was created from. For forms and reports, inherited filters aren't automatically applied when an object is opened.

This next link shows that smig's observation isn't new; the thread was started in 2000.

https://access-programmers.co.uk/forums/showthread.php?t=21792

Here is someone who uses code to do the last-minute ordering via .OrderBy, which is what smig also noted. It shows code which has been partly customized, but the concept is similar to this thread.

http://www.databasedev.co.uk/sorting_reports.html

Finally, a similar complaint from another source in 2004:

https://www.tek-tips.com/viewthread.cfm?qid=825427

So apparently, the order in the .Recordsource might as well be kaka. The report ignores it completely in favor of some divine inspiration it gets from phase of the moon.
 

isladogs

MVP / VIP
Local time
Today, 21:58
Joined
Jan 14, 2017
Messages
18,209
The sort behaviour has been the same for many versions. Probably since version 1. I could check that later today!

Whilst frustrating when you first experience it, there is a major advantage in this approach. You can use the same query or SQL statement for several reports and sort each in a different way. Or you can use open args and sort the same report in different ways depending on the argument used.

There are in fact multiple ways of sorting reports including
1. Setting this in the calling form using code
2. Using the wizard when you create the report
3. Using OrderBy In the property sheet
4. Using Sorting and Grouping on the report

If you use more than one of those at once, then a priority order is assigned and I believe that will be the last of the above (not checked). If you use none of them, it will sort by the first field in the record source.

What I don't quite understand is smig's reluctance to use the sorting feature built into Access reports
 

Users who are viewing this thread

Top Bottom