• db (unregistered) in reply to Still Not Tim
    Still Not Tim:
    I don't really understand how these situations occur, so I'm asking a serious question.

    In this scenario: 1: the software is buggy and insecure, in a way that can be recognised by almost anyone with relevant experience; 2: the IT department duly recommended against it - in writing... <snip>

    There is a paper-trail, after all.

    If there isn't a specific individual accountable, then surely it becomes the collective responsibility of the board of directors ?

    The board of directors don't get to see the paper trail, they just get told of an IT problem that required taking action against the IT staff.

    If more things come out the IT staff are castigated for not making their warnings clear enough - ie. written in blood on the managers wall or whatever stupid escalation the failed manager can think of.

    Paper trails are only really useful if the majority of the chain of command is honest. That sysadmin in San Francisco probably had a nice clear paper trail which will help when he gets to court but does nothing before then.

  • (cs) in reply to Peter
    Scarlet Manuka:
    I take a nice normalised format with two tables and turn it into a denormalised format with a separate table for each month, and then put each month's table into its own database. No, I am not making any of this up.
    At first glance, I read that as "...turn it into a demoralised format". Seems appropriate, somehow.
    Oh, it is, it is. Especially when I found that the first lot of data I sent them this year was corrupt - the data volume had grown enough that I had to split the database into two parts (dividing one table into pre-2007 and 2007 on) because it was taking over an hour to generate each monthly table instead of a few minutes. What we didn't find out until after we'd sent the data off was that when I'd deleted the appropriate rows from each copy of the DB, Access had also silently dropped a bunch of others. I suspect this was due to having two copies of Access open at the same time. Silly me for trying to be efficient instead of just waiting around for the long operations to finish. Thankfully I had the Oracle tables there so I could run a query and say "no, we should have more records than that."

    Actually we had a whole bunch of other snafus this year. One of them was even my fault (two, if you count "trusting a zip utility to do what you told it to do" as my fault - or more precisely thinking "I've got two CPUs, let's run two zip processes to get through it faster"; I guess I just need to get used to the notion that You Shall Only Run One Instance Of Any Application At A Time). I was up until 3:45 this morning regenerating the data yet again, after that one. I really hope that's the last of it until next year.

  • Thomas (unregistered) in reply to John
    So because some bloke in IT doesn't like Microsoft, he tried to obstruct HR from setting up a web portal the way they wanted to do it. He mislead management about the quality of Access (it isn't that bad) and the nature of the application (an internal HR site isn't really "production").

    Did he consider the situation from HR's POV? Of course not. If he did, hed have realised that a system that's easy to set up will save the most time overall. The next Amazon or Google was not required here.

    Submitter is the real-life incarnation of Mordor the denier of information services. When he didn't get his way, he broke his NDA on a web blog whose sole purpose is to indulge whiny geeks. What an obstructionist, passive-agressive l()()zer!!!1

    So, if the data was available to anyone in the company, that would be ok right? If all of the data stored by the system corrupts itself and a day or two of work is lost, that would be ok right? It has nothing to do with not liking Microsoft. It has to do with using a corporate grade DBMS like SQL Server, a Microsoft product, for an corporate application and not a toy like Access. It is the difference between doing deliveries in a golf cart or a truck.

  • Thomas (unregistered) in reply to David W. Fenton
    David W. Fenton:
    Access is fine for an application that is going to run on the user's desktop, and only be accessed (no pun intended) by one user at a time.

    It's fine for small workgroups, too, not just single users. Of course, you have to be a competent programmer to create a multi-user Access app (using a Jet back end, of course, since Access wasn't involved in this WTF web app, only a Jet data store) that can be run by 25 or 30 people simultaneously.

    But using Access for a web application is crazy.

    Access can not be used for a web app. You can certainly use a Jet MDB as the back end for a website (not that it's advisable), but you certainly can't use Access. Access is an application development platform, for creating front ends to databases, and it won't be involved in any website whatsoever.

    Of course, the Access bigots always choose to elide the difference between Access and Jet, because it serves their purpose to ignore the fact Access is the best RAD database front-end development tool in existence, while Jet is merely a versatile file-based desktop database engine that doesn't scale well beyond a few dozen users without very careful application programming. It's the misuse of Jet in situations where it's not appropriate that gives Access its bad reputation among the Access bigots.

    But all they are showing when they badmouth Access is their complete ignorance of the product as a whole.

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

    Actually, Access (not Jet) is a narcotic. Like most narcotics, it isn't harmful in small doses. However, in large doses, it will kill you and like a drug addiction, it is very difficult to break. Once you go down the dark path of Access, forever (or at least for quite a bit of money) does it dominate your destiny. Frankly, Access does not scale. It does not port to other platforms and it has a habit of corrupting itself. Thus, if only used a RAD tool, it is average. But used for anything other that or as a tool for one-off imports, it is playing with fire.

  • Patrick (unregistered)

    Silly IT people. The HR guys had to remind them that their job is to APPROVE third party software, not critique it.

  • caper (unregistered)


    "Microsoft Jet is not intended for use with high-stress server applications, high-concurrency server applications, or 24 hours a day, seven days a week server applications. This includes server applications, such as Web applications, commerce applications, transactional applications, and messaging server applications. For these types of applications, the best solution is to switch to a true..."



    "Jet can support up to 255 concurrent users, but performance of the file-based architecture can prevent its use for many concurrent users. In general, it is best to use Jet for 10 or fewer concurrent users."

  • (cs)
    “It’s 2006,” Dave snapped back, “not 2015. Everyone knows that .NET hasn’t really taken off yet. It’s slow, difficult to code, and very buggy. Maybe in a few years we’ll consider it, but until then, ASP is far more quicker and powerful.”
    did not realise i was still in the Early Adopter program. thanks for the heads up!
  • accented (unregistered) in reply to basseq

    I'm a former Accenture employee and I can confirm what basseq said. Dave's full of it, Accenture uses the same databases everybody else does. The only time I interacted with Access when I worked for Accenture was one time when a client had some data in an Access database.

  • milop (unregistered) in reply to Been There

    It's called SQL Injection

  • nuba (unregistered) in reply to Barrett Jacobsen

    It's 2009, and thats a most canonical example of a SQL Injection, and it still has to be explained. Scary!

  • Luis Espinal (unregistered) in reply to MHD

    [quote=MHDTo be fair, instead of queuing the Access database every page request to fetch user information, it makes sense to put all that data in the session. It's likely quicker than Access. No real WTF there in my opinion. Makes sense with the tools they have at their disposal. [/quote]

    The concept on and by itself is not WTFish so long as the information being retrieved from the database into the session is not into the tens of kbs (or more), and the number of concurrent users is not in the thousands. In the WTF code example, they are loading almost 200 fields. Some of them are HTML blocks which can easily be 50-100 bytes each. Assume its 200 fields * 60 bytes (10 bytes for field name and 50 bytes per value size), that's more or less 12kb.

    For a small, intranet site, that's fine. But for a mid-size to large intranet one, that's getting into the realms of WTFland. It might sound like nitpicking, but I've seen real apps tanking because of supposedly small sessions multiplied by an unexpected number of users during peak hours.

    Furthermore, the larger the session being held on the mid-tier, the harder that it is to scale an application. One should only load into the session the stuff that is needed the most often or with more regularity. There are other stratagems that help (.ie. caching on the local disk or a local/co-located db/key-value store), the complexity of which are justified only in the face of real availability requirements.

    But a simple assumption to load a multitude of database columns into the session, including html fragments (wtf with people loading html fragments on a session?), that can easily turn WTFish real fast.

  • Luis Espinal (unregistered) in reply to Connect to Reality
    Connect to Reality:
    Who actually uses Access, for anything?

    Meh, it has its place. On different jobs, I've worked with financial analysts (or people working on logistics, shipping or inventory) using Access on their desktops to run custom reports and do their own ad-hoc analytics on database dumps provided to them at given intervals (usually daily, weekly or bi-weekly, depending on the nature of the data.)

    It's a cheap way to provide semi-quasi-okie-dokie data warehousing and reporting capabilities to what I call "power users" - business users that are sufficiently tech savvy to do their own sql queries, reporting and even VB-scripting on dumps separated from live data. The ROI of those approaches are tremendous as they increase productivity and allow power users to really analyze data and what not.

    That's pretty much the idea behind Access (and I'd surmise VBA). For that job, they are excellent tools, but then we have IT tards using them for developing actual applications with transactional requirements :-/

  • IIS (unregistered)

    Surf to http://localhost/database.mdb (or replace localhost with the servers ipadress) and watch his face go red again.

  • Rabiator (unregistered) in reply to Anon
    I've always thought that people who bullshit for a living (i.e. marketing people) would be immune to other people's bullshit, but no, this has not been my experience. It seems to me that the people who are most vulnerable to marketing-speak are other marketing people.

    Which leads me to the deeply worrying and shocking conclusion that marketing people actually believe their own bullshit! And naturally assume that other marketing "professionals" are telling the complete, total, 100% truth.

    This conclusion makes me weep for humanity.

    Oh, it also explains a lot about politicians being bullshitted by lobbyists (unless you assume outright bribes).

  • tregare (unregistered)

    why was i not surprised to see accenture mentioned....

  • Nick (unregistered)

    Anyone else notice that the ultra secure database.mdb was sitting in the root folder for IIS? Seems like it would be easier to download that than to play tricks with the SQL query.

  • David (unregistered) in reply to Barrett Jacobsen

    Yes, you're exactly correct. It's called SQL injection. What really blows your mind, is when someone develops an interface that takes SQL directly from the client.

  • sad man (unregistered) in reply to basseq

    Not only they DO use Access instead of other databases routinely, even when using Oracle o anything else they never take care of code insertion in password fields in their forms. I've seen almost EVERY WTF here published in production code written by Accenture (and its filials, such as Coritel and others). Even a simple rounding to integer it's a wild forest in their hands. And they sure are pretty well paid and pretty slow. And of course, I've never seen the least care in subjects as integrity, security, correction, and (of course not) performance, nor any ejecutive nor any kind of boss there said never a word about those subjects. The only thing that matters there is a cute suit and tie, staying seated in front of your desk even in lazy days four at leasr two hours past your exit time, and those brain-washing meetings where you are told hundreds of times how high are the incomings this year, and how good they are.

  • anon (unregistered) in reply to Barrett Jacobsen
    Barrett Jacobsen:
    Protector one:
    Could someone explain why typing ' OR ''=' in the password field would give him access to anything? I don't see the magic happening there. :/

    Because the code that called the SQL they were using was probably along the lines of ...WHERE...AND [Password] = '" + string_user_entered + "'

    Which when inputed with ' OR ''=' results in the following SQL ...WHERE...AND [Password] = '' OR ''=''

    Notice the last part the OR ''='' - that's always going to be true :P

    This trick is generically called an SQL-injection attack. Google it if you are interested.

Leave a comment on “Slow, Difficult to Code, and Buggy”

Log In or post as a guest

Replying to comment #:

« Return to Article