• Shinobu (unregistered)

    I cannot believe how many responses this article is getting that seem to assume that what the article says is true. Autoclicking in the task manager and then popping up Notepad? You don't seriously believe someone would code that when it's so much easier to terminate the processes directly, I hope?

  • AdT (unregistered) in reply to Shinobu
    Shinobu:
    I cannot believe how many responses this article is getting that seem to assume that what the article says is true.

    I can't believe how many people say that an article is false, even though they did not read it carefully, nor comprehend it.

    Shinobu:
    Autoclicking in the task manager and then popping up Notepad? You don't seriously believe someone would code that when it's so much easier to terminate the processes directly, I hope?

    There was no autoclicking. Someone remoted into Eric's machine. This is totally obvious from "Learning the Hard Way", for example the sentence that says a text appeared in Notepad letter by letter (as opposed to all at once) clearly indicates that this wasn't scripted.

  • David W. Fenton (unregistered) in reply to Tourist
    Tourist:
    David W. Fenton:
    This WTF does not pass the smell test.
    1. "Access" could not be used as the datastore for an application this large.

    It can be used, it has been used, I have seen it used myself in a real WTF project so what is so difficult to understand? There are such crappy architectures running, and the problem with Access (as well as VB6) is that such tools support/encourage creating such crappy solutions.

    Access (i.e., Jet) has never been used as the data store for an app with more than 2GBs of data because Jet has a hard-wired 2GB limit to the size of a Jet MDB. I can't imagine that the system described in the original post could fit its data comfortably into less than 2GBs.

    So, again, it's not credible to claim that "Access" was used as the database. The only thing Access could have been used for was for the front end application.

    -- David W. Fenton David Fenton Associates http://dfenton.com/DFA/

  • (cs)

    DO NOT READ WHATEVER COMMENTS YOU WERE READING!! YOU DEADLOCKED -- TDWTF CRASHED!!!!!

    • THANK YOU, COMMENTER

    Seriously, If I ever work for a software company, I'll install a GNU/Linux system that I can control if possible. That sort of remote control over your computer seems so 2001-ish.

  • (cs) in reply to David W. Fenton
    David W. Fenton:

    Access (i.e., Jet) has never been used as the data store for an app with more than 2GBs of data because Jet has a hard-wired 2GB limit to the size of a Jet MDB. I can't imagine that the system described in the original post could fit its data comfortably into less than 2GBs.

    So, again, it's not credible to claim that "Access" was used as the database. The only thing Access could have been used for was for the front end application.

    -- David W. Fenton David Fenton Associates http://dfenton.com/DFA/

    Well your whole argument basis on the assumption that the database is larger than 2GB

    Back in 1996 when I worked with Access last time, their database was ~2-300 MB despite having similar requirements as mentioned in the article. Still I maybe remembering wrong, it was a long time ago.

    Nm, no point in arguing about assumptions.

  • Rabiator (unregistered) in reply to Quango
    Quango:
    Franz Kafka:
    Bob X:
    Dude, haven't you noticed how many WTFs are the direct result of choosing MS Access to be the backend of a high-volume multi-user production-critical application like this?

    Frankly, MS should limit Access to 50 tables per DB, 100k records per table, and 20 concurrent users. That would make it great platform for your tape collection DB, but impossible to use for Ford's production control system. As it should be.

    Captcha: luptatum. WTF?

    That's fucking stupid. In the situation you want to avoid, they'll cobble something together, grow the tables over time, and run into a hard wall at some random time, probably at 11:30 on a tuesday with no way out except to upgrade the system while completely dead in the water.

    You're basically advocating a time bomb.

    A rather rude and unintelligent reply considering you don't know the full context.

    What if there was a tight budget? Maybe it's a short term solution for a system that has a limited lifespan anyway? Creating a full client-server RDBMS solution when one isn't needed is just as much WTF as the original story was. There have beem examples of these in this very site.

    I think GP (Franz Kafka) referred to the possibility that the "short term" solution grows bigger than expected and eventually runs into the hardcoded limits at the most inconvenient moment.

    With regard to the 100k records per table I agree that this is fucking stupid. Because the system may exceed those anytime during normal use and become unusable (assuming normal use requires adding more data).

    The 50 tables per DB and 20 concurrent users are more reasonable because they don't hit you quite that hard: A developer may run into the 50 table limit when trying to extend the system, but the existing version won't collapse because of it. Likewise, the inability to add a 21st user is only a limit on growth, but won't amount to a sudden shutdown.

  • (cs) in reply to Tourist
    Tourist:
    David W. Fenton:

    Access (i.e., Jet) has never been used as the data store for an app with more than 2GBs of data because Jet has a hard-wired 2GB limit to the size of a Jet MDB. I can't imagine that the system described in the original post could fit its data comfortably into less than 2GBs.

    So, again, it's not credible to claim that "Access" was used as the database. The only thing Access could have been used for was for the front end application.

    -- David W. Fenton David Fenton Associates http://dfenton.com/DFA/

    Well your whole argument basis on the assumption that the database is larger than 2GB

    Back in 1996 when I worked with Access last time, their database was ~2-300 MB despite having similar requirements as mentioned in the article. Still I maybe remembering wrong, it was a long time ago.

    Nm, no point in arguing about assumptions.

    Hos whole argument is predicated on the notion that there iis only one WTF-ish database involved. I could easily believe that some early incarnation of this steaming pile ran up against the 2GB limit and now there's one DB for every auto plant they supply to, with plenty of juicy spaghetti handling interaction across all the DBs. They could also be using flat files, numeric "codes" for each item they stock, all sorts of things that might not reach beyond 2GB. But I do agree that the design is likely not entirely svelte.

    Of course, Occam's Razor says that it's just a plain old piece of crap.

  • (cs) in reply to Mr. Smith
    Mr. Smith:
    When any company tells me they are using Access I tell them that my 8 yr old niece uses that as well for organizing her tape collection and perhaps they should talk to her if they want someone who ENJOYS using Access.
    Is your young niece surprisingly old school in her music tastes or a big fan of 3m and Manco?
  • blunder (unregistered) in reply to biziclop

    You'd think so, wouldn't you? Our security tapes say different. Everyone has to make a mistake with a 2-ton forklift at least once before they realize it's not worth tempting fate. It's only the ones that keep screwing up that you have to watch out for.

  • Kutai (unregistered) in reply to Tony

    Heard about BigTable? Google's production database is column based and not relational as other RDBMS, since their data is not relational anyway. It can take advantage of the nature of the data, which is not relational and non transactional, and is superfast, easily extendable, etc.

    Plus, how much is the license cost for Oracle installation that stores the whole world data? That, and several other installation for DR. And it has to return the most relevant (not the most accurate) results in microseconds.

    I don't know, but for me, and given the size of Google, in this situation, rewrite is granted.

  • Ty (unregistered)

    1: Acquire a full backup of the entire system, and port it over to a play environment. If they do not have a backup scheme in place...yeah. Inform them that their database is slowly corrupting itself and, one day, it will go kaput and the system will be down for days to weeks. 10 grand now for an active backup solution and some downtime is nowhere near as bad as 3 weeks of downtime. They can install this during their planned downtime/days when orders can be completed early.

    2: Analyze the data, Create new metrics.

    3: Inform management that if #4 fails due to people worried about job loss, you will be walking away from this project. If they want to not hire new people, sure, but if they want to fire people, you know they are not only incompetent but also need to be shot. If #4 fails for this reason, meet with a higher up and explain the problem to them; consider the contract terminated when you do that and start job searching beforehand.

    4: Run around the warehouse, talk to everyone about the daily problems. Hand out sheets of paper and ask people to write down what annoys them, what takes forever and a day to do, etc.

    5: Create a baseline you want, write up a design document and start development.

  • Jeff (unregistered) in reply to Jethris

    It's a kind of sexual act, involving the use of ice cream to emphasize your partner's title (or appellation).

    Seriously, I think most of the CAPTCHAs here come from someone's lorem ipsum magnum oopus.

    This CAPTCHA: 

    incassum
    ('in vain', or 'progressive female-fronted metal', or so says http://www.incassum.com) :-)

Leave a comment on “A Barely Accessible System”

Log In or post as a guest

Replying to comment #:

Log Out

« Return to Article