"Width" column - Data Dictionary

[rzr]

Hello,

On the Data Dictionary tool..
Menu - Options - Adjust Field Width (image attached below)



What is the significance of the column "Width" (image attached below) ?? Any idea where / when this is used ??

 

[Casper]

The width column represents the sql width of the column. Progress has variable column widths sql has fixed ones. So if you query with SQL a Progress database and the data in it exceeds the width value for a particular column it raises an error. By default the width column is twice the display format.
Progress has made an option in the dbtool utility to automatically set the value for width for all columns of all tables. You can do this with a certain persentage above highest value. So SQL queries will not fail. This tool should e run on a daily basis if you are sing SQL.

There is also a client parameter (-checkwidth n ) which checkes if you enter a value greater then the value of _width field for a particular field in the database.

HTH,

Casper.

 

[Stefan]

Its the width used by the sql92 engine (used by odbc / jdbc). Fields larger than this width will error when queried using sql92. The default is twice the width based on the ABL format.

 

[rzr]

Okay, thanks for the info.... so if i were to change the format of a field from X(8) to x(50).... I should be changing the sql width too..huh..? Or Can i use dbtool to adjust and sql width ? well, let me try on my local db...i'll let you guys know how it goes... thanks for the quick response...

 

[Casper]

Use dbtool. That runs online and the cache is also automatically refreshed. And there is not a real relation between display format and needed sql width. It is just an assumption being made by Progress. You can put 30K in a field of format 'X(1)'.

 

[Stefan]

It depends on your opinion of 'display format'.

We also support Oracle & SQL Server databases (which have hard widths) using the DataServer so need to find the lowest common denominator and have a hard field width. Therefore we decrease the width to equal the display format and use the -checkwidth parameter so that the OpenEdge client also complains when the width is exceded making the OpenEdge database behave more like the other two.

 

[tamhas]

Format <> width. The dictionary format is a *default* to use in displays, but has no control over what is stored in the field. One can have an X(8) format and put 3000 characters in the field. The format which actually controls display is the one in the program doing the display ... this is only the default if nothing is specified there. SQL width is entirely independent of that. SQL is upset if you try to read something wider than the width. So, one wants the SQL width at least as wide as the actual data, whatever the source. E.g., you might have a memo field where the default format was X(30) to show just the beginning if you didn't say anything else, but in selected places you would use an editor widget to see the whole thing. But, if you then stick 3000 characters into the field, you need the SQL width to be at least 3000 to avoid an error.

 

[Casper]

It depends on your opinion of 'display format'.

We also support Oracle & SQL Server databases (which have hard widths) using the DataServer so need to find the lowest common denominator and have a hard field width. Therefore we decrease the width to equal the display format and use the -checkwidth parameter so that the OpenEdge client also complains when the width is exceded making the OpenEdge database behave more like the other two.

Ok I understand, you use the checkwidth parameter to enforce the display format to be an 'absolute' format for the application. It is essential then that all client sessions use the parameter. Including progress editors and batch procedures. And I suspect special action also needs to be taken for instance when importing data from external sources, because I suspect that you dont want to error out during an import of large batch files.
But in my opinion even if you do so, display format is just wat it is. It is a format Progress uses to display the data. Not more not less.

Regards,
Casper.

 

[Stefan]

Yes, display format is display format. But, since SQL and Oracle databases (and the Progress SQL92 side) have a requirement to have a hard width it is necessary to have something similar on the ABL side of things.

Note that we do not rely on clientwidth to complain - our business logic enforces field widths functionally. If there are bugs there, then this will lead to errors on Oracle / SQL which we can also get on OpenEdge by using clientwidth.

 

[Casper]

Understood. Just wanted to clarify it to the OP.