Error Message - 9287

Team,
In our Production environment we are getting error message 9287. I could see what the error message is all about...

Unable to assign file number to temp-table <name>. Number of active temp-tables reached limit of 32767. (9287)

Progress assigns a unique file number to each temp-table in a progress session. This file number falls in the range of 1 to 32767. All of these numbers are currently in use.

It is happening consistently across programs and modules. What could be the root cause of this issue? Any clues where i can start on?
 

TomBascom

Curmudgeon
You may be dynamically creating temp-tables and failing to delete them (or the handles).

Or you might have lots of TT definitions in include files that are very widely included.
 

RealHeavyDude

Well-Known Member
Never stumbled across this error.

But, the error message tells you that, at run time within the same session there are too many Temp-Tables created (or defined). There is a limit on how many active Temp-Tables are allowed and your application tries to go beyond that. But that may only be the symptom because I don't think that one would ever need that many Temp-Tables at the same. My guess is that there is a piece of code which either defines static Temp-Tables or creates dynamic Temp-Tables on-the-fly which is called more times than you expect it and it is meant to be. Probably your application is caught in an infinite loop.

You could enable the SESSION:DEBUG-ALERT (you can also achieve this by adding the -debugalert parameter to the start of the session) which gives you a stack trace if you click on the help button on the error message. Then you will see which piece of logic is causing the problem and might be able to pin it down.

Another option is the client logging which you can switch on with parameters and then you can examine the log file it creates to see what is going on. But be aware that you might get a really big file depending on the things you want the log-manager to write into the log.

Heavy Regards, RealHeavyDude.
 
Sure Tom/RealHeavyDude...

I will proceed with my analysis on the directions that you people have given and try to narrow down my issue in production.
 
Top