• Brian Boorman (google)

    INSERT INTO #frist_1comments(…) -- frist comment get inserted

  • (nodebb)

    This is the SQL centipede. It's centimetring, not inching, along.

  • (nodebb)

    There is a very sensible rule of thumb here: "If it ain't broken, don't fix it".

    However, I wouldn't be surprised if there were no unit tests/integration tests available to test the upgraded database properly so they'd have to manually convince themselves of upgrade success.

  • Andrew (unregistered)

    TRWTF is SQL Sever 2000.

  • LCrawford (unregistered)

    TRWTF is always Oracle, even in today's WTF.

  • James (unregistered) in reply to Andrew

    Is it though? I mean yes using a 19 year old database engine is highly questionable. Sure they really should have upgraded before now. That said other than being a bit feature poor; I can't think of much wrong with SQLServer 2000. It ran and it ran well. You could optimize it effectively if you took the time to study the manual which was also very very complete and good. If I HAD to use nearly 20 year old database version; I would much much rather it be SQLServer 2000 than say Oracle 9 or some version of Sybase ASE from that era (even recognizing the heritage of SQL Server).

  • get off my lawn (unregistered)

    The real WTF is not explaining what's wrong with the code for people who don't know the language. If it runs then it's a matter of style rather than content, so at the very least show a better version.

    Remy: There's not much to explain. None of this code actually DOES anything. It's just a chain of methods X->Y->…->D->E->F, where F is the method that actually does things, and there's no reason to not just call F directly.

  • (nodebb)

    2 & 2 are 4, 4 & 4 are 8, 8 & 8 are 16, 16 & 16 are 32 [repeat ad nauseum]

    Inchworm, inchworm, measuring the marigolds You and your arithmatic, you'll probably go far. Inchworm, inchworm, measuring the marigolds Seems to me you'd stop and see how beautiful they are.

  • K.I.S.S. (unregistered) in reply to get off my lawn

    The only one who benefits from that much boilerplate is an iron supplier.

    Can you seriously tell at a glance what the WHOLE procedure does? You probably could with a single proc that had all the logic.

    Style is never an excuse for excessive obfuscation. Anyone saying otherwise is a conman.

  • Gumpy_Gus (unregistered)

    I've had to do things like that sometimes when the Holy Tablets ordain that you 're not allowed to build up exec strings, because "Injection". That means you have to submit n procedures to the database weasels and they have to meet to discuss and approve or deny each one. Security, you know. Because developers that are otherwise trusted with a billion-dollar business database can't be trusted to not do SQL Injection.

  • (nodebb)

    The guy who made these procedures was probably paid per line of code.

  • anonymous (unregistered)

    Plot twist: Fixing this is going to break something else that relies on being able to call one part of the compound-function individually.

  • löchlein deluxe (unregistered)

    Seeing something named "a7b" makes me reach for the vodka. Is this how OIDs were invented?

  • Kaewberg (unregistered)

    Hm.

    There are four different cases depending on vendor_code == 1 (which of course being a boolean can only have three values).

    All four cases just return the original data. Unless, of course, the temp tables aren't...

  • Barf4Eva (unregistered)

    TRWTF are stored procedures!

  • (nodebb)

    am I going crazy here or does the terminal sproc sp_inchworm_1wk_a9 not even do anything? this is just a totally absurd chain that eventually noops yeah? also what does this have to do with building up a parameter string? Isn't a big selling point of sprocs that you bind and send parameters in like function args, treated in such a way that they're effectively sanitized by method of handling?

  • Mel (unregistered)

    These are local temp tables, not global ones. Wouldn't the subsequent procedures fail because the temp tables are not in scope?

  • Erik (unregistered) in reply to Andrew

    SQL Sewer :P

  • (nodebb) in reply to Andrew

    I know, they even removed the facility to import properly quoted CSV. (Fortunately there was a character not used by my data set which I could use as a field separator.) Apparently 2017 at last knows how to import CSV again.

  • Jay (unregistered)

    There's something more to this. All this does is propagate the same data from one temp table to the next with nothing changing in-between other than the name of the temp table.

    https://www.sqlservercentral.com/forums/topic/temp-tables-and-table-variables-scope-and-persistence

    That article explains that temp tables exist only in the scope of the connection where they're created and cannot be assigned to the same name by different procs within the same connection. This may be a template for some type of calculation where the programmer did not know how to use actual queries but knew enough not to touch the actual data as best as they could by using temp tables. After the insert, the programmer would insert their actual logic and then pass on the data to the next proc for the next step, or even call another proc that assumes all these temp tables already exist. It would all have to be done in the same session and called every time.

    I can't imagine this is any more efficient than a query

Leave a comment on “Inching Along”

Log In or post as a guest

Replying to comment #:

Log Out

« Return to Article