Hi all, I got this error
'SYSTEM error: attempt to define too many indexes for area 6 database
DBI18992a13864 (40) (14675)'
From Progress help i found the problem is because of defining the temp-tables with index many times.
we have defined the static temp-table
In order to find the dynamic temptables deleted or not i have the code
DEFINE NEW SHARED TEMP-TABLE tt_check
FIELD FIELD1 AS INT
FIELD FIELD2 AS INT
.
DEFINE VARIABLE hBuffer AS HANDLE NO-UNDO.
OUTPUT TO "c:\memdump.log" APPEND.
PUT UNFORMATTED SKIP
"** Dump: " TODAY STRING(TIME,'HH:MM:SS') SKIP
"** Dynamic temp-tables **" SKIP.
ASSIGN hBuffer = SESSION:FIRST-BUFFER.
DO WHILE VALID-HANDLE(hBuffer):
IF VALID-HANDLE((hBuffer:TABLE-HANDLE)) THEN DO:
PUT hBuffer:TABLE-HANDLE:NAME FORMAT "x(20)" AT 2
" ".
&IF PROVERSION BEGINS "1" &THEN
IF VALID-HANDLE(hBuffer:INSTANTIATING-PROCEDURE) THEN
PUT hBuffer:INSTANTIATING-PROCEDURE:FILE-NAME FORMAT "x(40)".
&ENDIF
PUT SKIP.
END.
hBuffer = hBuffer:NEXT-SIBLING.
END.
OUTPUT CLOSE.
This will work for static temp-tables also?
If not plz provide code to find the static temp-tables i am in urgent need.
Thanks in advance for help.
Regards
Shireesh.
Hi Shireesh,
We are facing the same problem.
It doesn't seem to be any way to log creation/deletion of static temp-tables. As far as I know, you can only trap implicit creation/deletion of temp-tables passed as parameter (through the client logging feature).
I've yet asked Progress Support if there's any secret tool to trap what exactly goes into the DBI temporary file, but it doesn't seem to be any neither.
I see your question was posted in May, so did you fix the problem on your own? Do you learn something about this issue?
Thanks for sharing.
Regards.
Hi olivier,
Yes we found the prob
1) transaction scope
If still you have the prob
Temp table having indexes is called many times in transaction. Use no-undo for temp-table.
This will solve the problem
Regards,
Shireesh
The rule for static TT's is - if you run code with one or more TT definitions, all the TTs in the program are instiantiated when the program code is run, regardless of whether they're used or not.
Thanks to you both.
The error occured in a class-based implementation of the OpenEdge Reference Architecture.
Believe me or not, there were only one temp-table defined without the NO-UNDO attribute. This temp-table held the context of each user's request. So it was indirectly involved in transactions.
Thanks again, Shireesh, for having focused my attention on this particular point.
Keep in mind that instantating too many temp tables has serious (negative) performance implications since the compiler / AVM doesn't optimize when the TTs are instantiated. This'll result in the TT tables overflowing in to the DBI file, which can get quite large along with the count of "current" TTs - I've personally seen DBI files in the hundred of MB size.
This means that putting a TT def'n in a single base class that's instantiated a lot of times will - in time - result in the TMTT problem.
Search for TMTT for other - lengthy - discussions on the point.
Thanks Tim.
I've yet reviewed/followed a lot of discussions over the "TMTT" topic... it seems to be a never ending story.
During the debugging process, we've indeed observed that the DBI were growing up to reach 1GB!
Now that this is fixed, the DBI file remains around 1.5MB.
I'm still wondering if there is a way to log what's going into the DBI (I mean, static temp-tables or implicitly created ones).
There's some code to log dynamically created objects, but I haven't found anything yet regarding static TT.
Do you have any idea?
TT performance / activity measurement is an area where the language is lacking.
The "next best" thing I can think of is the check out the LOG-MANAGER system handle.