• Brian Boorman (unregistered)

    Is it really a "user entered" timestamp or rather something that some Javascript in a browser front end generated from the client local time?

    Not saying that's any better, and certainly the injection surface is still there, just that I find it harder to believe they make a person type in the date and time .

  • (nodebb)

    They should deploy the database server on the planet Mars, then the date/time formatting requests can be handled literally "IN SPACE", which I'm sure will be a buzzword at some point in the future.

  • (nodebb)

    Databases get their time from the servers they run on, which gets time from a time server, which gets time from an atomic clock, which gets time from some quantum mechanical process involving entangled particles (maybe). Or we could go back to the days of a stick in the ground.

  • TS (unregistered)

    "In fact, I could log into the production database and make changes to my heart's content"

    Did you work for Fujitsu by any chance?

  • TheCPUWizard (unregistered)

    CLR code in the Database... used it all the time to good effect.

  • Pabz (unregistered) in reply to TS

    I thought exactly the same thing - you beat me to it! I'd like to think that the Post Office Horizon system would have been a lot better if Remy had been involved :)

  • Old lurker (unregistered) in reply to TS

    You don't have to single out a particular company because this shit is far more common than you'd believe. Heck, I had the displeasure of facing a similar situation (thankfully I didn't take long to get out) and I never even sent a resumé to any company in the same field as Fujitsu's.

  • Sami (unregistered)

    EDI to XML to a query string, sent to a database to do parsing, getting back, creating a new text to be be formatted in a database via network. No wonder we have an environmental problem.

  • Hal (unregistered)

    I find Remy's comment interesting because everywhere I have worked the exact opposite was true. Usually some DBA was master of the universe and ANY changes that required ( if you implemented them sanely ) and schema extension or would make sense to do in a procedure with some temp tables or even just complex CTEs, was impossible to get migrated to production.

    So I have always ended up with front ends that do lots of ugly looping, sorting, comparing, aggregating, computing, that resulting in massive object creations and other memory fragmenting mayhem at the web tier to do stuff that could have been trivially expressed in a few SQL statements, and executed far more efficiently by the database engine.

    While all that might be forgivable if you the DBA believe yourself to be faced with severe resource constraints and no hope of getting new kit just as often I was faced with I'd like to add this attribute, or create a new entity relation, whatever you DBA think best, always to be 'No' so we can end up with, well 'description is a VARCHAR, so it will be multi-valued field now...'

  • Geomancer (unregistered) in reply to Mr. TA

    From the CLOUD into SPACE would indeed be a step up...

  • TS (unregistered)

    In case my comment above was excessively cryptic: Everyone in the software industry should familiarise themselves with the Post Office/Fujitsu scandal, which has enough WTFs to keep this site going for years. https://en.wikipedia.org/wiki/British_Post_Office_scandal

    TRWTF, of course, is that Fujitsu has completely got away with it.

  • Noadle (unregistered) in reply to Hal

    Not so very long ago I was working on a programme collecting accounting transaction data for analysis.

    The original developers - all Rock Star and/or Genius in their own opinions - had written their own "ORM" library which spilt read and write into different objects. This sort of made sense in context: if you used the Reader you could absolutely guarantee that you wouldn't be able to write to the database. Unfortunately for us the Writer a) couldn't read from the database b) couldn't be extended to execute any sort of useful aggregations.

    The processing code on the application server was thus forced to hold all the transactional data in memory, and execute numerous loops over the data to build out the different aggregations. There was one memorable data set that yielded a 30GB database file out of 9 years of accounting records. 99% of that was the aggregation tables because someone had tried to void out invoices by adding counter-invoices with dates set to "invoice_date + interval '20000 years'". The G/L account monthly aggregation tables were VAST, and almost entirely static.

  • (nodebb) in reply to TS

    Just looked it up, and wow. "Over 900 subpostmasters were prosecuted" and "over 4,000 subpostmasters had been identified as eligible for compensation" - so for around 15 years, they thought they had thousands of subpostmasters trying to rip them off, and refused to consider "hey, maybe there's a bug in the software", or literally anything else that could have been going on? Like, not even after the one-thousandth prosecution? Incredible.

  • Drux (unregistered) in reply to Brian Boorman

    I guess the term "user supplied input" instead of "user entered" is more common and would describe the situation better.

  • SG (unregistered) in reply to TS

    To be fair, Fujitsu have gotten away with it because writing crap software is just such a tiny part of the wider scandal, compared to all the Post Office people trying to cover up their part in buying the crap software in the first place...

  • (nodebb)

    Based on personal experience, I wonder if this person ends up in a similar position I was, once upon a time. Many years ago, I worked at a place that had pretty strict deployment processes for getting code promoted to even test application servers, but no one had any rules about how code got promoted to database environments. In fact, I could log into the production database and make changes to my heart's content (yes, terrifying, I know). But the result is that our web code was a thin wrapper around database code

    I once worked in a company that had a product where the dev team did exactly that. I asked the project manager why they were putting so much code in the DB server and his answer was literally "so we don't have to do change control".

  • ichbinkeinroboter (unregistered) in reply to Hal

    in 30 + years I have seen both just as often...

Leave a comment on “Time for Oracle”

Log In or post as a guest

Replying to comment #:

Log Out

« Return to Article