![]() ![]() (Some error traps ARE interrupts, which is why error event processing is slightly different from regular event processing.) If you are running code, it is already running in an event context. The reason your timer can't run is because a timer queues a timer EVENT, not an interrupt. (We delved into this a couple of years ago and got confirmation from various online sources.) And Jet or Ace itself is internally synchronous. The Access GUI synchronizes with Jet/Ace if the BE is a native Access BE file. But for any native Access query, you run synchronous code for any event. If that query were to an SQL engine and you ran it using a pass-thru query, it would be possible to test the underlying recordset for progress or completion. But the automatic data-load query gives you no "hook" to execute code while it is running. In order to do something with a progress bar, you need some CPU time to execute code to diddle with the settings of the progress bar. Among other things, YOU didn't trigger it Access did, as an automatic feature. You cannot get any code to execute in the time gap for a "pure Access" operation because that form-data-load query is indivisible. ![]() This is a description of a network issue, the "home" showing a slow connection and the "office" showing a fast connection. I have a Pause function that I use elsewhere in the database, so I added a 10-second pause in the load event after the initial call of the progress bar and the progress bar is not moving - unless Pause shuts down the timer event also. I just thought of and tried something else. I saw a delay at home when I closed and re-opened the form, and I see the progress bar (but no movement) now if I close and re-open it. I added a switchboard and I moved that code to a subroutine of my autoexec.vba and I have progress bars that are working for that (but I can identify discrete events for that.)įor testing, I am opening this form explicitly along with the switchboard, but I'm not sure that matters. This particular form used to be my startup form and I had code in it to check the opening path of the database and to check for front end updates prior to sorting the records. In Form_Activate(), I have code to close other open forms, but the unload ufProgress is after that, so I would expect the progress bar to still be running at that point. (Note that there is no query actually being loaded.) In the office (today), it loads in under a second, so I can't really tell if the progress bar is failing or not. When I load it from home, I typically see "Running Query" and the built-in progress bar in the status bar and it takes about 60 to 90 seconds to load. The form that takes the longest to load has about 3000 records and there is a line in the load event to sort it on a binary field called "Sortkey" and then on a field named "Title". ![]()
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |