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

Error in ODBC connection

  • Hello,

    I'm getting an error message when I try use MS Access through ODBC connection to connect to our Progress database.  The error is "Array element value overflow (12664).  I already have several table linked but I get this error on one of the linked tables.  Does anyone have an idea?

    Thanks

    Jody

  • The version might be important too know for this issue.

    Also, how does that table look like?

  • Mike,

    I'm on version 10.1B.  I'm not sure what you are looking for when you say "Also, how does that table look like?".  Let me know and I will get you the information.

    Thanks,

    Jody

  • say "Also, how does that table look like?". Let me know and I will get you the information.

    Maybe a field and index report from the dictionary?

  • Mike,

    Attached is a pdf of the data dictionary report.

    InvcDtl_Report.pdf

    Thanks,

    Jody

  • I guess one of your CHARACTER fields in that table contains more characters than the defined SQL width of that field. That's not an issue for the 4GL (variable field length) but critical for ODBC clients. Use the SQL width dialog of the data dictionary to fix that.

    K-Base ID 124558

    Title: "[DataDirect][OpenEdge JDBC Driver][OpenEdge] Array element value overflow. (12664)"

    Created: 06/22/2007 Last Modified: 06/28/2007

    Status: Unverified

    Symptoms:

    • [OpenEdge JDBC Driver][OpenEdge] Array element value overflow. (12664)

    • Char array column test is defined with 2 extents and SQL-Width of 3

    • Executing the following query fails:

    UPDATE PUB.Customer SET test1='aaa' where "Cust-Num"=1;

    SELECT test1 FROM PUB.Customer where "Cust-Num"=1;

    Facts:

    • OpenEdge 10.1B

    Cause:

    • Accessing a char field containing more characters than defined with SQL-Width via the SQL-92 engine.

    In the specific case each column extent for the specific record was updated to contain 3 characters which are then in total 6 characters for the two extensions. The SQL-Width for the record selection of the individually extent was sufficient but not to select the whole array.

  • Mike,

    It looks like you know what the problem is.  Forgive me, for not understanding how to fix.  Is there more specific steps to fix the problem?   Is it in the ODBC driver that I need to add information or in MS Access?

    Jody

  • It looks like you know what the problem is. Forgive me, for not understanding how to fix. Is there more specific steps to fix the problem? Is it in the ODBC driver that I need to add information or in MS Access?

    It's a property of CHArACTER fields in the Progress Data Dictionary. There is nothing (to my knowledge) that you can change at the ODBC driver or Access.

  • From the data dictionary:

    Select the table, then Options -> Adjust Field Width

    See attachment.

  • Your report shows many array fields (extent fields). None of them is character.

    I guess it's one of the integer or decimal array's that need a higher SQL width. I'd try to set them to something very large, like 100 and see if that solves the issue. Then I'd try to narrow down to a width that's appropriate. Progress defaults we SQL width based on data-type and character format. For extents the SQL width seems to be for the whole array and not just the individual members.

  • I found a document that I attached.  In section 6 under troubleshooting there is a SQL Width that looks like what I need to do.  It uses the "dbtool".  By using this tool it doesn't change anything to my database?

    V803400_Instructions.rtf

  • That should be o.k. ;-) But a backup doesn't hurt either.

    Settings the SQL width shouldn't affect your table's CRC values, so that shouldn't require a recompile either.

  • Glad you discovered dbtool.  That is where I would have pointed you if I had joined this conversation earlier.  Manual adjustment of SQL Width is an easy quick fix, *IF* you know what value you need to set it to.  dbtool not only takes care of figuring out what value you need, but can do so for the entire database.  Use it regularly to avoid surprises!

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

  • Thomas,

    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.

    Jody

  • I'm not maintaining a production database, so it has been a while since I have run it.  Perhaps you should run us through the questions and your answers?

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