SYSTEM ERROR: Attempt to define too many indexes for area 6 data

This is caused by a few possible things


1) You have defined new temp tables that are not set as NO-UNDO, or you are calling some code that defines some

2) You are persistently running procedures and not deleting the handle to them after usage <- more probable

3) You are using data directives forward to procedure on some busy tables , (which has a bug that doesn't delete the persist proc is starts your code)

a. Work around is not to forward to procedure on busy tables but instead run persistently your code and delete the procedure after - recreating forward to proc.

The problem with trying to decipher this issue is that it can occur in different places i.e. it may look like custship but it could be another area causing it.
You can look at the chain of procedures that are still running from the procedure handle.
Normally if it was a client connection the deactivate Appserver logic as/deactivate.r cleans up any persistent procs you leave running (or possibly Epicor bugs leave).
However if you are automating things via 4GL and not handling errors or cleanup correctly you get this exact issue.

Hope that helps guide you.

Regards,

From: vantage@yahoogroups.com [mailto:vantage@yahoogroups.com] On Behalf Of reptcon
Sent: 08 August 2012 23:37
To: vantage@yahoogroups.com
Subject: [Vantage] SYSTEM ERROR: Attempt to define too many indexes for area 6 database



From time to time I get this error and all work being done by the process is undone:

[12/08/08@17:49:43.467-0400] P-001484 T-006836 1 AS -- (Procedure: 'server/bo/custship/custship.p' Line:0) SYSTEM ERROR: Attempt to define too many indexes for area 6 database DBI1484a06836. (40) (14675)

I've researched it and I know it is a known Progress problem.

custship.p shown but it happens with other business objects too.

Does anybody know a workaround, or when a fix will be available?

I'm trying to create shiphead/shipdtl records for palletized shipments, with hundreds of "packs". It takes forever, and then DIES ingloriously with this area 6 index problem.

It's going to send me to Area 51!

Thanks,
Chris



[Non-text portions of this message have been removed]
From time to time I get this error and all work being done by the process is undone:

[12/08/08@17:49:43.467-0400] P-001484 T-006836 1 AS -- (Procedure: 'server/bo/custship/custship.p' Line:0) SYSTEM ERROR: Attempt to define too many indexes for area 6 database DBI1484a06836. (40) (14675)

I've researched it and I know it is a known Progress problem.

custship.p shown but it happens with other business objects too.

Does anybody know a workaround, or when a fix will be available?

I'm trying to create shiphead/shipdtl records for palletized shipments, with hundreds of "packs". It takes forever, and then DIES ingloriously with this area 6 index problem.

It's going to send me to Area 51!

Thanks,
Chris
Try upping the -s(chunks of 1000) and -Bt(chunks of 1024) in your PF file
for that Appserver.

Also, that DBI1484a06836 is the name of the temp file that is being used to
generate and it's possible that it's just getting too big and you could be
running out of space on the drive or file size allowed.

Also, there could be a problem with the code in the program the way it is
written, and this would become an actual fix that would require Epicor.

Tried setting up the shipments in multiples instead of one big one to reduce
the load? Or is that not an option?

-----Original Message-----
From: vantage@yahoogroups.com [mailto:vantage@yahoogroups.com] On Behalf Of
reptcon
Sent: Wednesday, August 08, 2012 6:37 PM
To: vantage@yahoogroups.com
Subject: [Vantage] SYSTEM ERROR: Attempt to define too many indexes for area
6 database

From time to time I get this error and all work being done by the process is
undone:

[12/08/08@17:49:43.467-0400] P-001484 T-006836 1 AS -- (Procedure:
'server/bo/custship/custship.p' Line:0) SYSTEM ERROR: Attempt to define too
many indexes for area 6 database DBI1484a06836. (40) (14675)

I've researched it and I know it is a known Progress problem.

custship.p shown but it happens with other business objects too.

Does anybody know a workaround, or when a fix will be available?

I'm trying to create shiphead/shipdtl records for palletized shipments, with
hundreds of "packs". It takes forever, and then DIES ingloriously with this
area 6 index problem.

It's going to send me to Area 51!

Thanks,
Chris



------------------------------------

Useful links for the Yahoo!Groups Vantage Board are: ( Note: You must have
already linked your email address to a yahoo id to enable access. )
(1) To access the Files Section of our Yahoo!Group for Report Builder and
Crystal Reports and other 'goodies', please goto:
http://groups.yahoo.com/group/vantage/files/.
(2) To search through old msg's goto:
http://groups.yahoo.com/group/vantage/messages
(3) To view links to Vendors that provide Vantage services goto:
http://groups.yahoo.com/group/vantage/linksYahoo! Groups Links
Thanks Ned, I will try that.

I've been toying with the idea of creating ALL of the shiphead/shipdtl pairs in temp tables then sending the whole pallet down to the BO for update. But there is a sequence of calls which have to be made to assign the packnum, populate the shiphead, create the line, populate, and some final touchups (weight). I splice in a debugging log of what it takes to create one pack below. 11 seconds in this case, but usually 4-6 seconds (we were running a DMT while this was happening).

Doing a little reading I see that the memory ramification are approximately 1.1 * -Bt * -tmpbsize (in KB).

So if I quadrupled -Bt to 16384, I would have 1.1 * 16384 * 8K = approx 144MB. A lot of RAM! How does this extrapolate? Times 120 users? And each user session while active has 2-3 appserver connects. I better run this change by my DBA/LAN before diving in!

Here is our appserver startup -pf file, in case anyone with keen eyes sees anything amiss. We are on 9.05.607b with MSSSQL DB. SCADS of hardware.

-disabledeltrig
-Mm 1024 -mmax 65534 -Bt 4096 -s 8000 -yy 1970 -stsh 31 -inp 32000 -tok 4000 -TB 31 -TM 32 -D 500 -l 1000 -ttmarshal 5 -tmpbsize 8 -rereadnolock -lkwtmo 180
-d mdy -basekey ini
# 02.02.2012 CAH:
# -debugalert
# --------------
-T "E:\EPICORTEMP"
-db "E:\Epicor905\db\newdb\mfgsyssh" -RO
-db Epicor905 -dt MSS -ld mfgsys -Dsrv PRGRS_CONNECT,DSN=Epicor905,TXN_ISOLATION,1,PRGRS_NATIVE_LOCKWAIT,30000,PRGRS_NOWAIT_OVERRIDE,1
-cpinternal utf-8 -cpstream utf-8 -cprcodein utf-8 -cpcoll icu-uca

Creating a shiphead/shipdtl using BO Calls:

08/08/12 17:40:55 SCManager pick-order.ip pny/CreatePack.p : -- Top of loop, Order.Line.Rel Part/Type Pallet.Carton Pack.Line: 2477436.1.1 P-FD16GATT03-GE/MasterPack 1.134 0.0
08/08/12 17:40:55 SCManager create-shiphead.ip pny/CreatePack.p : ---- BOJ, viPacknum: 0 Order.Line.Rel 2477436.1.1 ASN: 00007514920090462182
08/08/12 17:40:56 SCManager create-shiphead.ip pny/CreatePack.p : -- Call# 1 CustShip.GetNewShipHead for table shiphead SysRevID: 0 Rowmod: ttshiphead.recid: <null> DBRowID: <null>
08/08/12 17:40:56 SCManager create-shiphead.ip pny/CreatePack.p : --- After GetNewShipHead #Records in ttShipHead: 1 Rowmods: A
08/08/12 17:40:57 SCManager UpdateMaster.ip pny/CreatePack.p : -- Call# 1 CustShip.UpdateMaster for table shiphead SysRevID: 0 Rowmod: A ttshiphead.recid: 26525952 DBRowID: <null>
08/08/12 17:40:58 SCManager UpdateMaster.ip pny/CreatePack.p : --- After UpdateMaster, pack is: 3003314 Line# 0 Errors: no #Records in ttShipHead: 1 Rowmods:
08/08/12 17:40:58 SCManager UpdateMaster.ip pny/CreatePack.p : EOJ-eTime: 1374
08/08/12 17:40:58 SCManager create-shiphead.ip pny/CreatePack.p : --- After Initial Update: 3003314 #Records in ttShipHead: 1 Rowmods:
08/08/12 17:40:58 SCManager create-shiphead.ip pny/CreatePack.p : --- After create of before-image in tt: 3003314 #Records in ttShipHead: 2 Rowmods: U,
08/08/12 17:40:58 SCManager create-shiphead.ip pny/CreatePack.p : --- After GetManifestInfo: 3003314 #Records in ttShipHead: 2 Rowmods: U,
08/08/12 17:40:58 SCManager create-shiphead.ip pny/CreatePack.p : ---- EOJ, viPacknum: 3003314 eTime: 1524
08/08/12 17:40:58 SCManager pick-order.ip pny/CreatePack.p : Checking NegativeInventory for part/whse/bin/lot/uom/conv/qty P-FD16GATT03-GE/NJ/SHIP/<lot>/CS20/20/1
08/08/12 17:40:58 SCManager create-shipdtl.ip pny/CreatePack.p : ---- BOJ, viPacknum/line: 3003314/0
08/08/12 17:40:58 Don Soranno Actions/RMAProcNew.p : BOJ-RMAProcNew.p
08/08/12 17:40:58 Don Soranno UpdateBefore Actions/RMAProcNew.p : Procedure UpdateBefore Started
08/08/12 17:40:59 SCManager create-shipdtl.ip pny/CreatePack.p : --- After GetNewShipDtl #Records in ttShipDtl: 1 Rowmods: A
08/08/12 17:41:01 SCManager UpdateMaster.ip pny/CreatePack.p : -- Call# 1 CustShip.UpdateMaster for table shiphead SysRevID: 122210000 Rowmod: U ttshiphead.recid: 26525952
8/08/12 17:41:01 SCManager UpdateBase127_A1
08/08/12 17:41:03 SCManager UpdateMaster.ip pny/CreatePack.p : --- After UpdateMaster, pack is: 3003314 Line# 0 Errors: no #Records in ttShipHead: 2 Rowmods:
08/08/12 17:41:03 SCManager UpdateMaster.ip pny/CreatePack.p : EOJ-eTime: 2772
08/08/12 17:41:03 SCManager pick-order.ip pny/CreatePack.p : Checking carton weight of pack# 3003314
08/08/12 17:41:04 SCManager pick-order.ip pny/CreatePack.p : -- Call# 1 CustShip.GetByID for table shiphead SysRevID: 122210001 Rowmod: ttshiphead.recid: 26525952
08/08/12 17:41:06 SCManager pick-order.ip pny/CreatePack.p : LastOfCarton eTime: 2563



--- In vantage@yahoogroups.com, Ned <TechnoBabbly@...> wrote:
>
> Try upping the -s(chunks of 1000) and -Bt(chunks of 1024) in your PF file
> for that Appserver.
>
> Also, that DBI1484a06836 is the name of the temp file that is being used to
> generate and it's possible that it's just getting too big and you could be
> running out of space on the drive or file size allowed.
>
> Also, there could be a problem with the code in the program the way it is
> written, and this would become an actual fix that would require Epicor.
>
> Tried setting up the shipments in multiples instead of one big one to reduce
> the load? Or is that not an option?
>
> -----Original Message-----
> From: vantage@yahoogroups.com [mailto:vantage@yahoogroups.com] On Behalf Of
> reptcon
> Sent: Wednesday, August 08, 2012 6:37 PM
> To: vantage@yahoogroups.com
> Subject: [Vantage] SYSTEM ERROR: Attempt to define too many indexes for area
> 6 database
>
> From time to time I get this error and all work being done by the process is
> undone:
>
> [12/08/08@17:49:43.467-0400] P-001484 T-006836 1 AS -- (Procedure:
> 'server/bo/custship/custship.p' Line:0) SYSTEM ERROR: Attempt to define too
> many indexes for area 6 database DBI1484a06836. (40) (14675)
>
> I've researched it and I know it is a known Progress problem.
>
> custship.p shown but it happens with other business objects too.
>
> Does anybody know a workaround, or when a fix will be available?
>
> I'm trying to create shiphead/shipdtl records for palletized shipments, with
> hundreds of "packs". It takes forever, and then DIES ingloriously with this
> area 6 index problem.
>
> It's going to send me to Area 51!
>
> Thanks,
> Chris
>
>
>
> ------------------------------------
>
> Useful links for the Yahoo!Groups Vantage Board are: ( Note: You must have
> already linked your email address to a yahoo id to enable access. )
> (1) To access the Files Section of our Yahoo!Group for Report Builder and
> Crystal Reports and other 'goodies', please goto:
> http://groups.yahoo.com/group/vantage/files/.
> (2) To search through old msg's goto:
> http://groups.yahoo.com/group/vantage/messages
> (3) To view links to Vendors that provide Vantage services goto:
> http://groups.yahoo.com/group/vantage/linksYahoo! Groups Links
>