WorkArounds2=8192

[smoser16]

I'm trying to make calls into Progress using the ODBC Merant 3.60 32-BIT Progress SQL92 v9.1D driver in C#. I've been getting the following error on some records:

Column column_name in table PUB.table_name has value exceeding its max length or precision.

The Progress database belongs to a 3rd party application and I have no control over it what so ever. The company that provides this application told me to add WorkArounds2=8192 into the registry for the ODBC data source, but it appears to have no effect.

Does anyone know what WorkArounds2=8192 is supposed to do? The only documentation on WorkArounds2 (linked here) that I can find does not say anything about the 8192 value.

 

[Casper]

If you have installed SP6 or higher then run dbtool, option 2 for your database.
The Progress database has, in contrast to SQL databases, variable length fields. The sqlwidth in a progress database is default twice the display format. It is easy to get more data in a field then this value.
dbtool sets slqwidth correctly.
You should run this tool on a daily basis.

Casper.

 

[Casper]

Hmm, I should read better
Let me rephrase the previous post:
You must tell the company taht provides this applicationt that, in order for you to query on the database, they should run dbtool daily (or at least periodically). It is best to run it in the evening hours.

Casper.

 

[smoser16]

Thanks for your reply Casper, but the database is owned by a 3rd party and I have zero control over it. They tell me that they run dbtool once a week, but I get the error constantly.

 

[Casper]

Well, in theory , the errors should go away in time, because there is a limit of 32K for a record

Maybe you can ask them to set sqlwidth much higher then needed for the affected tables. I suppose you get the errors on the same tables....

The only KB entry for WorkArounds2=8192 doesn't seem to involve your problem nor the Progress version you're working with: http://progress.atgnow.com/esprogress/Group.jsp?bgroup=progress&id=P116845

Casper.

 

[smoser16]

That's pretty much the conclusion that I've drawn, that WorkArounds2=8192 does not address the issue I'm seeing. I think they've sent me down the wrong path since anytime I ask for more information they just send the same instructions again. Looks like I'm stuck.

 

[Casper]

Hmm, difficult.

Did you already mentioned what tables are problematic to you and asked if they can confirm that those are the tables which are altered by dbtool on their weekly run?
It seems rather strange to me that the fields keep getting bigger every time. Normally this would even out after a couple of weeks.
Can it be that this is a new application?

Casper.

 

[smoser16]

Yes, they've been given table and column names. They are an extremely difficult company to deal with which is why if I could solve it on my end that my life would be so much easier. It is actually quite an old application, I think more than 10 years old.

 

[smoser16]

My latest attempt is to use the LEFT function in my SELECT to trim the values myself, but I still get the same error, even in SQL Explorer.

 

[doom1701]

The error is generated at the data retrieval level, so nothing you can do on your code is going to make it go away, other than not returning the field that is bigger than it's stated ODBC size.

We recently learned of dbtool, and I never would have imagined that fixing the issue was so simple. We've got a pretty hefty database, too, and it didn't take too long to update all of the fields lengths that needed updating. Your DB host may be running it regularly, but there's a few options (just like any Progress tool), and if they aren't running it to scan for oversized fields and fixing the ODBC length for that field, it's not doing you any good.