>>>My users rarely report on the problem they come across when using my application. Only way I can see that there was an error here or there is by logging the error information into a ERRORLOG.DBF. Basically all I log in this table are the following:
>>>class and method where error occurred
>>>error description (e.g. "No table is open in the current work area"
>>>and the array aStackArray
>>>
>>>But this does not seem to be sufficient for me to find what actually went wrong or if it is a bug. What else would you suggest to log on error? TIA for any suggestions.
>>
>>Everything that AError() and AStackInfo() return along with LIST STATUS and LIST MEMORY.

About this... it always comes with a long list of system variables, specially those for DOS printing system, which we don't care about. So I cut them out:

		LIST MEMORY TO FILE (THIS.cJunkFile) NOCONSOLE

		IF FILE(THIS.cJunkFile)
			LOCAL lcLeftDelim, lcRightDelim, C
			lcLeftDelim="Memvars"+0h0d
			lcRightDelim="variables available"
			C=STREXTRACT(lcLeftDelim+FILETOSTR(THIS.cJunkFile), lcLeftDelim, lcRightDelim,1,1+4)
			REPLACE mMemory WITH C IN ErrorLog
			ERASE (THIS.cJunkFile)
		ENDIF

>I am taking notes of all suggestions. And will check out this PSR.EXE. However, I can't make my application automatically email; many clients "warn" that they do not like this. Probably mainly concerned about losing confidential information. I periodically connect and check myself.

Alternately, you can arrange for error logs (one per error, or one per user session) to be made in a predetermined folder to which you have FTP access (and can check for it periodically and automatically) or to have these files FTP'd to your predetermined URL. Disclose this to admins and tell them to deny access to this location to yourself only (in the first case), or limit the FTP to your URL only (2nd). Let them log it any way they like it.