Error when clicking too fast (1 Viewer)

[The_Doc_Man]

Both Jet and external engines run in this 'semi-asynchronous' manner, where they start returning records and the VBA code may continue as soon as the first is retrieved, instead of waiting for them all. But that has nothing to do with all this.

Not a true statement. The "Both Jet and ..." part is wrong. Jet, like Ace, operates synchronously to build a result-set. In external SQL engines, the result set is built locally, asynchronously with the FE, and then transferred to the FE via the recordset object. In Jet and Ace, the result set is in the file that Jet or Ace can directly access to build the fully-extant temp table that contains the list of returned items.

OK, a qualifier on that statement. That is the way that Microsoft documentation describes it when discussing pass-thru and non-pass-thru queries. But since Access is NOT open-source, we have a hard time verifying the details.

EDIT: A further wrinkle is that a poorly designed query that includes Access VBA functions might force Access to do the processing rather than the back-end engine. Whenever THAT happens, you can bet that everything becomes synchronous.

 

[gemma-the-husky]

Bound forms are fine when doing simple things. This app is decidedly NOT simple, and many of its functions would be completely impossible with bound forms. Some can be bound, and are. The more complex ones are out of the question.

I would be very surprised if you need unbound forms. I have only needed them a handful of times, and I suspect with more understanding I could have avoided the use of unbound forms completely.

 

[pdanes]

I would be very surprised if you need unbound forms. I have only needed them a handful of times, and I suspect with more understanding I could have avoided the use of unbound forms completely.

Then you are obviously doing far different sorts of work than what I'm doing. Bound forms are fine for simple manipulations of datasets, but there are a great many tasks that are not nearly so simple. Unbound forms are just another tool in the toolbox. They are good for some things, not good for other things, but in no way are they some sort of crutch that is to be avoided when possible.

If all your work is simple enough that bound forms are adequate, great - use them. Mine is not.

 

[pdanes]

The "Both Jet and ..." part is wrong. Jet, like Ace, operates synchronously to build a result-set.

It does NOT. Try it yourself - populate a large local table, then issue an OpenRecordset command and immediately test RecordCount. It will NOT show the full count. It will always be at least one, and in the background, Jet will continue filling in the records, EXACTLY as does SQL Server. If the app insists on seeing a record that has not yet been delivered, processing will STOP until that records is delivered, whether by Jet or SQL Server - a synchronous set of processes.

In external SQL engines, the result set is built locally, asynchronously with the FE, and then transferred to the FE via the recordset object. In Jet and Ace, the result set is in the file that Jet or Ace can directly access to build the fully-extant temp table that contains the list of returned items.

It would only be asynchronous if the issuing app continued on its way without waiting for the records. Mine does NOT, as I have written so many times. And if I manually insist on seeing the last record, or the full count, once again, the app WAITS until those counts or records are delivered by the engine, whether SQL Server or Jet or something else. SYNCHRONOUS.

EDIT: A further wrinkle is that a poorly designed query that includes Access VBA functions might force Access to do the processing rather than the back-end engine. Whenever THAT happens, you can bet that everything becomes synchronous.

Yes, but I don't do it that way. I don't know eveything there is to know about all this, but I do know better than that.

And it would not affect the issue of being synchronous. It would force Access to wait until the ENTIRE recordset had been delivered, just as it would now were I to issue a .MoveLast command, rather than permitting it to continue with the first one and filling in records in the background.

 

[The_Doc_Man]

Try it yourself - populate a large local table, then issue an OpenRecordset command and immediately test RecordCount. It will NOT show the full count.

Have, actually. You are looking at this incorrectly. The delay is due to the action of loading the finished recordset. It is that lengthy action that causes the delay that you see. In my genealogy database, which involves tens of thousands of records, I see that delay quite often, even if I am opening a big, static table that WASN'T created by a query. It is my main data-source table created from a data import-and-parse operation.

 

[The_Doc_Man]

And if I manually insist on seeing the last record, or the full count, once again, the app WAITS until those counts or records are delivered by the engine, whether SQL Server or Jet or something else. SYNCHRONOUS.

And yet if you do a database.Execute, the .RecordsAffected count is available right away after a successful execution under native Access. You keep on conflating the act of opening the recordset results with the act of executing the query. It is a DIVISIBLE ACTION.

 

[pdanes]

And yet if you do a database.Execute, the .RecordsAffected count is available right away after a successful execution under native Access. You keep on conflating the act of opening the recordset results with the act of executing the query. It is a DIVISIBLE ACTION.

The same is true of SQL Server. If I issue a command to execute a stored procedure, the result is available as soon as the procedure completes. That has nothing to do with opening a recordset.

 

[The_Doc_Man]

The same is true of SQL Server. If I issue a command to execute a stored procedure, the result is available as soon as the procedure completes. That has nothing to do with opening a recordset.

But the difference is that the procedure can theoretically complete while the FE does something else.

 

[pdanes]

But the difference is that the procedure can theoretically complete while the FE does something else.

Yes, theoretically it could. But the point is that it doesn't - it waits. In all these cases, Access waits for a response.

Sometimes the response is, "Here you go."
Sometimes the response is, "Here is the first record, I'm working on the others."

In both cases, Access waits for that response. Waiting for the other side to respond is what defines a synchronous set of processes. Having an option to do something else does not make it asynchronous, unless you avail yourself of that option.

 

[The_Doc_Man]

Having an option to do something else does not make it asynchronous, unless you avail yourself of that option.

We are arguing over semantics. Having the option to do something else INCLUDES the option to asynchronously wait and do nothing, because that, too, is a choice. If you were waiting and had a choice to do something else, it is asynchronous no matter WHAT you chose. If you were waiting because there WAS no choice, it is synchronous.

 

[pdanes]

We are arguing over semantics. Having the option to do something else INCLUDES the option to asynchronously wait and do nothing, because that, too, is a choice. If you were waiting and had a choice to do something else, it is asynchronous no matter WHAT you chose. If you were waiting because there WAS no choice, it is synchronous.

"Waiting and doing nothing..." Waiting for what? The sun to go down? If you are waiting, then you are waiting for the other process. THAT makes it synchronous. There is always the option to not wait, but if you need the results from the partner process, not waiting is silly. What would you do in the meantime?

I have the option to kill people. That does not make me a murderer. TAKING the option is what would make me so. Having it means nothing.

 

[The_Doc_Man]

This is getting boring because you won't see the distinction. Believe as you will.

 

[Petr Danes]

This is getting boring because you won't see the distinction. Believe as you will.

Yes, because most of the distinctions you keep bringing up simply don't exist, or you say that having a universally available option is somehow meaningful, while actual behavior is not.

Sorry - you've been very helpful with some things in the past, but what you write on this topic just makes no sense.