>First, coverage profiling is a 6.0 feature, and not available in 5.0. While the COVERAGE.APP project is available to be modified, it's the VFP design time internals that generate the log file.


Yeah, I got that confusion sorted out when someone else mentioned that it parses the file. I do try and mention which version I'm currently using since I go back and forth, but I often forget. I wish there was a combo like for selecting the category, but I believe it was already suggested and denied.

>You wouldn't want to enable such a process at runtime anyway, since it adds additional processing overhead, and would hurt performance.

I have to do this at run-time because I can't reproduce the error locally. It's apparantly "random". I realize that there's a pattern there somewhere because nothing is really random with computers, but they don't know what it is and it only occurs a couple times a month.

>Now, even though you say that the log file will be quite large because of the routine, it would provide the information you need. Further, in your error handler, if you issue SET COVERAGE TO to turn profiling off, all you have to do is go to the bottom of the log and examine that.

I was about to say that this won't work, but then I thought about it again. If I keep _overwriting_ the log file, then it wouldn't be so bad. I turn it on at the begining of the program and turn it off when the error occurs, then it will just overwrite the file each time so I won't have months worth of code in there. There will still be a lot because the code jumps all over the place, but it shouldn't be too huge to email to me.

>Hopefully, you'll take the following in the spirit it's given. Of course, without seeing the code, this is pure conjecture on my part. If I were to hazard a guess, this code segement could stand some re-doing. You've mentioned that there are 19 or 20 calls to the routine that's causing the error within it. Frankly, when my stuff starts to approach 19 or 20 lines I start to examine it more closely. Why? Because it's indicative that the code isn't as functionally cohesive as it should be. I suspect that's the problem here. If the code were more functionally cohesive, I doubt that you'd be spending time on this maintenance chore now. Of course, this is just IMO, and you can take it or leave it.

Oh, I agree 110%. Unfortunately, I don't have the resources to rewrite SBT. :)

Thanks,

Michelle