Plateforme Level Extreme
Abonnement
Profil corporatif
Produits & Services
Support
Légal
English
Controlling the mysterious behavior of MESSAGE(2)
Message
De
17/08/1999 13:38:24
 
 
À
Tous
Information générale
Forum:
Visual FoxPro
Catégorie:
Autre
Titre:
Controlling the mysterious behavior of MESSAGE(2)
Divers
Thread ID:
00254576
Message ID:
00254576
Vues:
55
I have noticed fairly consistently in my error log, that certain errors in certain places in code cause the results of MESSAGE(2) to be filled with the last SQL command issued to VFP. This is the SQL that VFP builds to do a update, select, delete or insert from a REQUERY() or a TABLEUPDATE() on a view.

This "accidental" output is very interesting to me, and I would like to find a way to harness it. If I could find exactly what causes the contents of MESSAGE(2) to be filled with this string, I could do it on purpose and use it to analyze a view. (Those of you that use eView can already smell a new feature).

My error log is sprinkled with strings like:

UPDATE mac!bondcard SET websent=lvunsentbonds.websent WHERE websent=OLDVAL('websent','lvunsentbonds') AND id=OLDVAL('id','lvunsentbonds')

and

SELECT Elections.*, Purchase.desc FROM mac!elections INNER JOIN mac!purchase ON Elections.fa = Purchase.code WHERE 1=0 ORDER BY Elections.elec_dt into cursor Viewcalv87

This stuff is great. It lets me know exactly what is going on behind the scenes with views. The problem is, I can't get it when I want it.

Important additional note: This only happens in a compiled executable. When running fromthe command window, MESSAGE(2) always returns the line of code that caused the error (like it was designed to).

Anybody got a clue as to what is going on?
Erik Moore
Clientelligence
Suivant
Répondre
Fil
Voir

Click here to load this message in the networking platform