Hi guys, I'm new with Progress and have a strong SQL background. I understand that character field in progress have a format (or display up to X character) size, while in SQL the size of a character field is a maximum lenght.
With that said, we have a *few* hundred program which export data from progress to some sql database through some CSV files.
Right now, for length purpose we trim down each character field to their format size before exporting them in the CSV (to make sure they don't exceed the size in the SQL database, would have been better to do it at the SQL level, but anyhow).
My question is:
Is there a way to do all in one step (during the read operation ask the progress database to limit the field length to the format size) without having to trim down programmatically?
can't automatically trim during the read operation. however, there is a maximum width attribute that is part of the column definition and a client startup parameter that will enforce the maximum width in the 4GL.
> What is the startup parameter to enforce the maximum width of a column?
What is the -checkwidth parameter for?
I guess -checkwidth was just what Gus was referring to.
"-checkwidth 2" prevents storing more data than what is defined in max width.
"-checkwidth 1" gives just a warning when storing data beyond max width.
DBTOOL can be used to report/fix potential problems with max width:
http://knowledgebase.progress.com/articles/Article/P24496
And here's how you can programmatically go through the database to detect fields that exceed the max width setting:
http://knowledgebase.progress.com/articles/Article/P13348
or
http://knowledgebase.progress.com/articles/Article/000044626
And another related article:
http://knowledgebase.progress.com/articles/Article/P128368
The field formats in Progress are just display formats. You can define a character field with x(3) as its format and still stuff it full with 100's of characters. Therefore you can't automatically truncate the values based on the format.
can't automatically trim during the read operation. however, there is a maximum width attribute that is part of the column definition and a client startup parameter that will enforce the maximum width in the 4GL.
@gus. What is the startup parameter to enforce the maximum width of a column? Is it a good practice? Can we dynamically resize a column (mostly enlarge it) without having to stop the database?
I personnally think this would solve my problem and make progress work more like a regular database.
> What is the startup parameter to enforce the maximum width of a column?
What is the -checkwidth parameter for?
I guess -checkwidth was just what Gus was referring to.
"-checkwidth 2" prevents storing more data than what is defined in max width.
"-checkwidth 1" gives just a warning when storing data beyond max width.
DBTOOL can be used to report/fix potential problems with max width:
http://knowledgebase.progress.com/articles/Article/P24496
And here's how you can programmatically go through the database to detect fields that exceed the max width setting:
http://knowledgebase.progress.com/articles/Article/P13348
or
http://knowledgebase.progress.com/articles/Article/000044626
And another related article:
http://knowledgebase.progress.com/articles/Article/P128368
Reply by youngblood@gus. What is the startup parameter to enforce the maximum width of a column? Is it a good practice? Can we dynamically resize a column (mostly enlarge it) without having to stop the database?
I personnally think this would solve my problem and make progress work more like a regular database.
Stop receiving emails on this subject.Flag this post as spam/abuse.
-- Tom Bascom 603 396 4886 tom@greenfieldtech.com[/collapse]
Unfortunately, Progress has to "play nice" in a world that doesn't always recognize the "better way" when they see it. One of Progress' many strengths is their dedication to maintaining backward compatibility. It's ironic that the "regular" db's do that too :-)