Thanks, Jason. Well, I can't wait to watch Kevin.

Do you know if he's going add this to the next release of the framework?

Thanks,

David


>Yep, this is a bug that somehow reared its ugly head at some point last summer. If you change the following code in cErrorMgr.CreateLogEntry(), located in cManager.vcx:
>
>Change from :
>

>DO WHILE !EMPTY(SYS(16,lnCount))
>	IF SYS(16,lnCount) != 'ON.'
>		REPLACE mCallChain WITH mCallChain + SYS(16,lnCount) + ;
>		CHR(10) IN ErrorLog
>	ELSE
>		EXIT
>	ENDIF
>	lnCount = lnCount + 1
>ENDDO
>
>lcAlias = This.ErrorMgrObj.GetAlias()
>
>This.ErrorMgrObj.New()
>

>
>Change to:
>

>
>lcAlias = This.ErrorMgrObj.GetAlias()
>This.ErrorMgrObj.New()
>
>DO WHILE !EMPTY(SYS(16,lnCount))
>	IF SYS(16,lnCount) != 'ON.'
>		REPLACE mCallChain WITH mCallChain + SYS(16,lnCount) + ;
>		CHR(10) IN ErrorLog
>	ELSE
>		EXIT
>	ENDIF
>	lnCount = lnCount + 1
>ENDDO
>

>
>Essentially, it was adding all the call chain information to the first record in the errorlog table. Don't worry, as part of Kevin's "mea culpa" on this one, he agreed to Riverdance for all of us at Whilfest and DevCon. The critics agree, it's better than Cats... you'll want to see it again and again.
>
>>The error log in my app is not storing the calling chain. This means that I know the error, when it occured, and the user's environment, but I do not know where the error occurred - the most important piece!
>>
>>Thanks,
>>
>>David