Unexected reports of Error 1523

[Mike Lewis]

A client tells me that he has recently had several uses reporting that his application is crashing with error 1523 ("Execution was canceled by the user"). The Help page for this error says "You canceled a remote command by pressing the ESC key).

The client is completely certain that none of the users is pressing ESC at the relevant time. And, in any case, the application has SET ESCAPE OFF in all its data sessions.

The error occurs in a function that creates remote views, which it does by executing CREATE SQL VIEW statements. The users have been experiencing some network and server issues recently, and these might be having an effect here. But that wouldn't explain why they are seeing that particular error.

Can anyone throw any light on this? Are there any circumstances where this error might occur other than by the user pressing ESC?

Also, what do they mean by "you canceled a remote command"? What is a "remote" command in this context?

Mike



__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro articles, tips and downloads

 

[Olaf Doschke]

What I connect to ESC is what is described in SET REPROCESS.

If you have kept this at the default and VFP can't directly lock something it displays a message "Attempting to lock..Press Escape to Cancel". I wonder if VFP then activates the ESC key, no matter, if you SET ESCAPE OFF or ON. And the next question is, whether VFP reacts as if ESC was pressed, even if the user does nothing.

Do you have error handling set up? I would look out for errors 108 or 109, then.

Bye, Olaf.

 

[Mike Lewis]

An interesting point, Olaf. Thanks. I hadn't though of SET REPROCESS. I believe that when VFP displays the "Attempting to lock..Press Escape to Cancel" message, that takes precedent over the setting SET ESCAPE. (It would be strange if it didn't.) I've never heard of the possibility of VFP reacting as if ESC was pressed, but who knows ....?

However, I don't think this is the explanation of what we are seeing. That's because the only data that the application accesses is on a back-end server which it accesses via remote views, and these are contained in the user's private copy of a DBC. In other words, there are no DBFs to lock.

There is an error routine in force, but I don't know how this handles 108s and 109s. I'll ask the client to send me a copy. (I should explain that I didn't write this application. The client himself has his own programmers. I just provide them with VFP training and technical support.)

Mike

__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro articles, tips and downloads

 

[Olaf Doschke]

In regard to remote command, what I connect to the error message is executing a long running sqlexec or a remote view. A wait window message "executing remotely...press ESC to cancel" might appear, if a query takes longer in the same manner as the "Attempting to lock" message appears for DBF locks. That might be the case in using such views, but not in defining them.

Bye, Olaf.

 

[Olaf Doschke]

...Some timeout of VFP (ConnectTimeOut, QueryTimeOut) or the SQL Server might then cause the error.

Bye, Olaf.

 

[Olaf Doschke]

And by the way: If it would be the "Executing Remote...press ESC to cancel" message, then SET ESCAPE OFF should work as said in thread184-216775 and Foxite

So are you sure SET ESCAPE is OFF in that part of your application, too?
Besides the help topic on SET ESCAPE doesn't say that this setting effects that message.

Bye, Olaf.

 

[Mike Lewis]

Thanks for your further input, Olaf. I have been following up your idea of a timeout causing VFP to react as if ESC had been pressed. I've just found out that there have been problems with the server that hosts the back-end database, which would be consistent with that explanation.

I can't put my hand on my heart and say ESCAPE is definitely off, because I haven't seen the code yet and am only reporting what I hear second hand. Also, it seems that the problem occurs when a top-level form is active and _SCREEN is invisible, which might mean that the "executing remotely...press ESC to cancel" is active but not be visible to the user - but still accepting ESC to cancel the operation.

I think I'm going to have to set up a test to reproduce the problem. If nothing else, I might learn a bit more about this particular message and the circumstances surrounding it. If I do, I will of course report back.

Mike



__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro articles, tips and downloads

 

[Olaf Doschke]

Well, as you said yourself:

"The users have been experiencing some network and server issues recently"

Some flaky connection might also have caused a remote view to stop executing, then it should rather be "excecution was canceled by the network". We should consider replacing user with network in all error messages. Simply because a user friendly error message NEVER would mention the user.

Bye, Olaf.

 

[Mike Lewis]

I've finally got to the bottom of this problem. I'll post some more information here in case anyone else comes up against a similar issue.

As I supposed, there were indeed problems with the SQL Server that caused connections to fail intermittently. When a connection fails, in some cases the user sees SQL Server's own login dialogue (or, more precisely, one generated by the ODBC driver). If they try to use this to log in to the server, the login might fail again. Eventually, the user will cancel out of the login dialogue. When they do that, the application halts with error 1523: "Execution was canceled by the user".

So, the error message is, strictly speaking, correct. But it not because the user is pressing ESC, nor is it caused by a timeout. And, because it's nothing to do with the user pressing ESC, it is not affected by SET ESCAPE OFF.

Going further, the application's error reporting mechanism was picking the error message from the second element of the AERROR() array. This is the message that VFP generates. However, it is the third element of the array that contains the error reported by the ODBC driver. This message is more informative, as it gives an indication of why the login might have failed in the first place. In this case, the error routine should have been reporting that ODBC message to the developer, as that contains the information they need to deal with the problem.

Apart from the above point about the error message, I'm not sure what the ideal solution is. Ideally, you never want the user to see a login dialogue that is not under the control of your own application - if for no other reason than that the user might not have a clue about what user name or password to use to log in. But I don't know of any way of suppressing it if the ODBC driver wants to to display it. It's not enough to trap the error within VFP, because the dialogue will appear before you have a chance to do that.

Anyway, I hope this information will be useful if anyone ever hits the same issue. The bottom line is that "Execution was canceled by the user" doesn't necessarily mean the user pressed ESC.

Mike

__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro articles, tips and downloads

 

[craigber]

Even more curious.... When is Error 1523 expected?

Craig Berntson
MCSD, Visual C# MVP,

http://www.craigberntson.com/blog

 

[Mike Lewis]

When is Error 1523 expected?

Sorry, Craig. I don't understand the question.

Mike



__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro articles, tips and downloads

 

[craigber]

Mike, look at the name of this thread.

Craig Berntson
MCSD, Visual C# MVP,

http://www.craigberntson.com/blog

 

[Olaf Doschke]

Well, Craig, errors are always unexpected, but if the help on the error message states the user pressed ESC and he didn't, that is another form of "unexpectedness", isn't it?

Mike, it's good to know Eror 1523 can also come from a SQL Login Prompt being cancelled. I think because ESC causes the Cancel button and a Cancel button causes ESC in VFP forms, that might also be in the system dialogs. I don't really think so, most probably it's just a misleading part of the error explanation and this error simply happens for all canceled remote operations.

Anyway, I can add that AERROR() creating several array rows sometimes also happened to me, especially if you do AERROR() after SQLEXEC() or TABLEUPDATE() indicate to do so. You only expect an ODBC ERROR 1526 but some other errors get reported related to code in other places, too. As if some errors were suppressed and still wait to get read from a queue.

Bye, Olaf.