• (cs) in reply to lucio
    lucio:

    John Smallberries:
    As someone mentioned above, doing that hardcodes the sort into the SQL. If the desired order changes, or you want more than 2 "special" items, you need to recode the proc.

    I don't see a problem with that. You don't need to compile a proc for it to work, so that kind of edit would never drop everybody's session or anything.

    Also, this probably wouldn't happen too much; and even if it would, the counterpart solution seems slower to me. I think that opening Enterprise Manager and editing a procedure would be quicker than opening and editing the table itself.


    Well, when we make code changes (even little ones) we go through this little process known as "testing". This requires resources and time.

    We also use something known as "source code control". Nobody goes into Enterprise Manager and changes code directly against the DB.

    As far as changing the data, we provide users with an interface to do that. Write it once, let the users manage it from there.
  • (cs) in reply to foxyshadis
    foxyshadis:
    Rick:
    I know of a place that just lives with the bad names. The names are usually 3 letters, and it is a 3rd party application, but views are so easy.

    I've come to the opinion that all those third-party and custom apps with incomprehensible db/table names are doing it as a form of encryption. If you can't figure out how the hell it does it, you can't edit it or extend it, so you NEED them to make any changes for you, assuming they'll even bother with a small customer with custom requirements.


    Hmm, "security through obscurity"?  It didn't work for the ancient egyptians when they built tombs you know.
  • El Duderino (unregistered) in reply to lucio
    lucio:

    Also, this probably wouldn't happen too much; and even if it would, the counterpart solution seems slower to me. I think that opening Enterprise Manager and editing a procedure would be quicker than opening and editing the table itself.

    It would be much longer if your team is adhering to strict testing & version control procedures (which they should be!).  Making changes to the schema (which a proc is part of) SHOULD be followed with a code review, checking the change into your version control system, user testing and production migration. 99% of all WTFs can be cured with these steps. 

    By putting the order in the table it's free to be changed by anyone with the rights to update that field -- in other words, the task can be delegated to the users (provided an interface) where it belongs instead of having to take up the programmers' valuable time!

    John Smallberries:

    For reasonable dropdown/selection lists (less than about 100 items) I can't believe that the ORDER BY clause imposes significant overhead for the DB server, especially if the table is indexed properly. Offloading this processing to the middle/presentation tier (which, even if using a cuspy algorithm, is not going to be optimized like a DBMS) seems like an unecessary complexity.

    I actually agree but have worked with people who would still have argued against it, prefering to stick with the safety of their "method" (wherein they can open up a book and point to the line some college professor wrote saying that it's wrong) than being creative and doing the best thing.

  • Noob (unregistered) in reply to lucio
    lucio:

    John Smallberries:
    As someone mentioned above, doing that hardcodes the sort into the SQL. If the desired order changes, or you want more than 2 "special" items, you need to recode the proc.

    I don't see a problem with that. You don't need to compile a proc for it to work, so that kind of edit would never drop everybody's session or anything.

    Also, this probably wouldn't happen too much; and even if it would, the counterpart solution seems slower to me. I think that opening Enterprise Manager and editing a procedure would be quicker than opening and editing the table itself.



    You're assuming that the developer would be making those changes and not an end user....much better to write a admin interface that would update the sort order column, I would think.

    But that's just my opinon...
  • (cs) in reply to Mach005
    Anonymous:

    I knew what A_IX stood for before I read your piece :)

    BTW A_TX stands for transaction

    In the code presented, in its anonymized form, perhaps...

    Wizard:

    The scary thing is that I know exactly why the Space(135) is in there.

    Combo boxes in VB are not like dropdowns in HTML, where you can say something like...

    Ten

    And then use your language of choice to get the value and the text as separate items. No, VB 6 combo boxes only have the List property, and the Index property. List is the text, and Index is the item's index, relative to its position in the list. (0 for the first item, 1 for the second item, etc.)

    So if you want some extra value associated with your dropdown item (like "10"), you can either do the smart thing, which is use the ItemData catch-all property and stuff it in there, or you can do the WTF thing, which is to pad your unique value out to the right with a whole bunch of spaces. Make your dropdown narrow enough, and the user won't see the unique value. Then, when the user saves his selection, parse out the right-padded number with Mid or something similar.

    So, obviously, someone wanted to get the A_ID value associated with the selected item, and either they didn't know about ItemData, or this is code ported from an earlier version of VB that didn't have that property. Either way, they should have RTFM.

    I've always used the ItemData property in VB6 as I thought that's just How It's Done.  However, in a situation where the ItemData property isn't available, what would be the proper way to achieve the same result?

     

    As for the WTF, I guess I stand somewhat corrected.  I've never been in a situation where I needed to have a highly specialized sort order on a list of values, and that, in combination with the fact that the specialized sort order in this instance was so close to just sorting alphabetically and the fact that no user interface was designed by which the users could change that sort order (heck, the users can't even change add, edit, or delete records in this table without getting a developer to change the tables directly), led me to believe that this was a solid WTF.

     

  • (cs) in reply to UncleMidriff

    users can't even change add, edit, or delete records in this table without getting a developer to change the tables directly
    [:'(]

    As further facts are uncovered, I can see that this system as a whole is a WTF.  Not that I haven't seen dozens of equally bad applications.  Some of them from industry leaders . . . Lawson comes to mind (oops! did I say that out loud?)

  • (cs) in reply to Alex Papadimoulis
    Alex Papadimoulis:
    Drak:

    We prepend ours with fld, standing for field. Not exactly sure why, but they were doing this since before I started, and well, at least you know when people are talking about a field (fld) or table(tbl). They say stuff like 'From tuhblUser you must get fuhldName' and you know what they are talking about.

    Holy WTF naming convention. The irony of that being that FIELDS DO NOT EXIST IN A DATABASE (there are, however, columns).

    I suppose that's soo much clearer than saing, "From the Users table you get the Name colum."

    I don't know whether you are trying to be trollish, or over-precise, or what, but from where I'm from, Rows and Columns are spreadsheet terms (but still widely used when talking about databases), and records and fields are database terms.

    Please ignore this if my sarcasm meter was simply mis-functioning...

  • (cs) in reply to UncleMidriff
    UncleMidriff:
    I've always used the ItemData property in VB6 as I thought that's just How It's Done.  However, in a situation where the ItemData property isn't available, what would be the proper way to achieve the same result?

    In olden times (VB6) I used a parallel array. These days (C#.Net) I would probably derive a new class from System.Windows.Forms.ComboBox and add my new properties.
  • (cs) in reply to BradC

    BradC:
    I don't know whether you are trying to be trollish, or over-precise, or what, but from where I'm from, Rows and Columns are spreadsheet terms (but still widely used when talking about databases), and records and fields are database terms.

    You must be from the 60's, where they actually did have record- and field- based data models (reel-to-reel tapes). [;)] With the introduction of the relational model and relational databases, the proper terminology (as definied by Codd, Date, et al) is "tables", "rows", and "columns." (relational theory uses different terms, based on set-theory: relation/revlar, tuples, and attributes). Calling a "row" a "record" is as much a gaffe as mixing up "classes" and "objects."

    But no, this is not meant to troll. A fundamental understanding of relational databases is something many programmers lack. What gets dangerous (and quite WTFy) is when said programmers think they know what their doing and then do it. They often find themselves creating (within a RDBMS) the exact problems that the reltional model set out to solve.

  • (cs) in reply to BradC
    BradC:
    I don't know whether you are trying to be trollish, or over-precise, or what, but from where I'm from, Rows and Columns are spreadsheet terms (but still widely used when talking about databases), and records and fields are database terms.

    Well, in data modeling terminology, tables are "entities", fields/columns are "attributes", and records/rows are "instances".
    :)
  • refried (unregistered) in reply to Maurits
    Maurits:

    SELECT
        *
    FROM
        Table
    ORDER BY
        CASE
           WHEN Field = 'Most Common Value' THEN 1
           WHEN Field = 'Second Most Common Value' THEN 2
           ELSE 3 -- everybody else goes after those two
        END,
        Field -- alphabetically


    :O

    Wow, that's so cool.  I didn't know you could do that.  Thanks for the cool trick.
  • (cs) in reply to Alex Papadimoulis
    Alex Papadimoulis:

    BradC:
    I don't know whether you are trying to be trollish, or over-precise, or what, but from where I'm from, Rows and Columns are spreadsheet terms (but still widely used when talking about databases), and records and fields are database terms.

    You must be from the 60's, where they actually did have record- and field- based data models (reel-to-reel tapes). [;)] With the introduction of the relational model and relational databases, the proper terminology (as definied by Codd, Date, et al) is "tables", "rows", and "columns." (relational theory uses different terms, based on set-theory: relation/revlar, tuples, and attributes). Calling a "row" a "record" is as much a gaffe as mixing up "classes" and "objects."

    But no, this is not meant to troll. A fundamental understanding of relational databases is something many programmers lack. What gets dangerous (and quite WTFy) is when said programmers think they know what their doing and then do it. They often find themselves creating (within a RDBMS) the exact problems that the reltional model set out to solve.

     

    I have to wonder how much it really matters if I say "rows" or "records."  If anyone were to hear me say "records" and respond, "OMG WTF are you talking about!!11!one!  I have no idea what you mean!  Your terminology is so foreign to me!" I'd probably punch them in the nose.

    While I understand that a common terminology is a valuable thing, as long as we're talking about the same thing (and we know it) I couldn't care less if you call rows "flimjamps" and columns "sloogyhoos."

  • (cs) in reply to Alex Papadimoulis
    Alex Papadimoulis:

    BradC:
    I don't know whether you are trying to be trollish, or over-precise, or what, but from where I'm from, Rows and Columns are spreadsheet terms (but still widely used when talking about databases), and records and fields are database terms.

    You must be from the 60's, where they actually did have record- and field- based data models (reel-to-reel tapes). [;)] With the introduction of the relational model and relational databases, the proper terminology (as definied by Codd, Date, et al) is "tables", "rows", and "columns." (relational theory uses different terms, based on set-theory: relation/revlar, tuples, and attributes). Calling a "row" a "record" is as much a gaffe as mixing up "classes" and "objects."

    Great Googly Moogly

    No, I'm only 33, learned MS Access about 10 years ago (all together now: "ah, that explains alot") and SQL server about 5 years ago.

    Guess I've always assumed that "row and column" were simply informal terms for "record and field". So in a relational database, we don't use the term "record" because that would imply one complete "instance" of data (like a flat-file database), where one "instance" of data really consists of rows of data across many related tables? Is that the reason for the terminology change? Or is there another substantive difference between the terms?

  • (cs) in reply to BradC
    BradC:
    Alex Papadimoulis:

    BradC:
    I don't know whether you are trying to be trollish, or over-precise, or what, but from where I'm from, Rows and Columns are spreadsheet terms (but still widely used when talking about databases), and records and fields are database terms.

    You must be from the 60's, where they actually did have record- and field- based data models (reel-to-reel tapes). [;)] With the introduction of the relational model and relational databases, the proper terminology (as definied by Codd, Date, et al) is "tables", "rows", and "columns." (relational theory uses different terms, based on set-theory: relation/revlar, tuples, and attributes). Calling a "row" a "record" is as much a gaffe as mixing up "classes" and "objects."

    Great Googly Moogly

    No, I'm only 33, learned MS Access about 10 years ago (all together now: "ah, that explains alot") and SQL server about 5 years ago.

    Guess I've always assumed that "row and column" were simply informal terms for "record and field". So in a relational database, we don't use the term "record" because that would imply one complete "instance" of data (like a flat-file database), where one "instance" of data really consists of rows of data across many related tables? Is that the reason for the terminology change? Or is there another substantive difference between the terms?



    A "record" may or may not comprise multiple rows across multiple tables. And the term "relational" has nothing to do with "relationships" between data (and, frankly, is a misnomer -- the term should have been "functional", which would have implied that other database types didn't work, which would have come as quite a shock to the IMS customer base), it has to do with orthogonal access path axes in n-space -- one set of coordinates will uniquely address one datum (a Cartesian function, which is by definition also a Cartesian relation; the sicking point is that while all functions are relations, not all relations are functions, and it's easy to desribe a "relational" system that does not obey the Twelve Laws). The ability to create efficient relationships between data tables is implied by the coordinate system.
  • (cs) in reply to Stan Rogers

    Stan Rogers:
    A "record" may or may not comprise multiple rows across multiple tables. And the term "relational" has nothing to do with "relationships" between data (and, frankly, is a misnomer -- the term should have been "functional", which would have implied that other database types didn't work, which would have come as quite a shock to the IMS customer base), it has to do with orthogonal access path axes in n-space -- one set of coordinates will uniquely address one datum (a Cartesian function, which is by definition also a Cartesian relation; the sicking point is that while all functions are relations, not all relations are functions, and it's easy to desribe a "relational" system that does not obey the Twelve Laws). The ability to create efficient relationships between data tables is implied by the coordinate system.

    [:|]

    [^o)]

    [*-)]

    [B][B]

    [:D]

  • (cs) in reply to BradC
    BradC:
    No, I'm only 33, learned MS Access about 10 years ago (all together now: "ah, that explains alot") and SQL server about 5 years ago.

    Don't feel bad; I was the same way. I think I may have the honor of doing one of the most horrific things possible with a relational database in one project I did ages ago (having, of course, no experience in anything); I may post that one of these days (well, it was a "hobby" project, but I make an exception for me).

    This taught me three valuable lessons: (1) I don't know everything, (2) things that I don't know I should research extensively before trying, and (3) Relational Databases are nothing like procedural programming.

    BradC:
     Guess I've always assumed that "row and column" were simply informal terms for "record and field". So in a relational database, we don't use the term "record" because that would imply one complete "instance" of data (like a flat-file database), where one "instance" of data really consists of rows of data across many related tables? Is that the reason for the terminology change? Or is there another substantive difference between the terms?

    The short answer: kinda. Few points, keep in mind a comparison to non-relational databases  ...

    • Records are definied within the application (think COBOL or C-structs reading from binary files). Rows are definied in the database.
    • Records do not have consistant structure. In file systems, flags within a file record determine what data follow All Rows within a table are the same.
    • Records are ordered. Rows have no order.
    • An empty file (where you store records) contains nothing: zero bytes on disk. An empty table still has columns, permissions,  constraints, etc.
    • Most importantly, records contain other records (or a pointer to another record in another file). Rows cannot contain other rows and *should not* contain pointers to other rows (many programmers make this mistake by putting pointers in their rows known as GUID or IDENTITY)
    • Fields are ordered, columns are not
    • Fields cannot be "null" (what combination of bytes would you use to represent an integer null?); they can only contain a "dummy value" known by the application (999999999).
    • Fields can contain other records. Columns are always scalar (many programmers also make the mistake of the "CSV" column)

    There's a lot more I'm sure, but the idea is that the relational model is completely different than non-relational models.

  • (cs) in reply to BradC

    Those are supposed to be beers, btw...

    A lot of the emoticons don't work properly.... WTF? [;)]

  • (cs) in reply to Noob

    Anonymous:

    You're assuming that the developer would be making those changes and not an end user....much better to write a admin interface that would update the sort order column, I would think.

    But that's just my opinon...

    I did assume that. My bad [:P].

  • (cs) in reply to Drak
    Drak:

    I'm just wondering, what's with calling all your columns A_ ?

    We prepend ours with fld, standing for field. Not exactly sure why, but they were doing this since before I started, and well, at least you know when people are talking about a field (fld) or table(tbl). They say stuff like 'From tuhblUser you must get fuhldName' and you know what they are talking about. But A_ ??

    What'sit stand for?

    Drak

    "Asshat", of course.

  • (cs) in reply to BradC
    BradC:

    Those are supposed to be beers, btw...

    A lot of the emoticons don't work properly.... WTF? [;)]



    ... and the "sicking point" [sic] should have been a "sticking point". Although, to a theoretical mathematician, there may have been some sicking going on as well [;)]
  • Raw (unregistered) in reply to Stan Rogers

    Well, there may be perfectly good reasons for this (appart from such naming and so on).

    Someone has mentioned putting the common selections first, it may be that the system once worked that way, but was later changed to simple alphabetical sorting.

    Internationalization is another good cause. The VB6 combo does not sort international characters correctly, for instance it sorts the Swedish characters å, ä and ö as if they were a and o, which is completely wrong. Even the database does not sort correctly in an international environment. It understands å, ä and ö correctly, but it, for some screwed up reason, decides to sort v and w as if they were the same character.

    It probably could be better done, but it may very well be a practical solution to a very real problem.

  • (cs) in reply to Alex Papadimoulis
    Alex Papadimoulis:

    "tlkp"??? Please tell me that isn't a prefix short for "table lookup". Because that would be pretty silly if it was. Especially considering that there is only one thing you can select from in a database: tables (views are virtual tables). That, and the word "lookup" has nothing to do with a data model (discrete domain is what people usually mean when they use that word). Even so, it'd be pretty silly to use a tables name to say it models a DD (it's also against ISO-17779 standards).

    But I'm sure you knew this ... and you were just joking around ;-).



    I had Joe Celko flog me in private correspondence on the topic of prefixes to database objects, and I'm still non-plussed by the arguments against it.  The arguments seem to corresponde nicely to the arguments against hungarian notation over in C++.
    For a data model of size, adding a sprinkling of semantics to the names of objects helps to organize, particlarly when the model when it is browsed in a console; conceptually related items clump together.  This point is diminished when using graphical data modeling tools, I admit.  That great sin is being committed when I put extra information in the names of things, I have yet to see a convincing argument.
    As for the ISO standard...I would have been interested in doing that research, just not $1,000 interested.  Maybe I'll start a thread over on http://lambda-the-ultimate.org about it.


  • (cs) in reply to Alex Papadimoulis
    "Great Googly Moogly".  Well, I ahven't heard that in a while!  Frank Zappa, RIP.
     
    I think Joe Celko admonished a newsgroup poster for calling something a column in SQL; he says SQL has fields, not columns.  But sometimes Celko confuses me, and he's sure rude in the newsgroups.
     
    David
  • (cs) in reply to Alex Papadimoulis

    Alex, were those bullet points supposed to apply to relational or non-relational databases?  I can't quite tell from the phrase "keep in mind a comparison to non-relational databases"...

  • (cs) in reply to DWalker59

    DWalker59:
    Alex, were those bullet points supposed to apply to relational or non-relational databases?  I can't quite tell from the phrase "keep in mind a comparison to non-relational databases"...

    Those were meant to illustrate *why* there is such a big difference between those words. "Fields", "Records", etc. come from the world of non-relational databases (from CODASYL to COBOL sequential files) because they accurately describe how those systems represent data. In a relational database, we don't use files with records to store data - we use tables with rows ...

  • (cs) in reply to Alex Papadimoulis
    Alex Papadimoulis:

    DWalker59:
    Alex, were those bullet points supposed to apply to relational or non-relational databases?  I can't quite tell from the phrase "keep in mind a comparison to non-relational databases"...

    Those were meant to illustrate *why* there is such a big difference between those words. "Fields", "Records", etc. come from the world of non-relational databases (from CODASYL to COBOL sequential files) because they accurately describe how those systems represent data. In a relational database, we don't use files with records to store data - we use tables with rows ...

    Of coures, ironically, in the pure english definition sense, the words "Row" and "Column" bring to mind a visible position somewhere (i.e., on a screen or on a spreadsheet) implying a location or an ordering, while the words "Record" and "Field" do not have those same connotations since they are much more abstract concepts or ideas. 

     

  • (cs) in reply to Jeff S

    There is a physical position (row, column) in memory (or in the store), which is what makes a relational database an efficient database. Tables are tightly defined; every column has a defined "width" and all rows contain the same number of column entries. If you know the position of any one datum, it's simply a matter of pointer math (how far over, how far down) to get from one place to another. (That's what I meant by all of that there "orthoganal data access path axes" stuff.) If you are looking for a particular value in the table, you just move to the first row, move over to the column of interest, then jump down a row width at a time until you find what you're looking for -- no need to parse, say, a comma-delimited line of text. So there is a physical order to the data, but it may not be the same as the logical order -- you can't necessarily predict the content of one row simply by knowing the content of the previous and following rows.

  • (cs) in reply to Stan Rogers

    OK but say you have a table like this
    int
    char(20)

    so each record is 21 bytes long

    the binary data will be
    [ 1 ][ 20 ];[ 1 ][ 20 ];[ 1 ][ 20 ];...

    why is each [ 1 ] [ 20 ] called a row?  It could just as well be called a column.

    I'm also guilty of an assumption writing it left-to-right - Arabic programmers might write it right-to-left, Japanese programmers top-down, ex-busboys bottom-up, etc.

    record and field are culture-agnostic terms.

  • (cs) in reply to Maurits
    Maurits:
    why is each [ 1 ] [ 20 ] called a row?  It could just as well be called a column.

    Convention, if you want to get all linguistic about it. The point is that to find any string value (char[20]), you go to the beginning of the table store, move one byte (or word, depending on how the storage structure is described) to skip over the int "column", then jump through the store using an offset equal to the "width" of a "row" (the sum of all of the data widths of the "columns"). The "rows" and "columns" are just aids to visualising the storage structure; a mathematical model of the way values are mapped in memory.

    And no, "record" and "field" are not culture-agnostic. Where I come from, a "record" is a textured vinyl disc used to mechanically reproduce musical performances, and a "field" is a good place to grow hay or play ball [:)] As for their use in database terminology, a "record" is a complete entry describing an entity, and a "field" describes all of the data falling under a particular label. If the entity you are describing can be completely contained in itself (without refering to any other described entity), and all of the labelled values associated with that entity are singular values, it may be possible and correct to make a one-to-one correspondence between a "record" and a "row".

    Let's say, though, that you are describing a set of contacts. It would be extraordinarily silly to store the contacts' office location in each contact row, particularly if several of those contacts work in the same location. As soon as you decide that updating all identical information in one place is a good idea, you've taken that "record" and split it into two tables. One holds a single unique row that holds the office info for everyone who works for the company, the other holds a row for each individual. Is that now two records? Not if the office has three fax machines -- if you follow the Twelve Laws, you can't store more than one value in any "cell" in the table, so you have to break the fax numbers of into yet another table. And so on, and so on.
  • Z (unregistered) in reply to Raw
    Anonymous:
    Even the database does not sort correctly in an international environment. It understands å, ä and ö correctly, but it, for some screwed up reason, decides to sort v and w as if they were the same character.


    The Swedish standard for alphabetical sorting is to treat v and w as the same letter, so if the sorting of å, ä, and ö is done localized, then v and w should be considered the same also. Furthermore, it is not possible to do the sorting un-localized when the information is to be presented to humans, as different languages have different sorting-orders.

    As a side note, there has been some discussion recently to change the standard sorting-order in Sweden so that v and w should be considered different.
  • Z (unregistered) in reply to skicow
    skicow:
    Alex Papadimoulis:

    Fregas:
    On a different note, is anyone else having trouble with this Forums' CAPTCHA stuff?  I swear it breaks every now and then even when I put in the right word into the text box.

    I set it up so that it's an English word, but I agree, sometimes it's impossible to read. But, that's just the cost of randomness ... note that registered users aren't required to guess WTF the word is ...

    I'm a reg so I don't have to guess WTF the word is [:)] but I know that some CAPTCHA on a few blogs I go to are set to not work if you've been on the page for more than one minute, even if you enter in the correct word. So if you take more than one minute to enter a message before hitting the 'post' button the CAPTCHA will fail no matter what.



    Thats the way I feel this forum os working. If the comment I write is very short, the CAPTCHA works. If it isn't, one has to validate twice.
  • Craig (unregistered) in reply to travisowens
    travisowens:

    So what happens if a 3rd option becomes normal, you'll have to re-hard code this shortcut again.  So technically your defense for this method is a wtf solution, imho.

    So, let me get this straight. A less than perfect dynamic solution to a problem is a WTF but hard coding isn't?

  • 57451 (unregistered) in reply to Z

    W/w is not a letter, it's a different symbol for V/v in Swedish.


  • 57451 (unregistered) in reply to Craig
    So, let me get this straight. A less than perfect dynamic solution to a problem is a WTF but hard coding isn't?


    I think the real WTF here is that someone actually still uses VB6 (Which is known to suck on more than one occasion)
  • (cs) in reply to PeteM
    Anonymous:
    Drak:

    I'm just wondering, what's with calling all your columns A_ ?

    A is the table name, it therefore makes every field in the database have a unique name so when you write SQL you do not have to prefix the table name



    So... you prepend the columns with A_ so that you don't have to prepend them with A.
    WTF??

  • (cs) in reply to gremlin
    gremlin:

    So... you prepend the columns with A_ so that you don't have to prepend them with A.
    WTF??



    Doing so has important advantages. First, if you do a statement against a single table, you still have to prefix. So it requires less thinking. Consider all the problems if a programmer always prefixes with "A.", but once forgets it and sees the statement is still working. It would totally confuse him. Second, some database tools can automatically guess join conditions based on identically named columns. Those tools threaten the programmer's job security, since they reduce the work to be done manually. Third, some companies use hungarian notation for column names, e.g. ID_ORDER instead of ORDER_ID. This is inherently wrong, but can be easily avoided by the A_ prefixes, since A_ID_ORDER looks extremely stupid and is (technically) no longer hungarian.

    ;-)
  • (cs) in reply to ammoQ

    GROAN
    I need to invest in some better goggles.

  • Jerry J (unregistered) in reply to Raw
    Anonymous:
    Well, there may be perfectly good reasons for this (appart from such naming and so on).

    Someone has mentioned putting the common selections first, it may be that the system once worked that way, but was later changed to simple alphabetical sorting.

    Internationalization is another good cause. The VB6 combo does not sort international characters correctly, for instance it sorts the Swedish characters å, ä and ö as if they were a and o, which is completely wrong. Even the database does not sort correctly in an international environment. It understands å, ä and ö correctly, but it, for some screwed up reason, decides to sort v and w as if they were the same character.

    It probably could be better done, but it may very well be a practical solution to a very real problem.

  • Johnny (unregistered)

    Adam, My heart goes out to you. Good luck maintaining a system built by morons. You have the smarts to counter the stupidity - but still it takes time and energy to come to some level of understanding as to what the idiots where trying to do. Good luck to you! Hopefully the people that came up with this system are not playing with sharp knives.

Leave a comment on “Still Paying it Back”

Log In or post as a guest

Replying to comment #:

Log Out

« Return to Article