Kbase P139875: ADM: Is there a limit on the number of fields in a SmartDataObject (SDO)?
| Autor |
Progress Software Corporation - Progress |
| Acesso |
Público |
| Publicação |
22/01/2010 |
|
Status: Unverified
GOAL:
ADM: Is there a limit on the number of fields in a SmartDataObject (SDO)?
GOAL:
Is the limit on on the number of fields in an SDO higher in OpenEdge 10.1C than in Progress 9.1E?
GOAL:
What is the function and size of the Input Characters (-inp) client session startup parameter in Progress 9.1x and OpenEdge 10.1x?
GOAL:
What is the function and size of the Token (-tok) client session startup parameter in Progress 9.1x and OpenEdge 10.1x?
GOAL:
Does the successful building of an SDO with a large number of fields guarantee its usability as a Data Source for a SmartDataBrowser (SDB) or a SmartDataViewer (SDV)?
GOAL:
Is it possible to modify the AppBuilder SDO generated code and make an SDO with a large number of fields work properly as a Data Source for an SDB or an SDV?
FACT(s) (Environment):
Windows
Progress 9.1E
OpenEdge 10.1C
FIX:
There is no absolute number set as limit on the number of fields one can add to an SDO and there is no difference between Progress 9.1x and OpenEdge 10.x in how the maximum number of fields in an SDO may be reached. The maximum number of fields that can be successfully added to an SDO is a function of the following variables:
1. The size of the Input Characters (-inp) client session startup parameter. This parameter sets the maximum number of characters allowed in a single 4GL/ABL statement. In Progress 9.1E, the default is 4,096 characters and the maximum is 32,000 characters. In OpenEdge 10.1C, the default is 4,096 characters and the maximum is 32,000 characters.
2. The size of the Token (-tok) client session startup parameter. This parameter sets the maximum number of tokens allowed in a single 4GL/ABL statement. In Progress 9.1E, the default is 1,024 tokens and the maximum is system dependent and limited only by available system memory. In OpenEdge 10.1C, the default is 3,000 tokens and the maximum is system dependent and limited only by available system memory.
3. The lengths of the fields involved. More short named fields can be successfully added to an SDO than long named ones. This is a consequence of the fact that the lengths of the filed names decide on how fast the 32,000 character limit on the length of a 4GL/ABL statement is reached.
The successful building of an SDO with a large number of fields does NOT guarantee its usability as a Data Source for an SDB or an SDV. Indeed an SDO may be successfully built with a large number of fields only to prove unusable as a Data Source for a SmartDataViewer due to the limitation on the size of the frame of the SmartDataViewer and unusable as a Data Source for a SmartDataBrowser due to the 32,000 character limit on the length of a 4GL/ABL statement.
It is possible to modify the AppBuilder SDO generated code using the Procedure Editor and make an SDO with a large number of fields work properly as a Data Source for an SDB and/or an SDV. However, these manually edited procedures will most likely be corrupted if ever opened and saved again in the AppBuilder.
Although it is possible to modify the AppBuilder generated SDO code in the Procedure Editor to make such an SDO properly work as a Data Source for an SDB or an SDV, this is neither recommended not supported. It is far more efficient to split the SDO or to selectively add only the fields that are truly needed by the visual components of the application.