Error in ODBC connection - Forum - OpenEdge General - Progress Community
 Forum

Error in ODBC connection

  • Thank you for your response. I'm currently in the process of testing this dbtool on our test database. Unfortunatly, it has some questions after I make selection #2 that I don't know the answers to. I made a guess at them, but the results showed no changes. Any idea's.

    What answer did you give?

  • I attached a screenshot of the information I entered.  As you can see the dsmUserConnect failed.

    dbtool_screenshot.rtf

  • jmannett@midamericamfg.com schrieb:

    I attached a screenshot of the information I entered.  As you can see the dsmUserConnect failed.

    That issue may actually have a number of causes. Did you try to restart the DB server and try again?

    I suggest that you check the OpenEdge K-Base on http://progress.atgnow.com/esprogress/results.do, enter dsmUSerConnect failed on the search field at find solutions by problem and work through the solutions. The dbtool is not able to connect to your DB. Either the user count or the server count is exceeded or another configuration issue.

  • Is the DB server up or down when you are doing thig?  If the server is up, you can't pick single-user.

    Consulting in Model-Based Development, Transformation, and Object-Oriented Best Practice  http://www.cintegrity.com

  • Thomas,

    No, I stopped the database.

    Thank you,

    Jody Mannetter

  • I stopped the database before using the dbtool.

  • I finally was able to get the dbtool to run.  I had to start the database and appservers. I used the following parameters;

    1.5

    Padding % above current max: 10

    all

    all

    3

    It ran and showed 17 changes.

    I connected using Excel and got the same error "Array element value overflow. (12664)".  I did isolate the field in the table that is giving me a problem.  Any other ideas?  At least I'm learning a lot.

    Thanks,

    Jody

  • It ran and showed 17 changes.

    I connected using Excel and got the same error "Array element value overflow. (12664)". I did isolate the field in the table that is giving me a problem. Any other ideas? At least I'm learning a lot.

    I'd try much higher values... to see if that helps anything at all.

    If not, I'd consider talking to Progress tech support.

  • AppServers are not relevant to dbtool.

    What do you mean by connect 1.5?  As far as I know, it only takes integers for the number of threads.

    Tell us about the offending field?  Is it character?  Does it have an extent?  If it has an extent are you using ProElement to access individual elements?

    One semi-random theory is that if you had a character field with an extent, that the SQL Width might apply to the element.  Without PROELEMENT(), it will return all the values of all the extents concatenated in one result ... which would be a lot longer!  You might get around this by manually setting the SQL width to something like the maximum sum of all of the lengths of all of the extents plus 10% or something .... but I don't know what you are going to do with the result.

    Consulting in Model-Based Development, Transformation, and Object-Oriented Best Practice  http://www.cintegrity.com

  • Tell us about the offending field? Is it character? Does it have an extent? If it has an extent are you using ProElement to access individual elements?

    One semi-random theory is that if you had a character field with an extent, that the SQL Width might apply to the element. Without PROELEMENT(), it will return all the values of all the extents concatenated in one result ... which would be a lot longer! You might get around this by manually setting the SQL width to something like the maximum sum of all of the lengths of all of the extents plus 10% or something .... but I don't know what you are going to do with the result.

    The table in question didn't have CHARACTER Extents. The Dictionary report is attached.

  • I solved the problem.  Once I figured out the field that was causing the problem I used the Progress Data Dictionary.  The field was set at a width of 4 and the format was >>9.  I changed the width to 25 and it works!!!   If it wasn't for both of your help, I would not have gotten it.

    Thank you,

    Jody

  • Of course, now you have to figure out why there is a value in that field larger than 999 ....

    Consulting in Model-Based Development, Transformation, and Object-Oriented Best Practice  http://www.cintegrity.com

  • The thing that really irritates me is that the name of the field is InvcDtl.Obsolete803-RepSplit.  Epicor in their database renames obsolete fields like this.  So this field is not used in the application at all.

  • Silly practice on Epicor's part ... but it does raise the question of why you want to pull the value into Excel if the field is not used in the application.

    Consulting in Model-Based Development, Transformation, and Object-Oriented Best Practice  http://www.cintegrity.com

  • Of course, now you have to figure out why there is a value in that field larger than 999 ....

    If I'm not mistaking, Epicor does also use .NET Clients connected thru the .NET Proxy. That won't care about ABL formats at all.

    The values might be the result of a calculation, not a user's input.

    The values might have been entered in an ABL frame overriding the dictionary default formats.

    There are so many reasons why the data might not be compliant to the dictionary format... It's probably very hard to answer above question.