• Josh (unregistered)

    Also I'm assuming the REPLACE_ is a clever way to do a, huh, parameter?

  • (cs) in reply to ObiWayneKenobi
    ObiWayneKenobi:
    ClaudeSuck.de:
    If you do you will have to take the responsibility when the business people notice that the results are different from what they were before. And if you tell them at that moment that YOU made this change I don't want to be in your shoes.

    Speaking from experience, it's more fun when the original report was outright wrong and performed incorrect calculations, and you're told to change the new one back to give bad results so it matches the old reports.

    So you had to go through this, too. :D The reason was that they had the habit of "tuning" the numbers in order to reflect the desired results. This was OK because many knew about the the problem. A correct report would have shown the real world, but who likes that? Big fun, indeed.

  • (cs) in reply to by
    by:
    ClaudeSuck.de:
      ------
  |    |
  v    ^
TRWTF is

    sry

    Huh?

    captcha: eros

    Not quite clear immediately when ASCII is used. So here is the long form:

    TRWTF is TRWTF is TRWTF is TRWTF is TRWTF is TRWTF is TRWTF is TRWTF is TRWTF is TRWTF is TRWTF is TRWTF is TRWTF is TRWTF is TRWTF is TRWTF is TRWTF is TRWTF is TRWTF is TRWTF is TRWTF is TRWTF is TRWTF is TRWTF is TRWTF is TRWTF is TRWTF is TRWTF is TRWTF is TRWTF is TRWTF is TRWTF is TRWTF is TRWTF is TRWTF is

    ... snip

  • (cs) in reply to MarkJ
    MarkJ:
    Salami:
    What is a better way of doing this in SQL?

    REPLACE(REPLACE(REPLACE(REPLACE(REPLACE( REPLACE(REPLACE(REPLACE( REPLACE(REPLACE( REPLACE(Documents.Destination,' ',''),')', ''),'(',''),'-',''),'/',''),'.',''),'*',''), ',',''),';',''),'',''),'-','')

    IMO, it's better to do this kind of thing in the user interface before it ever gets near the database!

    When you have one and only one interface that's OK. What about data coming from external sources like buy orders from different shops using different software (like Excel databases) and the like?

  • TeaDrinker (unregistered) in reply to Grammer Nazi
    Grammer Nazi:
    Detritus:
    Robyrt:
    But imagine how easy this is to deploy! Just update one line in a config file and your good to go!

    FTFY.

    No, the original poster was correct, and you're just an idiot.

    I think he ran the post through the SQL in the article first to fix it.

  • Not of this Earth (unregistered) in reply to TeaDrinker

    Truly, The Real Wut Da F**k. Awesome.

  • Darth Paul (unregistered) in reply to ClaudeSuck.de
    ClaudeSuck.de:
    Jason Y:
    I think it's better to go ahead and refactor as you go, making the code self-documenting, than to try documenting nasty code. You shouldn't use it prior to refactoring because programming against a well-documented mess is less productive than refactoring the mess to something clean and then programming against it. Simple, clean interfaces / contracts are more important than documentation, imo.

    You are right in your wishful thinking. However, I see queries like that quite often.

    Be sure to NEVER EVER refactor such a thing. Generally, nobody remembers old business rules and why they were there. "Documentation? Which documentation? We have one which is nearly up to date. Just "some" changes are not there. You'll have to find out which." So, they are just left in place. Refactoring impossible. If you do you will have to take the responsibility when the business people notice that the results are different from what they were before. And if you tell them at that moment that YOU made this change I don't want to be in your shoes.

    So don't change a hi-tech 16 valves 4 cylinder engine into a spinning wheel just because it makes a car run, too. You won't get very far.

    But I agree that it is difficult understand what exactly this thing is really producing. And when you imagine that the entire query is maybe only executed to retrieve a list of ID_FAX_LOGs (the rest is not used but you never know, so leave it) in order to produce a different report...

    I suspect that most people ensure that refactored code produces the same result. That's how refactoring works.

  • theWebalyst (unregistered) in reply to BC

    Ok, so no credits but can we infer the author: Bill Gates, Steve Jobs, Bill Joy... Homer Simpson?

    Mark

    theWebalyst.com Web Marketing and WordPress Websites

  • Anonymous Crowbar (unregistered) in reply to dgvid

    The Windows Registry... The name alone is vomit-inducing...

  • (cs) in reply to Socker-Conny
    Socker-Conny:
    boog:
    Indexing a computed column isn't so bad, but setting up the indexed view in SQL Server is so tricky on any substantial database that it's fairly accurate to say the indexed view is "not supported"

    You mean like:

    create view MyView
