You are using an out of date browser. It may not display this or other websites correctly.
You should upgrade or use an alternative browser.
You should upgrade or use an alternative browser.
temp-table fields
- Thread starter sureshp
- Start date
You get this when a statement is too big.
Usually it happens when setting up frames and the solution there is to split the define frame statement into two define frames.
However, you can't do that when defining a temp-table ....
So, you need to make the define temp-table statement shorter.
Several solutions might be:
1. Shorten field names
2. Don't include field labels/column labels in the temp-table, use them in frame statements.
3. Have you any fields such as address1 address2 address3 that are not used in an index but could be defined as an array?
4. Is the temp-table similar to an existing table? If so, you could use "define temp-table t_table like product" then add extra fields, basing it on a product table.
5. You could split the temp-table in two, defining two temp-tables and having a unique field to link the two together. Then you would have to find both at the same time, create both, display both. It's a bit more coding but allows you to effectively have very large temp-tables.
If you could post the temp-table definition then we could give some examples of how to shorten it.
Usually it happens when setting up frames and the solution there is to split the define frame statement into two define frames.
However, you can't do that when defining a temp-table ....
So, you need to make the define temp-table statement shorter.
Several solutions might be:
1. Shorten field names
2. Don't include field labels/column labels in the temp-table, use them in frame statements.
3. Have you any fields such as address1 address2 address3 that are not used in an index but could be defined as an array?
4. Is the temp-table similar to an existing table? If so, you could use "define temp-table t_table like product" then add extra fields, basing it on a product table.
5. You could split the temp-table in two, defining two temp-tables and having a unique field to link the two together. Then you would have to find both at the same time, create both, display both. It's a bit more coding but allows you to effectively have very large temp-tables.
If you could post the temp-table definition then we could give some examples of how to shorten it.
Hi,
If you're running Progress 9 or higher, you could also try and use dynamic temp-tables :
Code:DEF VAR ttHnd AS HANDLE NO-UNDO. CREATE TEMP-TABLE ttHnd. ttHnd:ADD-NEW-FIELD("monChamp1","char"). ttHnd:ADD-NEW-FIELD("monChamp2","char"). ttHnd:ADD-NEW-FIELD("monChamp3","char").
If you really need to define a static temp-table of this size you can add
in the startup of your progress session the -inp parameter with a number > 4096. ie 10000. usually it is in a pf file, or in the shortcut of your progress application.
As RKR already suggested, the easiest way to try and avoid the error is to increase the -inp parameter.
In this case, you can create a new shortcut and the only thing you have to do is set the following at the Target (Windows example):
<progressdirectory>\bin\prowin32.exe -inp 10000
After running this, you can connect to the database in the Procedure Editor with
connect -db <databasename> -H <hostname> -S <portnumber>.
Just posting this to an addition to RKR's suggestion.
In this case, you can create a new shortcut and the only thing you have to do is set the following at the Target (Windows example):
<progressdirectory>\bin\prowin32.exe -inp 10000
After running this, you can connect to the database in the Procedure Editor with
connect -db <databasename> -H <hostname> -S <portnumber>.
Just posting this to an addition to RKR's suggestion.