• Bob (unregistered) in reply to Ozz
    Ozz:
    Cue 50 references to Bobby Tables...
    Bobby Tables

    Bobby Tables Bobby Tables Bobby Tables Bobby Tables Bobby Tables Bobby Tables Bobby Tables Bobby Tables Bobby Tables Bobby Tables Bobby Tables Bobby Tables Bobby Tables Bobby Tables Bobby Tables Bobby Tables Bobby Tables Bobby Tables Bobby Tables Bobby Tables Bobby Tables Bobby Tables Bobby Tables Bobby Tables Bobby Tables Bobby Tables Bobby Tables Bobby Tables Bobby Tables Bobby Tables Bobby Tables Bobby Tables Bobby Tables Bobby Tables Bobby Tables Bobby Tables Bobby Tables Bobby Tables Bobby Tables Bobby Tables Bobby Tables Bobby Tables Bobby Tables Bobby Tables Bobby Tables Bobby Tables Bobby Tables Bobby Tables Bobby Tables Bobby Tables Bobby Tables Bobby Tables Bobby Tables Bobby Tables Bobby Tables Bobby Tables Bobby Tables Bobby Tables Bobby Tables Bobby Tables Bobby Tables Bobby Tables Bobby Tables Bobby Tables Bobby Tables Bobby Tables Bobby Tables Bobby Tables Bobby Tables Bobby Tables Bobby Tables Bobby Tables Bobby Tables Bobby Tables Bobby Tables Bobby Tables Bobby Tables Bobby Tables Bobby Tables Bobby Tables Bobby Tables Bobby Tables Bobby Tables Bobby Tables Bobby Tables Bobby Tables Bobby Tables

  • Pingmaster (unregistered) in reply to Bob
    Bob:
    Ozz:
    Cue 50 references to Bobby Tables...
    Bobby Tables

    Bobby Tables Bobby Tables Bobby Tables Bobby Tables Bobby Tables Bobby Tables Bobby Tables Bobby Tables Bobby Tables Bobby Tables Bobby Tables Bobby Tables Bobby Tables Bobby Tables Bobby Tables Bobby Tables Bobby Tables Bobby Tables Bobby Tables Bobby Tables Bobby Tables Bobby Tables Bobby Tables Bobby Tables Bobby Tables Bobby Tables Bobby Tables Bobby Tables Bobby Tables Bobby Tables Bobby Tables Bobby Tables Bobby Tables Bobby Tables Bobby Tables Bobby Tables Bobby Tables Bobby Tables Bobby Tables Bobby Tables Bobby Tables Bobby Tables Bobby Tables Bobby Tables Bobby Tables Bobby Tables Bobby Tables Bobby Tables Bobby Tables Bobby Tables Bobby Tables Bobby Tables Bobby Tables Bobby Tables Bobby Tables Bobby Tables Bobby Tables Bobby Tables Bobby Tables Bobby Tables Bobby Tables Bobby Tables Bobby Tables Bobby Tables Bobby Tables Bobby Tables Bobby Tables Bobby Tables Bobby Tables Bobby Tables Bobby Tables Bobby Tables Bobby Tables Bobby Tables Bobby Tables Bobby Tables Bobby Tables Bobby Tables Bobby Tables Bobby Tables Bobby Tables Bobby Tables Bobby Tables Bobby Tables Bobby Tables Bobby Tables Bobby Tables

    great. now with that little stunt of yours, we're up to 94 references.

    good going

    jerk

  • Cheong (unregistered)

    For people who puzzled on why the "right approach" is commented, I think the hint is in the following line:

    //OdbcParameter paramForumOption = new OdbcParameter("@ForumOption", OdbcType.Int, 1);

    I think some ODBC provider don't understand "@" sign as name of parameter... they use "?" instead. (see the other 3 lines) My bet is some clueless coder didn't notice it, and time is pressing, so use "replace" approach as quick fix.

  • Your Name (unregistered) in reply to TopCod3r
    TopCod3r:
    I don't know. It looks like they replaced 12 lines of code with 4 lines, so in that sense, this refactoring produced more efficient code. I don't know who uses ODBC anymore though, it is all OLEDB nowadays.

    Is that code in Javascript though? If so, that is a horrible practice because someone could just modify your SQL. It is better to just build a parameter string and then do the replacement on the server side.

    Here is what I'm talking about:

    Dim strSQL As String = "select * from [~TABLENAME~] where ~COLUMN~ = ~VALUE~" strSQL = strSQL.Replace("~TABLENAME~", Request.QueryString("t")) strSQL = strSQL.Replace("~COLUMN~", Request.QueryString("c")) strSQL = strSQL.Replace("~VALUE~", Request.QueryString("v")) 'Now you can execute strSQL

    This is a simple example, but you get the picture. Most of our queries have many more parameters, so you have c1/v1, c2/v2, c3/v3, etc.

    The bottom line is you always want to keep your data layer on the SERVER and never on the CLIENT, I cannot stress this enough. Well most of the time not on the client, there are some exceptions that I can think of, but those are advanced scenarios.

    I really hope you are joking. If you aren't then I feel sorry for your stupidity.

    CAPICHA: acsi - damn Easterners with all their larger-then-255-character-character sets. One byte FTW

  • Grassfire (unregistered) in reply to Maurits
    Maurits:
    SecCodr:
    TopCod3r:
    ...

    I hope you are joking...

    Shark Tank has JIM THE BOSS. TDWTF has TopCod3r.

    I had noticed a certain similarity of style between some of the posters here and on the tank. . . .

  • Azeroth (unregistered)

    Alex, can you highlight topcod3r with a big, nice troll icon? That way he will be nicely fed and people won't have to question the seriousness of his answers.

  • Nick J (unregistered) in reply to TopCod3r

    This code itself it WTF-worthy!

  • (cs) in reply to mjk340
    mjk340:
    The only secure application is one that doesn't use the internet, or a computer. I would just mail a product catalog to all potential clients and ask them to pay with a money order.

    Notice: A serious vulnerability has been discovered in the reference implementation of the mail delivery protocol. It allows a remote attacker previously unknown to the system to cause a serious denial-of-service attack.

    Details: The attacker, who needs know only their target's address, crafts a custom packet containing a payload capable of rapid exothermic gas-producing reaction (whether physical, chemical or nuclear is immaterial). This payload is then set to activate by some means - this could be a time delay, a remote wireless signal, or upon opening of the packet, or possibly other means. Upon activation of the payload, considerable damage and destruction is caused to all materials within a certain radius of the packet. These could include computer hardware, data backups, network infrastructure and human resources.

    Resolution: There are many ways to counter this threat. Mail transfer agents and mail delivery agents can have scanners added, though the variety of payload materials may mean some will not be caught. Some of the tools to create the payload have had their sourcing monitored or even made illegal, making it harder for attackers to obtain them undetected.

    However, we recommend the simplest solution: A limit on the maximum packet size of about that of an average letter, with special security procedures for larger packets.

    We strongly advise updating your systems as soon as possible. If you cannot update, you may wish to reject all mail.

  • cthulhu (unregistered) in reply to TopCod3r
    TopCod3r:
    I don't know. It looks like they replaced 12 lines of code with 4 lines, so in that sense, this refactoring produced more efficient code. I don't know who uses ODBC anymore though, it is all OLEDB nowadays.

    Is that code in Javascript though? If so, that is a horrible practice because someone could just modify your SQL. It is better to just build a parameter string and then do the replacement on the server side.

    Here is what I'm talking about:

    Dim strSQL As String = "select * from [~TABLENAME~] where ~COLUMN~ = ~VALUE~" strSQL = strSQL.Replace("~TABLENAME~", Request.QueryString("t")) strSQL = strSQL.Replace("~COLUMN~", Request.QueryString("c")) strSQL = strSQL.Replace("~VALUE~", Request.QueryString("v")) 'Now you can execute strSQL

    This is a simple example, but you get the picture. Most of our queries have many more parameters, so you have c1/v1, c2/v2, c3/v3, etc.

    The bottom line is you always want to keep your data layer on the SERVER and never on the CLIENT, I cannot stress this enough. Well most of the time not on the client, there are some exceptions that I can think of, but those are advanced scenarios.

    WTF is this?? Nearly everything you says is 100% Wrong.

    First of all no the code is not "in javascript", it's SQL.

    Also commenting a few lines out is NOT "refactoring"

    Your suggestion to do replacement "on the server side" is impossible.

    your claim that "it is all OLEDB nowadays" is rubbish

    and wtf is a "data layer"?

    your parameter names suck and your database codes suck

    I always amuses me how n00bs think they can add anything of value to the discussion.

  • fictilious (unregistered) in reply to TopCod3r
    TopCod3r:
    I don't know. It looks like they replaced 12 lines of code with 4 lines, so in that sense, this refactoring produced more efficient code. I don't know who uses ODBC anymore though, it is all OLEDB nowadays.

    Is that code in Javascript though? If so, that is a horrible practice because someone could just modify your SQL. It is better to just build a parameter string and then do the replacement on the server side.

    Here is what I'm talking about:

    Dim strSQL As String = "select * from [~TABLENAME~] where ~COLUMN~ = ~VALUE~" strSQL = strSQL.Replace("~TABLENAME~", Request.QueryString("t")) strSQL = strSQL.Replace("~COLUMN~", Request.QueryString("c")) strSQL = strSQL.Replace("~VALUE~", Request.QueryString("v")) 'Now you can execute strSQL

    This is a simple example, but you get the picture. Most of our queries have many more parameters, so you have c1/v1, c2/v2, c3/v3, etc.

    The bottom line is you always want to keep your data layer on the SERVER and never on the CLIENT, I cannot stress this enough. Well most of the time not on the client, there are some exceptions that I can think of, but those are advanced scenarios.

    The only thing worse than a dumb coder is an ignorant coder who thinks they know how to code securely but clearly don't.

  • ... (unregistered) in reply to cthulhu
    cthulhu:
    TopCod3r:
    I don't know. It looks like they replaced 12 lines of code with 4 lines, so in that sense, this refactoring produced more efficient code. I don't know who uses ODBC anymore though, it is all OLEDB nowadays.

    Is that code in Javascript though? If so, that is a horrible practice because someone could just modify your SQL. It is better to just build a parameter string and then do the replacement on the server side.

    Here is what I'm talking about:

    Dim strSQL As String = "select * from [~TABLENAME~] where ~COLUMN~ = ~VALUE~" strSQL = strSQL.Replace("~TABLENAME~", Request.QueryString("t")) strSQL = strSQL.Replace("~COLUMN~", Request.QueryString("c")) strSQL = strSQL.Replace("~VALUE~", Request.QueryString("v")) 'Now you can execute strSQL

    This is a simple example, but you get the picture. Most of our queries have many more parameters, so you have c1/v1, c2/v2, c3/v3, etc.

    The bottom line is you always want to keep your data layer on the SERVER and never on the CLIENT, I cannot stress this enough. Well most of the time not on the client, there are some exceptions that I can think of, but those are advanced scenarios.

    WTF is this?? Nearly everything you says is 100% Wrong.

    First of all no the code is not "in javascript", it's SQL.

    Also commenting a few lines out is NOT "refactoring"

    Your suggestion to do replacement "on the server side" is impossible.

    your claim that "it is all OLEDB nowadays" is rubbish

    and wtf is a "data layer"?

    your parameter names suck and your database codes suck

    I always amuses me how n00bs think they can add anything of value to the discussion.

    Ant it always amuses me how someone can miss the fact that someone else is obviously joking.

  • cthulhu (unregistered) in reply to ...
    ...:
    cthulhu:
    TopCod3r:
    I don't know. It looks like they replaced 12 lines of code with 4 lines, so in that sense, this refactoring produced more efficient code. I don't know who uses ODBC anymore though, it is all OLEDB nowadays.

    Is that code in Javascript though? If so, that is a horrible practice because someone could just modify your SQL. It is better to just build a parameter string and then do the replacement on the server side.

    Here is what I'm talking about:

    Dim strSQL As String = "select * from [~TABLENAME~] where ~COLUMN~ = ~VALUE~" strSQL = strSQL.Replace("~TABLENAME~", Request.QueryString("t")) strSQL = strSQL.Replace("~COLUMN~", Request.QueryString("c")) strSQL = strSQL.Replace("~VALUE~", Request.QueryString("v")) 'Now you can execute strSQL

    This is a simple example, but you get the picture. Most of our queries have many more parameters, so you have c1/v1, c2/v2, c3/v3, etc.

    The bottom line is you always want to keep your data layer on the SERVER and never on the CLIENT, I cannot stress this enough. Well most of the time not on the client, there are some exceptions that I can think of, but those are advanced scenarios.

    WTF is this?? Nearly everything you says is 100% Wrong.

    First of all no the code is not "in javascript", it's SQL.

    Also commenting a few lines out is NOT "refactoring"

    Your suggestion to do replacement "on the server side" is impossible.

    your claim that "it is all OLEDB nowadays" is rubbish

    and wtf is a "data layer"?

    your parameter names suck and your database codes suck

    I always amuses me how n00bs think they can add anything of value to the discussion.

    Ant it always amuses me how someone can miss the fact that someone else is obviously joking.

    Please. I have been working on database access for over 2 years. I think I know what I am talking about somehow.

  • g (unregistered) in reply to cthulhu
    cthulhu:
    ...:
    cthulhu:
    TopCod3r:
    I don't know. It looks like they replaced 12 lines of code with 4 lines, so in that sense, this refactoring produced more efficient code. I don't know who uses ODBC anymore though, it is all OLEDB nowadays.

    Is that code in Javascript though? If so, that is a horrible practice because someone could just modify your SQL. It is better to just build a parameter string and then do the replacement on the server side.

    Here is what I'm talking about:

    Dim strSQL As String = "select * from [~TABLENAME~] where ~COLUMN~ = ~VALUE~" strSQL = strSQL.Replace("~TABLENAME~", Request.QueryString("t")) strSQL = strSQL.Replace("~COLUMN~", Request.QueryString("c")) strSQL = strSQL.Replace("~VALUE~", Request.QueryString("v")) 'Now you can execute strSQL

    This is a simple example, but you get the picture. Most of our queries have many more parameters, so you have c1/v1, c2/v2, c3/v3, etc.

    The bottom line is you always want to keep your data layer on the SERVER and never on the CLIENT, I cannot stress this enough. Well most of the time not on the client, there are some exceptions that I can think of, but those are advanced scenarios.

    WTF is this?? Nearly everything you says is 100% Wrong.

    First of all no the code is not "in javascript", it's SQL.

    Also commenting a few lines out is NOT "refactoring"

    Your suggestion to do replacement "on the server side" is impossible.

    your claim that "it is all OLEDB nowadays" is rubbish

    and wtf is a "data layer"?

    your parameter names suck and your database codes suck

    I always amuses me how n00bs think they can add anything of value to the discussion.

    Ant it always amuses me how someone can miss the fact that someone else is obviously joking.

    Please. I have been working on database access for over 2 years. I think I know what I am talking about somehow.

    Sheesh... you've been working on database access for over 2 years. I hope you're not on the critical path of a project because that's an eternity just for database access. I hope you get it working sometime soon. Maybe you're having some problems with security or something.

  • cthulhu (unregistered) in reply to g
    g:
    cthulhu:
    ...:
    cthulhu:
    TopCod3r:
    I don't know. It looks like they replaced 12 lines of code with 4 lines, so in that sense, this refactoring produced more efficient code. I don't know who uses ODBC anymore though, it is all OLEDB nowadays.

    Is that code in Javascript though? If so, that is a horrible practice because someone could just modify your SQL. It is better to just build a parameter string and then do the replacement on the server side.

    Here is what I'm talking about:

    Dim strSQL As String = "select * from [~TABLENAME~] where ~COLUMN~ = ~VALUE~" strSQL = strSQL.Replace("~TABLENAME~", Request.QueryString("t")) strSQL = strSQL.Replace("~COLUMN~", Request.QueryString("c")) strSQL = strSQL.Replace("~VALUE~", Request.QueryString("v")) 'Now you can execute strSQL

    This is a simple example, but you get the picture. Most of our queries have many more parameters, so you have c1/v1, c2/v2, c3/v3, etc.

    The bottom line is you always want to keep your data layer on the SERVER and never on the CLIENT, I cannot stress this enough. Well most of the time not on the client, there are some exceptions that I can think of, but those are advanced scenarios.

    WTF is this?? Nearly everything you says is 100% Wrong.

    First of all no the code is not "in javascript", it's SQL.

    Also commenting a few lines out is NOT "refactoring"

    Your suggestion to do replacement "on the server side" is impossible.

    your claim that "it is all OLEDB nowadays" is rubbish

    and wtf is a "data layer"?

    your parameter names suck and your database codes suck

    I always amuses me how n00bs think they can add anything of value to the discussion.

    Ant it always amuses me how someone can miss the fact that someone else is obviously joking.

    Please. I have been working on database access for over 2 years. I think I know what I am talking about somehow.

    Sheesh... you've been working on database access for over 2 years. I hope you're not on the critical path of a project because that's an eternity just for database access. I hope you get it working sometime soon. Maybe you're having some problems with security or something.

    -1 troll

  • Eric L (unregistered)

    I know why they did it. To prove the point of crossplatformism, they switched their previously working MS SQL database out for a clunky old DB2 running on a mainframe (since its more enterprisey) and then realized nobody on staff could get a stored proc to work on db2.

  • b0ttomfeeder (unregistered) in reply to cthulhu
    cthulhu:
    g:
    cthulhu:
    ...:
    cthulhu:
    TopCod3r:
    I don't know. It looks like they replaced 12 lines of code with 4 lines, so in that sense, this refactoring produced more efficient code. I don't know who uses ODBC anymore though, it is all OLEDB nowadays.

    Is that code in Javascript though? If so, that is a horrible practice because someone could just modify your SQL. It is better to just build a parameter string and then do the replacement on the server side.

    Here is what I'm talking about:

    Dim strSQL As String = "select * from [~TABLENAME~] where ~COLUMN~ = ~VALUE~" strSQL = strSQL.Replace("~TABLENAME~", Request.QueryString("t")) strSQL = strSQL.Replace("~COLUMN~", Request.QueryString("c")) strSQL = strSQL.Replace("~VALUE~", Request.QueryString("v")) 'Now you can execute strSQL

    This is a simple example, but you get the picture. Most of our queries have many more parameters, so you have c1/v1, c2/v2, c3/v3, etc.

    The bottom line is you always want to keep your data layer on the SERVER and never on the CLIENT, I cannot stress this enough. Well most of the time not on the client, there are some exceptions that I can think of, but those are advanced scenarios.

    WTF is this?? Nearly everything you says is 100% Wrong.

    First of all no the code is not "in javascript", it's SQL.

    Also commenting a few lines out is NOT "refactoring"

    Your suggestion to do replacement "on the server side" is impossible.

    your claim that "it is all OLEDB nowadays" is rubbish

    and wtf is a "data layer"?

    your parameter names suck and your database codes suck

    I always amuses me how n00bs think they can add anything of value to the discussion.

    Ant it always amuses me how someone can miss the fact that someone else is obviously joking.

    Please. I have been working on database access for over 2 years. I think I know what I am talking about somehow.

    Sheesh... you've been working on database access for over 2 years. I hope you're not on the critical path of a project because that's an eternity just for database access. I hope you get it working sometime soon. Maybe you're having some problems with security or something.

    -1 troll

    I don't get it. Is cthulhu trolling as well? Or is he just dense?

  • Garrett (unregistered)

    TRWTF is stored procedures.

  • some noob (unregistered)

    lol. i love the responses to TopCod3r. Every day there's a new person who falls for it.

  • anonymous (unregistered) in reply to Max
    Max:
    Note to all programmers:

    What a company focuses on in its interview are three things:

    1. Can you do the job?
    2. Will you fit with the team?
    3. Will you fix our stupid problems?

    So if they focus on good design to the exclusion of all else, you can be very sure they are answering #3, not #1. Their code will suck.

    Oh, don't forget about the reassuring "we only hire senior developers" after talking about their design.

    That's where I'm at now... oh well, the pay is good. :) As long as I can keep my sanity intact until everything is fixed... and hopefully I'll be in on some interviews from now on to try and weed people out.

  • CopToad3r (unregistered) in reply to File Not Found
    File Not Found:
    SecCodr:
    TopCod3r:
    blah, blah

    I hope you are joking about using the above code to handle your SQL queries. That is still very susceptible to SQL injection.

    And you are very susceptible to TopCod3rs comments.

    Did you consider that TopCod3r and SecCodr might be the same person and that TopCod3r, knowing he can't get the long-time reader to fall for his troll bait, instead pretends to be a nube responding to TopCod3r troll bait, in order that you laugh out the nube? Thus falling prey to the trolling yourself? I await your answer with baited breath...

  • (cs) in reply to CopToad3r
    CopToad3r:
    I await your answer with baited breath...
    Yes, your breath does smell like fishbait. Next time, try bating it instead.
  • Fox (unregistered)

    If you fall for such trolling after someone else has already fallen for it then you really do deserve your plight - simply for not bothering to read the existing replies

  • (cs)

    Who is really the troll -- the troll, or the troll that trolls him?

    (... now I have a headache.)

  • (cs)

    TopCod3r's know-it-all-but-all-wrong character is artful enough and funny in its own way. I'm sure it's not easy to craft just the right amount of ignorance.

    But I don't like it when I get halfway through a someone making a point and I'm taking it seriously but then I realize it's all sarcastic. Sometimes I don't even find out until later in the thread, like today. Plus, I'm not sure I've unlearned all the stuff I read in his posts before I realized they were his. So in the end they really are disenlightening. It was a good hack but it's getting a little hackneyed.

    I almost never look at posters' names and if I did it would never be before reading the comment. Maybe I'll have to now, which I will regard as an overhead courtesy of TopCod3r.

    But I'm not saying he should stop or be banned. Humor is a tricky subject and if nobody ever tried to be funny nobody would ever be funny. But I can only take Jerry Lewis or Stephen Colbert for so long. There are better kinds of humor and I'd like to see TopCod3r try them.

    Level up, TopCod3r!

  • nigel (unregistered)

    fk me, thanks guys i can't believe i just read all of those comments and now it's 3am so just hope i don't dream of trolls wtf rules!

  • (cs) in reply to Pingmaster
    Pingmaster:
    great. now with that little stunt of yours, we're up to 94 references.
    Actually, thanks to your pointless repetition of the entire post, we're up to 184.
    Pingmaster:
    good going

    jerk

    You did exactly the same thing that he did, so what does that make you? An unoriginal jerk, I'm thinking.

  • (cs) in reply to Azeroth
    Azeroth:
    Alex, can you highlight topcod3r with a big, nice troll icon? That way he will be nicely fed and people won't have to question the seriousness of his answers.
    Pffft, what else are you gonna ask for next? "Joke" and "sarcasm" tags for the humour-impaired? TopCod3r's posts are blatantly tongue-in-cheek and dead funny, there's no need to spoil the joke.

    Anyone who can't see him coming from a mile off is TRWTF.

  • l33tc0d3r (unregistered)

    What? TopCod3r is a troll?! I just implemented his suggestions and they work grate! It's at least 30% faster on my MS Access + ASP web application.

  • VS (unregistered)

    I'm guessing the correct (second, of course, why am I pointing this out?) snippet was commented out because it didn't work.

    Why?

    The first snippet uses ForumsOption, but the second one used ForumOption. I'm guessing that instead of fixing the problem the right way they redesigned it.

  • BottomCod3r (unregistered) in reply to TopCod3r
    Dim strSQL As String = "select * from [~TABLENAME~] where ~COLUMN~ = ~VALUE~" strSQL = strSQL.Replace("~TABLENAME~", Request.QueryString("t")) strSQL = strSQL.Replace("~COLUMN~", Request.QueryString("c")) strSQL = strSQL.Replace("~VALUE~", Request.QueryString("v")) 'Now you can execute strSQL

    Ideally, if you were using a language that supports macros, you could write something like this:

    (sql select * from 'table where 'column = "value")

    In this example, the ' tells the macro to parameterize the variable "table" instead of accessing the table called "table". Anything following an = sign is treated as a value to be parameterized.

    The one-liner above expands to something that is equivalent to that half-page of commented out code shown in the article.

  • David (unregistered) in reply to b0ttomfeeder
    b0ttomfeeder:
    I don't get it. Is cthulhu trolling as well? Or is he just dense?

    He's been living under the sea for "Countless Eons". He's a little out of touch.

  • TekniCal (unregistered) in reply to Code Dependent
    Code Dependent:
    CopToad3r:
    I await your answer with baited breath...
    Yes, your breath does smell like fishbait. Next time, try bating it instead.

    'BATING IT???!!!??? That's DISGUSTING! If you're gonna 'bate your breath, do it in private, please. We don't wanna know about it.

  • anon (unregistered) in reply to TopCod3r

    You're just trolling, right???

  • Peter W. (unregistered)

    As sad and maybe unbelievable it sounds, I have been told to do things similar to this more than one time. Thank God, not that safety relevant, mostly path not found and segfault issues.

    I have to mention that we are an outsourced software factory for an international corporate group. And that we are paid by man hour, because the client believes this was cheaper.

    Application has several more or less severe bugs from time immemorial.

    I to my boss: "I'll fix this. Will take about half an hour. Testing comprised" Boss: "That issue is known to the client, but they are too avaricious to have it fixed. DO NOT MEND IT. THIS IS AN ORDER."

    So when there is little to do I write the code to fix it, test it and comment it out afterwards.

    When the client can't neglect their users' complaints any longer, they tell us to fix it, usually ASAP. Then we change comments, goof off two days and let the client pay for that time. (Okay, this is a bit exaggerated, but I think they'd deserve it.)

    (Sorry if digging out an old thread is against forum custom, but I thought it might fit here.)

  • some (unregistered)

    I'm alsways opting for the fine "EXECUTE IMMEDIATE" in Oracle to execute concatinated and replaced Strings as queries.

    Just to be sure everything gets executed fast! ;-)

  • scowler (unregistered) in reply to cthulhu
    cthulhu:
    TopCod3r:
    I don't know. It looks like they replaced 12 lines of code with 4 lines, so in that sense, this refactoring produced more efficient code. I don't know who uses ODBC anymore though, it is all OLEDB nowadays.

    Is that code in Javascript though? If so, that is a horrible practice because someone could just modify your SQL. It is better to just build a parameter string and then do the replacement on the server side.

    Here is what I'm talking about:

    Dim strSQL As String = "select * from [~TABLENAME~] where ~COLUMN~ = ~VALUE~" strSQL = strSQL.Replace("~TABLENAME~", Request.QueryString("t")) strSQL = strSQL.Replace("~COLUMN~", Request.QueryString("c")) strSQL = strSQL.Replace("~VALUE~", Request.QueryString("v")) 'Now you can execute strSQL

    This is a simple example, but you get the picture. Most of our queries have many more parameters, so you have c1/v1, c2/v2, c3/v3, etc.

    The bottom line is you always want to keep your data layer on the SERVER and never on the CLIENT, I cannot stress this enough. Well most of the time not on the client, there are some exceptions that I can think of, but those are advanced scenarios.

    WTF is this?? Nearly everything you says is 100% Wrong.

    First of all no the code is not "in javascript", it's SQL.

    Also commenting a few lines out is NOT "refactoring"

    Your suggestion to do replacement "on the server side" is impossible.

    your claim that "it is all OLEDB nowadays" is rubbish

    and wtf is a "data layer"?

    your parameter names suck and your database codes suck

    I always amuses me how n00bs think they can add anything of value to the discussion.

    Hello Bert.

Leave a comment on “Security by Posterity”

Log In or post as a guest

Replying to comment #:

Log Out

« Return to Article