with schemabinding
as
<query goes here>;

create clustered index MyIndex
on MyView (<candidate key for view>);

    Is that so hard? To someone who writes SQL once a year perhaps, but to someone who does this for a living?

    by:
    Thanks, that's what I actually meant but I forgot the exact details since it was 4-5 years since I came across this issue. I can recall many rediculous limitations, and ending up abandoning it altogether.

    There are some limitations, like that you can't use aggregates...

    Or LEFT JOINs...

  • Swedish tard (unregistered) in reply to ClaudeSuck.de
    ClaudeSuck.de:
    ObiWayneKenobi:
    ClaudeSuck.de:
    If you do you will have to take the responsibility when the business people notice that the results are different from what they were before. And if you tell them at that moment that YOU made this change I don't want to be in your shoes.

    Speaking from experience, it's more fun when the original report was outright wrong and performed incorrect calculations, and you're told to change the new one back to give bad results so it matches the old reports.

    So you had to go through this, too. :D The reason was that they had the habit of "tuning" the numbers in order to reflect the desired results. This was OK because many knew about the the problem. A correct report would have shown the real world, but who likes that? Big fun, indeed.

    I'd probably handle that by keeping the correct one and prepending "Correct " to the name, and making a new one with "Broken and incorrect " in front of the name, and then let the users choose which one they want. ;)

  • Waffle (unregistered)

    I don't get it Where's the WTF. What, no-one else does all they're business logic in SQL?

  • Anonymou5 (unregistered)

    Why would you put that in a config file? Wouldn't it be better to store it in the database? That way you could update it in a centralised manner if a field got added.

    But of course you'd need to base64-encode it just in case.

  • Brendan (unregistered)

    This looks like a quick hack which has snowballed into an Epic Frankenbeast and by the time the coders realized what had happened there was no budget or time to refactor. Either that or it just became Somebody Elses Problem.

  • nobis_likecaptcha (unregistered)

    This has to be the worst part:

    LEFT OUTER JOIN Notes Notes_CCList ON Notes_CCList.handle = Documents.CCListDBA LEFT OUTER join DTConfigurations ON DTConfigurations.ServerGUID = Documents.ServerGUID LEFT OUTER JOIN Globalization HistoryGeneric_Detail ON

    I f*ing hate inconsistency.

  • Dolor S. (unregistered) in reply to renewest
    renewest:
    My favorite part:
    CASE substring(REPLACE(REPLACE(REPLACE(REPLACE(REPLACE(REPLACE (REPLACE(REPLACE(REPLACE(REPLACE(REPLACE( Documents.Destination,' ',''),')',''),'(',''), '-',''),'/',''),'.',''),'*',''),',',''),';',''), '\',''),'-',''),1,1) WHEN '1' THEN substring(REPLACE(REPLACE(REPLACE(REPLACE(REPLACE( REPLACE(REPLACE(REPLACE( REPLACE(REPLACE( REPLACE(Documents.Destination,' ',''),')', ''),'(',''),'-',''),'/',''),'.',''),'*',''), ',',''),';',''),'\',''),'-',''), 2, len( REPLACE(REPLACE(REPLACE(REPLACE(REPLACE( REPLACE(REPLACE(REPLACE( REPLACE(REPLACE( REPLACE(Documents.Destination,' ',''),')', ''),'(',''),'-',''),'/',''),'.',''),'*','') ,',',''),';',''),'\',''),'-','')) ) ELSE REPLACE(REPLACE(REPLACE(REPLACE(REPLACE(REPLACE(REPLACE(REPLACE( REPLACE(REPLACE(REPLACE(Documents.Destination,' ',''),'-',''),')', ''),'(',''),'/',''),'.',''),'*',''),',',''),';',''),'\',''),'-','')

    I 'd like to think that this replaces all smilies into frowns into tears.

    It's like looking into a sea of Pikachu faces.

  • Olaf (unregistered)
    (note: line breaks and formatted added for clarity)
    LOL.
  • tri-stick (unregistered) in reply to Spearhavoc!
    Spearhavoc!:
    ObiWayneKenobi:
    I am always amazed that business managers will say "I MUST have real-time reports" but are unwilling to actually portion off the required budget to then set up even a basic OLAP data mart to do it, but have the audacity to whine like babies when the reports or other parts of a system take a huge amount of time to run because it has to query dozens of tables on a production system that is being used elsewhere.

    Gotta gleam the cube, man!

    At work? That's so sick, you pervert!

  • Shoki (unregistered) in reply to BC

    correction: it tried to undo all of creation

  • a bike-o (unregistered) in reply to ClaudeSuck.de
    ClaudeSuck.de:
    ObiWayneKenobi:
    ClaudeSuck.de:
    If you do you will have to take the responsibility when the business people notice that the results are different from what they were before. And if you tell them at that moment that YOU made this change I don't want to be in your shoes.

    Speaking from experience, it's more fun when the original report was outright wrong and performed incorrect calculations, and you're told to change the new one back to give bad results so it matches the old reports.

    So you had to go through this, too. :D The reason was that they had the habit of "tuning" the numbers in order to reflect the desired results. This was OK because many knew about the the problem. A correct report would have shown the real world, but who likes that? Big fun, indeed.

    I remember reading that WTF, too.
  • Satan (unregistered) in reply to BC

    Oh, so that's where I stored it! -Wonderd where it was.

  • (cs) in reply to JayC
    JayC:
    It's kinda a wtf, but I won't call it horrendous: a. certainly shouldn't be all on one line. Better to be rewritten in a way usable as a stored proc. at least the query plan would be saved. ...
    SQL 2000 and later saves query plans for ad-hoc queries. It doesn't always work as well as plan caching for stored procedures, but it is certainly not true that this plan will never be cached.
  • (cs) in reply to jasmine2501
    jasmine2501:
    boog:
    by:
    Views and functions can't be indexed...
    Not so. Several databases do support indexing functions/expressions, and some even support indexes on views.

    Indexing a computed column isn't so bad, but setting up the indexed view in SQL Server is so tricky on any substantial database that it's fairly accurate to say the indexed view is "not supported"

    But it's not necessary. All database servers that I am aware of expand views before optimization. This means two things: first, using a view allows the query optimizer to make exactly the same index choices as not using a view -- second, an index on a view can actually be used even if the original query doesn't reference the view that has been indexed. As for functions, they must be deterministic and must not modify data specifically so they can be cached. The function itself doesn't need to be indexed, the system will simply run the function exactly once for each set of parameter values. Any data access performed in the function will use indexes as necessary.

  • (cs) in reply to by
    by:
    The REPLACE functions are WTF, but lets not forget the SQL injection possibility here (check the last WHERE clause).
    Injection protection is pretty pointless here. Im someone wanted to inject SQL, they could simply change the config entry to whatever they wanted to run.
  • coyo (unregistered) in reply to amischiefr
    amischiefr:
    Besides the replace madness, what's the problem?

    Placing an SQL query in a config file? Maybe not the 'INDUSTRY STANDARD' (ohh beware the industry standard!), but not a wtf.

    The length of the query? Has nobody else had to write a complex query that included multiple tables?

    Maybe I'm not looking closely enough at the code.

    The config file is really a proxy to a database configuration.

    The real configuration must have so many permutations that 'configuring' it is really programming it.

    Damn, its ugly though. Does it work?

  • shanghai coder (unregistered)

    Aha, another masterpiece of US deep wizardry. If all your code is like that, it is no wonder that being afraid of things is part of your lifestyle. At first, it was indians you were afraid of, then black ppl, then japanese, and now it is everything.

    US programmers so useless ...

  • coyo (unregistered) in reply to shanghai coder
    shanghai coder:
    Aha, another masterpiece of US deep wizardry. If all your code is like that, it is no wonder that being afraid of things is part of your lifestyle. At first, it was indians you were afraid of, then black ppl, then japanese, and now it is everything.

    US programmers so useless ...

    Tibet! Boogah Boogah! We're all the same.

  • Kempeth (unregistered) in reply to BC
    BC:
    I don't get what this code is supposed to do. My best guess is that it tries to delete all of human history?
    It's an elaborate variation of:

    DELETE Joy FROM Life;

  • Design Pattern (unregistered) in reply to Jaime
    Jaime:
    by:
    The REPLACE functions are WTF, but lets not forget the SQL injection possibility here (check the last WHERE clause).
    Injection protection is pretty pointless here. Im someone wanted to inject SQL, they could simply change the config entry to whatever they wanted to run.
    That's not the point: All the REPLACE logic happening in SQL instead of the application layer means that it's highly likely that no escaping of input parameters is performed at application layer. Also prepared statements/parameter bindings obviously are not used.

    This and the line:

    AND History.TRDateTime > 'REPLACE_WHERE_CLAUSE_CRITERIA'

    means the database is an huge wide gate open for SQL-Injection for every single user who has read access to this application (and is allowed to run this particular report).

  • shanghai coder (unregistered) in reply to coyo
    coyo:
    shanghai coder:
    Aha, another masterpiece of US deep wizardry. If all your code is like that, it is no wonder that being afraid of things is part of your lifestyle. At first, it was indians you were afraid of, then black ppl, then japanese, and now it is everything.

    US programmers so useless ...

    Tibet! Boogah Boogah! We're all the same.

    What is Tibet? China has most population. You kill indians and eskimos. We have big firewall to not be afraid of US script kids. Only thing better in US is that your mothers are bitches and f*ckable.

  • by (unregistered) in reply to Jaime
    Jaime:
    by:
    The REPLACE functions are WTF, but lets not forget the SQL injection possibility here (check the last WHERE clause).
    Injection protection is pretty pointless here. Im someone wanted to inject SQL, they could simply change the config entry to whatever they wanted to run.

    Wow, I really hope you're joking... The whole point on "injection" is that you "inject" code into the interpreter... If you can change the config file, you've already powned the server.

  • (cs) in reply to Design Pattern
    Design Pattern:
    Jaime:
    by:
    The REPLACE functions are WTF, but lets not forget the SQL injection possibility here (check the last WHERE clause).
    Injection protection is pretty pointless here. Im someone wanted to inject SQL, they could simply change the config entry to whatever they wanted to run.
    That's not the point: All the REPLACE logic happening in SQL instead of the application layer means that it's highly likely that no escaping of input parameters is performed at application layer. Also prepared statements/parameter bindings obviously are not used.

    This and the line:

    AND History.TRDateTime > 'REPLACE_WHERE_CLAUSE_CRITERIA'

    means the database is an huge wide gate open for SQL-Injection for every single user who has read access to this application (and is allowed to run this particular report).

    You missed my point... Even if the application did everything right, an attacker could simply change the config to make it vulnerable to injection.

  • Sardonic Admirer (unregistered)

    That's funny. I thought I read this article yesterday.

  • American Maid (unregistered) in reply to shanghai coder
    shanghai coder:
    coyo:
    shanghai coder:
    Aha, another masterpiece of US deep wizardry. If all your code is like that, it is no wonder that being afraid of things is part of your lifestyle. At first, it was indians you were afraid of, then black ppl, then japanese, and now it is everything.

    US programmers so useless ...

    Tibet! Boogah Boogah! We're all the same.

    What is Tibet? China has most population. You kill indians and eskimos. We have big firewall to not be afraid of US script kids. Only thing better in US is that your mothers are bitches and f*ckable.

    Enjoy getting run over by tanks, if that incident hasn't been scrubbed from your cultural memory yet.

  • (cs) in reply to by
    by:
    Jaime:
    by:
    The REPLACE functions are WTF, but lets not forget the SQL injection possibility here (check the last WHERE clause).
    Injection protection is pretty pointless here. Im someone wanted to inject SQL, they could simply change the config entry to whatever they wanted to run.

    Wow, I really hope you're joking... The whole point on "injection" is that you "inject" code into the interpreter... If you can change the config file, you've already powned the server.

    Yes you have. What makes you think this is on a server?

  • by (unregistered) in reply to Jaime
    Jaime:
    by:
    Jaime:
    by:
    The REPLACE functions are WTF, but lets not forget the SQL injection possibility here (check the last WHERE clause).
    Injection protection is pretty pointless here. Im someone wanted to inject SQL, they could simply change the config entry to whatever they wanted to run.

    Wow, I really hope you're joking... The whole point on "injection" is that you "inject" code into the interpreter... If you can change the config file, you've already powned the server.

    Yes you have. What makes you think this is on a server?

    Oh, I get it... Ok folks, don't feed the troll! Move along, nothing to see here. There is no way someone is this dumb/misinformed by accident.

  • shanghai coder (unregistered) in reply to American Maid
    American Maid:
    shanghai coder:
    coyo:
    shanghai coder:
    Aha, another masterpiece of US deep wizardry. If all your code is like that, it is no wonder that being afraid of things is part of your lifestyle. At first, it was indians you were afraid of, then black ppl, then japanese, and now it is everything.

    US programmers so useless ...

    Tibet! Boogah Boogah! We're all the same.

    What is Tibet? China has most population. You kill indians and eskimos. We have big firewall to not be afraid of US script kids. Only thing better in US is that your mothers are bitches and f*ckable.

    Enjoy getting run over by tanks, if that incident hasn't been scrubbed from your cultural memory yet.

    Hahaha. That old chinese joke. You americans think that really happened? Hahaha. It is from a movie, and George Bush or some fucker has taken it for serious. I am glad we have firewall. Hahaha.

  • (cs) in reply to Design Pattern
    Design Pattern:
    That's not the point: All the REPLACE logic happening in SQL instead of the application layer means that it's highly likely that no escaping of input parameters is performed at application layer. Also prepared statements/parameter bindings obviously are not used.

    This and the line:

    AND History.TRDateTime > 'REPLACE_WHERE_CLAUSE_CRITERIA'

    means the database is an huge wide gate open for SQL-Injection for every single user who has read access to this application (and is allowed to run this particular report).

    To be fair, you said yourself that you're assuming that input parameters aren't being escaped. But even not escaped, we don't know that it is vulnerable to SQL injection from users. For all we know the user doesn't even specify REPLACE_WHERE_CLAUSE_CRITERIA explicitly; it could be computed based on input parameters. We just don't know.

    That said, not using prepared statements/parameter bindings for query inputs is just a lousy way to do it anyway.

  • (cs) in reply to by
    by:
    Jaime:
    by:
    Jaime:
    by:
    The REPLACE functions are WTF, but lets not forget the SQL injection possibility here (check the last WHERE clause).
    Injection protection is pretty pointless here. Im someone wanted to inject SQL, they could simply change the config entry to whatever they wanted to run.

    Wow, I really hope you're joking... The whole point on "injection" is that you "inject" code into the interpreter... If you can change the config file, you've already powned the server.

    Yes you have. What makes you think this is on a server?

    Oh, I get it... Ok folks, don't feed the troll! Move along, nothing to see here. There is no way someone is this dumb/misinformed by accident.

    If this article is about the config file of a web app, then you are correct. If this article is about the config file of a desktop app, then I'm right. The article gives no indication of what type of application this is, so why are you assuming it is a web app?

  • (cs) in reply to Jaime
    Jaime:
    You missed my point... Even if the application did everything right, an attacker could simply change the config to make it vulnerable to injection.
    That's assuming an attack has access to change the config and restart the application. This is far less likely, but could be a good argument to put the SQL in a view instead of a config file, since an attacker is also unlikely to have CREATE VIEW privileges in the database.
  • (cs) in reply to boog
    boog:
    Jaime:
    You missed my point... Even if the application did everything right, an attacker could simply change the config to make it vulnerable to injection.
    That's assuming an attack has access to change the config and restart the application. This is far less likely, but could be a good argument to put the SQL in a view instead of a config file, since an attacker is also unlikely to have CREATE VIEW privileges in the database.
    The phrase "restart the application" seems to imply that you think this is web app. Why? The article's wording is "app.config". That phrasing is usually used with desktop apps and services.
  • by (unregistered) in reply to Jaime
    Jaime:
    by:
    Jaime:
    by:
    Jaime:
    by:
    The REPLACE functions are WTF, but lets not forget the SQL injection possibility here (check the last WHERE clause).
    Injection protection is pretty pointless here. Im someone wanted to inject SQL, they could simply change the config entry to whatever they wanted to run.

    Wow, I really hope you're joking... The whole point on "injection" is that you "inject" code into the interpreter... If you can change the config file, you've already powned the server.

    Yes you have. What makes you think this is on a server?

    Oh, I get it... Ok folks, don't feed the troll! Move along, nothing to see here. There is no way someone is this dumb/misinformed by accident.

    If this article is about the config file of a web app, then you are correct. If this article is about the config file of a desktop app, then I'm right. The article gives no indication of what type of application this is, so why are you assuming it is a web app?

    You know what, you're absolutely right; I just assumed/hoped that the developer who created this monstrosity wouldn't be daft enough to give the user control over something like this, let alone the hell it would be to upgrade or make changes to all the distributed apps. Obviously I'm giving too much latitude to the orig. developer...

    My apologies.

  • Capt. Cavemerica (unregistered) in reply to shanghai coder
    shanghai coder:
    Only thing better is that your mothers are bitches and f*ckable.

    Isn't that what the Japanese said about China during WWII?

  • (cs) in reply to Jaime
    Jaime:
    boog:
    That's assuming an attack has access to change the config and restart the application.
    The phrase "restart the application" seems to imply that you think this is web app. Why? The article's wording is "app.config". That phrasing is usually used with desktop apps and services.
    Are you suggesting that desktop apps/services don't ever need to be restarted/refreshed to pick up changes to config files?

    I think my point still stands, regardless.

  • boog (unregistered)

    I'm pretty sure I would have strangled the person who wrote this before I read any farther.

  • (cs) in reply to boog
    boog:
    Jaime:
    boog:
    That's assuming an attack has access to change the config and restart the application.
    The phrase "restart the application" seems to imply that you think this is web app. Why? The article's wording is "app.config". That phrasing is usually used with desktop apps and services.
    Are you suggesting that desktop apps/services don't ever need to be restarted/refreshed to pick up changes to config files?

    I think my point still stands, regardless.

    But, the concept that an end user wouldn't have the right to restart a desktop application is pretty ridiculous. Therefore, any suggestion that the user might not have the rights to restart an application only makes sense for applications that are not desktop applications. Hence, your original question implies a web app or service.

  • Sock Puppet 1 (unregistered)

    That's funny, I thought I read this article yesterday.

  • Sock Puppet 2 (unregistered) in reply to Sock Puppet 1
    Sock Puppet 1:
    That's funny, I thought I read this article yesterday.
    That's funny, I thought I read this comment earlier.
  • Sock Puppet 1 (unregistered) in reply to Sock Puppet 2
    Sock Puppet 2:
    Sock Puppet 1:
    That's funny, I thought I read this article yesterday.
    That's funny, I thought I read this comment earlier.
    My point is that they haven't published an article today.
  • Sock Puppet 2 (unregistered) in reply to Sock Puppet 1
    Sock Puppet 1:
    Sock Puppet 2:
    Sock Puppet 1:
    That's funny, I thought I read this article yesterday.
    That's funny, I thought I read this comment earlier.
    My point is that they haven't published an article today.
    Then why do they call it the daily wtf?

Leave a comment on “All In The Config”

Log In or post as a guest

Replying to comment #:

Log Out

« Return to Article