Filter property or sql Where? OrderBy property or sql Order by?
- Thread starter amorosik
- Start date
MajP
You've got your good things, and you've got mine.
- Local time
- Today, 00:55
- Joined
- May 21, 2018
- Messages
- 9,657
Maybe I am missing something, but this seems like a very simple test.
1. Open a continuous form to a single filtered record
2. While the form is open go into the table and modify, delete, or add some records
3. remove the filter
All changes show, so would it not have to re-pull the data?
1. Open a continuous form to a single filtered record
2. While the form is open go into the table and modify, delete, or add some records
3. remove the filter
All changes show, so would it not have to re-pull the data?
MajP
You've got your good things, and you've got mine.
- Local time
- Today, 00:55
- Joined
- May 21, 2018
- Messages
- 9,657
However, that test is for a local table. I cannot test SQL backend to see if it works differently.
But what is confusing is how MS describes a filter
"Since the view you get after you apply a filter contains only records with the values that you selected, the rest of the data remains hidden until you clear the filter."
As written that does definitely suggest that the rest of the data is there but hidden.
If a forms recordset was by default bound to an ADO recordset, then I could understand it. Because an ADO filter is truly hiding the filtered records and you can unfilter an ado recordset. But a dao filter is not really a filter, it is applying a where clause and restricting the records pulled "You can use the Filter property to restrict the records returned from an existing object when a new Recordset object is opened based on an existing Recordset object". AFAIK you cannot unfilter a dao recordset.
But what is confusing is how MS describes a filter
"Since the view you get after you apply a filter contains only records with the values that you selected, the rest of the data remains hidden until you clear the filter."
As written that does definitely suggest that the rest of the data is there but hidden.
If a forms recordset was by default bound to an ADO recordset, then I could understand it. Because an ADO filter is truly hiding the filtered records and you can unfilter an ado recordset. But a dao filter is not really a filter, it is applying a where clause and restricting the records pulled "You can use the Filter property to restrict the records returned from an existing object when a new Recordset object is opened based on an existing Recordset object". AFAIK you cannot unfilter a dao recordset.
Access may not be functioning as expected in terms of record loading (in forms).
I have a continuous form that supposedly loads 1million+ records. When the form is loaded, Access appears to fetch an initial batch of up to 501 records, and additional records are retrieved as I scroll. For example, on mouse wheel, I reached a point where it wasn't printing a record count of 501 and, instead, it printed 1001, then 1501, and so on. If I then tried another scrolling method, like dragging the scrollbar to the bottom, it printed much greater counts at different rates. I tested this by printing the record count during the Open, Load, MouseWheel, and Detail.Paint events.
As mentioned, the record count did eventually match the total number of records, but that number seemed to depend on the way I scrolled.
In my experience with other platforms outside of Access, if you load thousands of records in some sort of table, not even a million, the software may struggle to keep up. That makes me suspect that Access forms don't really hold everything in memory and that there's some sort of optimization, pagination or caching under the hood to improve user experience.
I have a continuous form that supposedly loads 1million+ records. When the form is loaded, Access appears to fetch an initial batch of up to 501 records, and additional records are retrieved as I scroll. For example, on mouse wheel, I reached a point where it wasn't printing a record count of 501 and, instead, it printed 1001, then 1501, and so on. If I then tried another scrolling method, like dragging the scrollbar to the bottom, it printed much greater counts at different rates. I tested this by printing the record count during the Open, Load, MouseWheel, and Detail.Paint events.
As mentioned, the record count did eventually match the total number of records, but that number seemed to depend on the way I scrolled.
In my experience with other platforms outside of Access, if you load thousands of records in some sort of table, not even a million, the software may struggle to keep up. That makes me suspect that Access forms don't really hold everything in memory and that there's some sort of optimization, pagination or caching under the hood to improve user experience.
Similar threads
