10.2B08: Option auto adjustment sql-width available? - Forum - OpenEdge RDBMS - Progress Community

10.2B08: Option auto adjustment sql-width available?

 Forum

10.2B08: Option auto adjustment sql-width available?

This question is answered

Is there an option available that increase database sql-width on the fly to the maxium string length in the record(s)?
We run a replication and creates ddl and dump files and load them in  SQL reporting database.
Currently i have to run dbtool every time to prevent length errors in MS SQL server.

All Replies
  • ChUIMonster
    By far, test best idea is for MS, Oracle and company to stop making
    excuses for their inadequacies and fix SQL.

    They have bad implementations. The onus should be on them to fix it.
    They've had 30 years. Time to get off their butts.

    That is true, but in practice the OpenEdge team is blamed EVERY TIME the integration falls over, because these vendors succeeded for 30 years to convince their followers not only that it is OK to have these restrictions, but that it MUST be like that.

    Although none of the SQL users can tell you WHY is must be like that, they will always tell the powers that be that Progress is "violating the standard" when it saves all the user's data, rather than throwing away some of it. Even sensible managers can Google that and see that the SQL implementations all have this limitation. For some reason, nobody but us ever ask: But why? A futile question, really, because they will tell you: That is the standard. Still, a standard is only useful if it serves a purpose, but if you ask for the purpose the dodge the question or ramble non-sense until everybody is confused. And then everybody conclude that since OpenEdge keeps all their data and other systems do not, OpenEdge is the inferior product.

    Simon L Prinsloo

    www.vidisolve.com

  • Another alternative to increasing the WIDTH may be to get the SQL guys what they expect, truncated data. Let the RDBMS truncate the data for the SQL requests at the SQL-WIDTH.

    Simon L Prinsloo

    www.vidisolve.com

  • Simon, that would basically produce data corruption during update and likely unique key conflicts. No good way, I believe.

    Von meinem Windows Phone gesendet

    Von: Simon L. Prinsloo
    Gesendet: ‎17.‎10.‎2014 07:16
    An: TU.OE.RDBMS@community.progress.com
    Betreff: RE: [Technical Users - OE RDBMS] 10.2B08: Option auto adjustment sql-width available?

    Reply by Simon L. Prinsloo

    Another alternative to increasing the WIDTH may be to get the SQL guys what they expect, truncated data. Let the RDBMS truncate the data for the SQL requests at the SQL-WIDTH.

    Stop receiving emails on this subject.

    Flag this post as spam/abuse.

    Architect of the SmartComponent Library and WinKit

    Consultingwerk Ltd.

  • Oh! Yes, did not think about that. But then again, I've never encountered anybody actually updating through the SQL, most likely because we never allow that.

    Simon L Prinsloo

    www.vidisolve.com

  • Hallo

    For some reason my post on this matter went onto another thread.

    There is also the OpenAccess driver where you could write ABL code to only expose the data in a way that SQL can handle it.

    Thank you

    A Venter

  • ... and i answered in the other thread too, no idea how Mike created the new thread.

    I compared the time of using "export" or create it dynamically with abl to create a correct format for sql bcp load.

    ABL export method needs currenty for a full dump 30 minutes, the same with ABL code to create the string with some small checks >5 hours.

    The string functions in ABL seems to be very slow, in C# there is a stringbuilder with a good performance.

    So wie decided to use the "fast" ABL export command (with temp .p files dynamically generated for every table) and fast string conversion function in C# with many threads which use 100% of every CPU.