S
Simon L. Prinsloo
Guest
Ok, so to summarise, automatically increasing the SQL width as soon as a record is created will make pre-existing SQL processes crash. Someone may have to restart the process, which will now run fine. But still, we had the minor inconvenience of a crash... That does not sound much better than the status quo? Or does it? For me the status quo is this: Once a longer value enter the database, ALL SQL processes, new and old, will crash. They will be restarted automatically and recreashed. Eventually the top brass will notice that the dashboard did not change for 10 minutes, because these SQL processes, where ever I encounter them in the market, are used to populate data warehouses. So the guy at the top jumps on the dashboard people. They investigate why the auto start script is not working and find the problem in the log. First, the blame OpenEdge and the OpenEdge team. Then they call the OpenEdge support team and complain. The Pointy Haired Boss is still screaming. So now the OpenEdge team runs a db maintenance utility that scans the ENTIRE TABLE to locate the offending record, flushing all the buffers, messing around with the disks and slows down all performance. So now the OpenEdge takes the blame for the dead dashboard AND the slowdown in operations. And then everything is fine for a few days and the cycle repeats. I would vote for the (often unnoticed) once-off SQL crash ASAP, but I will not waste a vote on improving concurrency. That can be fixed in v. 103.3 circa 2081 for all I care....
Continue reading...
Continue reading...