- Feature Articles
- CodeSOD
- Error'd
-
Forums
-
Other Articles
- Random Article
- Alex's Soapbox
- Announcements
- Best of…
- Best of Email
- Best of the Sidebar
- Bring Your Own Code
- Coded Smorgasbord
- Mandatory Fun Day
- Off Topic
- Representative Line
- News Roundup
- Editor's Soapbox
- Software on the Rocks
- Souvenir Potpourri
- Sponsor Post
- Tales from the Interview
- The Daily WTF: Live
- Virtudyne
Admin
Sorry, you are so wrong. My ex-girl friend works at a major bank. And the software let's her go into any account and change any data element. The only difference is the software automatically logs which user account made the change, when and what the old data was.
This would be fine except when she first go access other people at the bank always wanted her to correct errors in the accounts that had nothing to do with her job.
In other-words, they screwed something up and rather than fixing it themselves and leave a trace-able log of the person causing the problem, they tried to turn her into their patsy. When she refused, they did not fix the data, instead they hoped no-one would notice and the mistake would be lost in time and the user's transactions
She clued in fast, but it shows there are people in banks who rather the database be wrong than they getting blamed for their own mistakes.
Admin
Somehow this sounds like an anonymized HR management DB frontend. So nothing serious. Sure, some punter may be left without a paycheck this month, but that's nothing beancounters downstairs can't resolve.
Admin
Ummm..which version of Excel are YOU using?
Admin
If the table is cleared while you work, how can two people update it at the same time (as claimed in the article)?
The second person will see an empty file...
Admin
This method works just fine. Why not? Prove me wrong.
Seriously? OK. To keep it simple, let's assume someone isn't trying to access the database while someone else deletes it, and noone tries to open the same file twice. We'll also have to rule out when the luser inevitably pours his coffee into the PSU, or can't understand why closing a file takes too long and hits reset.
The problem with your idea is its one-way nature of edits, with no way to close the file without saving.
Admin
[q] Seriously? OK. To keep it simple, let's assume someone isn't trying to access the database while someone else deletes it, and noone tries to open the same file twice. We'll also have to rule out when the luser inevitably pours his coffee into the PSU, or can't understand why closing a file takes too long and hits reset.
The problem with your idea is its one-way nature of edits, with no way to close the file without saving. [/q] Please re-read my original post :). And I thought I stressed "when done right" part strong enough. To address your concerns about saving and data consistency - transactions. To make sure user knows what's going on - use a GUI and make deletes/updates on user request (Load/Save buttons), not when the file is opened/closed.
As far as opening the same file and all. Yes, yes, the data shouldn't be deleted when the spreadsheet is opened. Delete it before saving it back. Use some sort of simplistic app level locking and transactions and you are golden.
Surely, I wouldn't choose something like that for truly multi-user environment. But for a limited set of problems it works. It's a matter of choosing right tool for the job. You don't need a milspec superglue and kevlar strips to seal a cardboard box - scotch tape will do just fine. And you don't use a scotch tape to seal a hole in ships hull, but there's nothing wrong with scotch tape per se. Right tool for the job.
Admin
"People" over here think XML is a database too :o)
Admin
The real WTF is that people aren't doing enough to stop global warming. >8^(
Even better... -User A opens the file; the data is deleted. -User B tries to open and gets an empty file. -User A closes the file, the data is deleted again and then his local copy is inserted. -User B closes the file, the data is deleted and then his local copy - which is empty - is inserted. :DAdmin
OOOO_OOOOO!!
I want to work for a bank, too. Not thinking about obscure stuff like 'design' or so and getting paid big time at the end of the month.
Managers should be shot for hiring such people!
Admin
Well, isn't it obvious from the story: User 1 opens the app. DB truncates. User 2 opens app, finds no data. Assumes data corruption, calls for restore of backup. Admin restore. Does this all the time, probably has a shortcut of some sort. User 2 open app, DB truncates again.
The data saved last will stay... craaazy (like the captcha)
Admin
Sheer stupidity at its finest!
Admin
Personally, I don't see any good reason to use Excel for this purpose. If you really wanted to give somebody access to editing tables directly, and you didn't want to build a front-end for doing so, or let them use an existing program that was intended for real DBAs, but you really wanted to use a Microsoft Office program, why would you choose Excel over Access?
You can easily set up a "linked table" in Access that will work through an ODBC connection. A former employer (with no developers on staff) used this solution for a couple minor applications before I changed it to something better. I just can't see any time where using Excel to edit a database makes any sense what-so-ever. It's kind of like using a radio to watch TV.
Admin
Nah! It's gotta be Northern Rock
Admin
Hope so, then maybe my mortgage will get accidentally deleted someday.
Admin
What about relational integrity? If you don't have constraints on your DB, why are you even using a DB backend in the first place? And, if you do have constraints, how are you maintaining the integrity during this goofy process? And, what's this nonsense about transactions? If this process runs even close to the way described, you don't even know what a transaction is. "[M]ost internal business desktops GUI" applications do go directly to a database. That's not the point. The point is, how do "most internal business desktops GUI" go about changing the data in the database? This is bad; always bad. There is no context that makes this OK. If the data doesn't matter, get rid of the DB. If the data does matter, get rid of the front end, and change your business practices.
Admin
Still, I would want to be sure the DB is always in a coherent state, and that each update to the DB leave it in a coherent state.
I don't mind if the application has to be a VB application using Excell sheet invoking shell script calling web services.
True, concurrency can be a big problem, but there exist a couple of simple patterns to avoid problems elegantly and easily.
Admin
Atleast they were doing backups. I wonder how many crashes they experienced before they realized they should be backing it up. :)
Admin
The problem is that you can't do something totally wrong and make it right by stressing "when done right". You can't do something totally wrong right; it is always totally wrong.
Which version of Excel became enough of a database to support transactions? I must have missed that in the documentation.
And that's the point everyone here is trying to make. Excel is not the right tool to use as a database. Ever. It's a frickin' spreadsheet. Repeat after me, please:
Excel is not a database. It's a spreadsheet. Excel is not a database. It's a spreadsheet. Excel is not a database. It's a spreadsheet. Excel is not a database. It's a spreadsheet. Excel is not a database. It's a spreadsheet.
Enough said?
Admin
It doesn't matter how many times you say it, the problem is most people don't understand the difference. Most people have no clue what a relational database is or how to use it.
Admin
Admin
Admin
HAHA Change the name to VDs, that's just too much LOL, I agree completely. Apparently they don't understand where clauses and parameters, oh wait if the mentality to delete the entire table after it's in such a stable, and well programmed Excel, was a thought I guess I should expect nothing less.
Sadly in our company Excel has become the tool of choice and everyone wants all data put into Excel for them to use it, we're getting them used to web forms and such now Thankfully.
Admin
Right, I agree, If they can manage Backups, they've got to be smarter than to do this crap, although the backups are probably in Excel. He keeps excel charts, and just does a select all rows copy paste into excel to make the backup, and they are obviously all full backups, no transactionals. although if they have the backup mentality one would think they would have the don't delete * mentality (I'm assuming Truncate is not a verb in their vocab)
Admin
Why wasting time developing that? That's The Complicator's Excel File Overwriting System! :)
Admin
Thank you, I thought the same thing, when they go to grab it it's gone, because it loads the data, then deletes right away, it doesn't wait till save to update.
Admin
In fact you are mixing up two terms: 'database' and 'relational database'. You are right Excel is not a database. The most important reason why: It does not have a DBMS. Not because it is not relational (there are also non-relational databases....)
Admin
Cool can I get all my data restored in my spreadsheet then? Oh and I need a few records in my spreadsheet updated.
Database? What? It's a spreadsheet, Ken said so.
Admin
Admin
Admin
My bank has its own level of WTF's - incompatible with this one... LOL
Admin
Actually no, it isn't a lock at all. It is simply a "Last one in wins" situation.
Admin
ding ding ding
we have a winner
Admin
Admin
ding ding ding
we have a winner
Admin
Admin
Imagine how much easier your job could be. Imagine no meetings, no signatures on change control paperwork, no code written by people other than you. Imagine being able to just log in to the production server to make a quick fix. Imagine being able to log in to the database server to manually fix some data.
This is actually my life.
Admin
While I highly doubt that this system was in place for any vital data (read the story... it's used by two exec-types in the bank, probably for tracking statistics or information about whatever department they oversee) it's not unheard of for banks to have very obsolete software.
I work for a bank and develop internal software applications for our department. Something like what's described here might be something I'd write (not the VB DB part, but the purpose of it). I've written software to track time spent on tasks, some to store data on invoices for clients we do work for, and even one application for employees to view which projects they're assigned to. Everything I write is non-vital to the actual workings of the bank... if I delete everything on my server (code and databases), my department will keep running, no money for customers will be lost, no private information compromised. My manager and the director will be a wee bit miffed as statistics and tools we use will make our jobs more difficult and they can't report statistical information to the higher ups (such as how much time people are spending on each project) but it's not vital.
And on the flip side, we have obsolete DOS based software for tracking transactional information on applications and financial records. One system tracks the user ID for anyone that accesses or changes the information. Unfortunately though, it overwrites whoever last did the changes. I can tell you that Peggy Sue was the last one who changed the address in that application, but I have no record that Jimmy James went in and just before her and raised the limit to $100,000.
Banks do have their WTFs in their software, but something this atrocious in the story ain't it. Something like that would cause the bank to come to a crashing halt. My example just makes it difficult to track fraud... not impossible, not vital to the daily functions of the bank, but still retarded.
-- Seejay
Admin
2 words: "HOLY SHIT!!!!" Ahum... sorry...
The real wtf is that it happened in a bank !!!!! What kind of bank is hiring such incompetent development guys ? it's terrifying...
Admin
Admin
Admin
Fortunately for OpenOffice.org, I don't need Excel '07!
CAPTCHA: doom (for Microsoft!)
Admin
Holy Crap!
You're me!
I work for an insurance company. I am a software developer and DBA working in a non-IT area. I write mission critical apps and the DBs to support them. I too have to edit live code throughout the day in order to keep production up and running.
The problem for me, and you too probably, is that like you said, the managers have no experience with what I do. Unlike IT managers who at least understand product lifecycle management, test cases, etc., these managers don't. However, I do. But that's not enough. Even though I know I should write test cases, I don't have the time or the resources. It's all developed on-the-fly and deployed immediately. The problem with that is that you end up spending too much of your time maintaining and fixing a broken system that shouldn't be so broken.
It's a vicious cycle of fast paced development and I-need-it-NOW fixes.
captcha: ewww - how I feel about the apps I develop and put into production.
Admin
I think it's worse for us, the CS degree folks, than it is for the hacks. At least the hacks are too stupid to know what they did. We KNOW why their work is so wrong on so many levels. And furthermore, we have to fix it.
Ugh.
Captcha: smile - You get to fix someone's nested for loops because they don't understand the performance implications of O(n^2) runtime.
Admin
Once I tried to explain that to a girlfriend of mine (she was a techie) who didn't know why when she processed more than 1000 items in the program she wrote, it would hang for hours...
I was met with a blank stare...
I drew some graphs that illustrated the time vs items relationship...
She said she needed to go see her parents...
And I never saw her again.
Admin
I would make the same recommendation. However, the Excel app was used by executives. When an exec tells you he doesn't care how you do it, so long as he gets to work in Excel, then you just pucker up and say "Yes".
Welcome to reality.
Admin
The ironic thing about the snarking about Excel and XML not being databases is that it is actually correct, but not for the reason the snarkers had in mind. Excel is a piece of software, not a collection of data. XML is a metalanguage, not a collection of data. So, they are, as stated, not databases. What the snarkers meant, but failed to express correctly, was that Excel spreadsheets and XML documents are not relational forms of data, which is true only if we define 'relational' strictly as meaning third-normal form relational data. Excel spreadsheets contain tabular data that can reference data in other spreadsheets. That's fairly relational. XML documents typically contain hierarchically organized data that can refer to data in other XML documents. That too, is pretty relational. In any case, they are databases.
Let's get out of the snooty habit of dismissing anything that isn't SQL-92 compliant as "not a database".
Admin
Think CSV...
it isn't pretty but in the end its only slightly less full featured a DB as an XML file and much smaller and faster for same data.
Admin
I kinda had the opposite thing happen the other day.
My wife does second tier helpdesk support for an inventory management system (she deals exclusively with IT departments, it cuts down on the morons even if it doesn't eliminate them).
Anyway, they run exclusively on Unix systems, so she does a decent bit of scripting to catch logs off hours and what not.
She put together a script that worked pretty well in sh+sed (not bash, mind you...). Then she got to run it on a bigger system which had about 25k records for one of her loops which included a couple of commands. The script took a much longer time on that run.
She tried rewriting that loop in pure awk, and it sped back up to a manageable amount of time. When I explained to her what happens when a Unix system fork()s a new process and the delay involved, I got halfway through my sentence and she said "Oh, that makes sense!"
And she doesn't have a CS degree either.
And to reiterate, I already married her, and no she doesn't have a sister.
Admin
I call bullshit to this story. You're a computer geek, you found a woman and married her, and she's smart enough to understand Unix, SED, AWK, and fork()? What fairy tale are you living in???
-- Seejay
(for the humour impaired, thassa joke so don't get your panties / jocky shorts wadded up about it)
Admin
3rd normal form is not a criteria for representing data using the relational model. 1st normal form is, though. 3rd normal form (actually, 5th normal form) is simply a design guideline that confers certain advantages.
Ugh.