Level Extreme platform
Subscription
Corporate profile
Products & Services
Support
Legal
Français
Controlling the mysterious behavior of MESSAGE(2)
Message
From
17/08/1999 13:38:24
 
 
To
All
General information
Forum:
Visual FoxPro
Category:
Other
Title:
Controlling the mysterious behavior of MESSAGE(2)
Miscellaneous
Thread ID:
00254576
Message ID:
00254576
Views:
54
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
Next
Reply
Map
View

Click here to load this message in the networking platform