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