Plateforme Level Extreme
Abonnement
Profil corporatif
Produits & Services
Support
Légal
English
M.Error = ERROR()
Message
De
04/06/2013 12:03:31
 
 
À
04/06/2013 11:48:49
Information générale
Forum:
Visual FoxPro
Catégorie:
Codage, syntaxe et commandes
Versions des environnements
Visual FoxPro:
VFP 9 SP2
OS:
Windows 7
Network:
Windows 2008 Server
Database:
Visual FoxPro
Application:
Desktop
Divers
Thread ID:
01575604
Message ID:
01575611
Vues:
49
>>In some legacy code there's a function SafeCmd() to execute some commandline and do this safely. If it fails it returns an error number. It always worked well, until recently. The command "use xxxx exclusive alias xxxx" correctly returns error 1705 (access denied) if the table is already opened by some other application. However, in another routine a similar call incorrectly returns error 0.
>
>
>It's possible the currently selected work area in that other routine just happens to be the work area of the other table that's being re-used, and therefore it succeeds by re-using the table atop itself in the same work area.

In the debugger, at the very moment that the ON ERROR line is displayed (in the debugger), ERROR() is zero and MESSAGE() contains the (correct) 'access denied etc' text of error 1705.

>If it's a variable issue, giving it some obscure convoluted names will likely fix it. Instead of using m.nError, use m.nError_safecmd, or something to make it distinct.

This will likely be the case, yes. The funny thing is that it goes wrong again if that same name is used as the receiving value, e.g.:
m.nError_safecmd = SafeCmd( "use xxxx exclusive alias xxxx" )
So, the how and when are now known. But the why is still a mystery to me.

>Best regards,
>Rick C. Hodgin
>
>
>>I could repair the routine by making variable m.error PRIVATE instead of LOCAL.
>>Another way was to rename m.error to e.g. m.lnError (and keep it local).
>>
>>My hunch is that, under (for me obscure) circumstances, the ON ERROR handling is occurring OUT OF THE LOCAL SCOPE (where it is not out of the private scope). Or that VFP internally can get confused when processing: m.Error = ERROR()
>>
>>Who's got a clue to what may be the problem here? I'm not so much interested in a solution (actually, we'll gonna use the array from AERROR instead), but more in the how, why and when of this quircky behavior.
>>
>>
FUNCTION SafeCmd
>>	LPARAMETER m.Command
>>
>>	local m.Error, m.OnError
>>*	private m.Error, m.OnError
>>
>>	m.OnError = ON( 'ERROR' )
>>	m.Error = 0
>>
>>	ON ERROR m.Error = ERROR()
>>	&Command
>>	ON ERROR &OnError
>>
>>	RETURN m.Error
Groet,
Peter de Valença

Constructive frustration is the breeding ground of genius.
If there’s no willingness to moderate for the sake of good debate, then I have no willingness to debate at all.
Let's develop superb standards that will end the holy wars.
"There are three types of people: Alphas and Betas", said the beta decisively.
If you find this message rude or offensive or stupid, please take a step away from the keyboard and try to think calmly about an eventual a possible alternative explanation of my message.
Précédent
Suivant
Répondre
Fil
Voir

Click here to load this message in the networking platform