10 ms·
You can do some insanely complicated stuff in a stored procedure. A favourite was versioning and updating a set of data across multiple tables as an atomic tran
by dwd 8y ago
You can do some insanely complicated stuff in a stored procedure. A favourite was versioning and updating a set of data across multiple tables as an atomic transaction.
Also MS SQL let you throw a data object (say XML) at a stored procedure, convert it to a table structure with some XPath (another useful black art like regex) and use that as the input to a single INSERT.
- AmericanChopper 8y ago>You can do some insanely complicated stuff in a stored procedure. You’re giving me flashbacks to stored procs that directly invoke java methods, and batch scrips that load client supplied data from and FTP server into external tables.
- dwd 8y agoxp_cmdshell always seemed like a really bad idea. The sql server agent was easy and reliable for scheduling so it made sense to let it run the whole process.
- Shacklz 8y ago> You’re giving me flashbacks to stored procs that directly invoke java methods A legacy application I once worked at used this extensively, and good grief it gave me nightmares. How anyone ever thought this is a good idea to use is beyond me; that stuff is not maintainable at all.
- AmericanChopper 8y agoYeah, the business logic was all over the place. Everything needed to be reverse engineered any time there was a problem, or if you wanted to make any changes. To make it worse, the app had about 300 scheduled tasks that were a mixture of batch files, SQL scripts and java classes. None of which had source code, most of which were slightly different and essentially operated as mysterious black boxes. We ended up having a copy of JD-GUI on all the production servers because we needed to decompile for debugging so often.