Question Performance loss due to Temp-Tables

Rob Fitzpatrick

ProgressTalk.com Sponsor
However for a start, I seriously think I'd save dozens of wasted hours per year if they could just added file name/line number to error messages (everywhere, not just in the UI and AppServer logs).
Just to play devil's advocate: not every error is associated with a particular line of code. Lock table overflow would be an example as it happens on the server, not in a particular client.

But I totally agree that "Write to NFS file system failed on fd 109" or "Write to NFS file system failed on fd 109" would be a lot more helpful after the fact if I knew which file it was. Is it possible the runtime doesn't *know* the file name at the time the error is thrown, and just uses a file descriptor to access it? I don't know.
 

GregTomkins

Active Member
I'd settle for file names/line numbers on 'xxx not on file' and 'xxx not available'. I have spent so many 100's of hours over my Progress lifetime sprinkling message statements all over, trying to track down where someone forgot NO-ERROR or AVAILABLE.

Maybe .R layout makes this hard - but - messages in AppServer logs do it (albeit, the line #s can be misleading, but the file name is never confusing, and that can be a big help!)
 

Rob Fitzpatrick

ProgressTalk.com Sponsor
I'd settle for file names/line numbers on 'xxx not on file' and 'xxx not available'. I have spent so many 100's of hours over my Progress lifetime sprinkling message statements all over, trying to track down where someone forgot NO-ERROR or AVAILABLE.
Absolutely agreed. It doesn't seem like there would be any reason the runtime couldn't report line numbers for those. It would be the line where you access the buffer rather than the query, but knowing that line number it wouldn't take long to work backwards and find the last query for that table.
 
Top