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.
ChUIMonsterBy 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
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.
this post as spam/abuse.
Architect of the SmartComponent Library and WinKit
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.
... 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.