| « Prev | Page 1 | Page 2 | Page 3 | Next » |
|
Seriously x2 -> rlmao
|
|
Shorten the name to VDs... seems more appropriate.
|
|
I like how the DB table(s) are deleted when the application is opened. That way when the application crashes, you are sure the DB isn't corrupt...
|
|
That is one excellent piece of software! Glad I don't bank there...
|
|
I like how the DB table(s) are deleted when the application is opened. That way when the application crashes, you are sure the DB isn't corrupt...
|
|
Somebody has to say it...the real WTF is they are using Visual Basic.
CAPTCHA: stinky just like this programmer's code |
Except, they are using Excel. |
|
The Real WTF is that they are using a database. After all Excel only supports 64K rows. For that all you need is a flat file.
BTW, I am a robot. Your captcha test needs some work. |
|
The real wtf was that they didn't have a firewall.
|
|
[NEWSFLASH] they moved the spreadsheet inside the firewall! Never underestimate the power of TRUNCATE...
|
Re: One at a Time, Please
2007-09-18 15:58
•
by
Inquisitor Bob
(unregistered)
|
How do you know you don't?? CAPTCHA: bling (not for long, if you bank at that place!) |
|
Hmmm,
- Slurp all data into ram - Delete data from disk (did they delete backups too (I'm assuming here) - Pray app doesn't crash while crunching - Check to make sure nobody added data during processing - delete it if they did - Save data to disk *shivers* |
|
poor mans read-consistent views.
oof |
|
I can see the web version now...
(long pause while Javascript^H^H^H^H^H^H^H^H AJAX web page loads, taking a long time, almost as much time as downloading the entire table into the browser and truncating the table in the database. Seriously.) (dialog pops up) DO NOT CLOSE THE BROWSER WINDOW. NOT EVEN AFTER YOU HAVE PRESSED THE "SUBMIT" BUTTON. YOU WILL BE TOLD WHEN IT IS SAFE TO CLOSE THE BROWSER WINDOW. SERIOUSLY. DO NOT CLOSE THE BROWSER WINDOW. |
|
Seriously. The SEC would like to know about this bank's (lack of) internal procedures.
|
|
Given the way they handle my accounts, it's gotta be Wells Fargo.
|
Re: One at a Time, Please
2007-09-18 16:20
•
by
anonymous
(unregistered)
|
must be sybase.... |
|
Keep in mind that they tend to change a lot of the trackable details of the story- this might not even be a bank at all!
CAPTCHA: Atari- maybe it was at atari! |
|
This article gives me the screaming VBDBs...
|
|
This is a simple non-flagging optimistic read/write lock, don't see what you guys are freaking out about.
VERY optimistic. |
|
OMFG! This must be... by a wide margin... the least likely thing that has ever happened (Tarunga Leela - Futurama).
|
|
They have working backups? I call bullshit.
|
Re: One at a Time, Please
2007-09-18 16:45
•
by
el jaybird
(unregistered)
|
VBDBs = heebie-jeebies. I love it. +1 |
|
This truly meets the description of "worse than failure".
The original developer would have been better off to tell the higher-ups "nope - I can't do that", and accept failure at that point. But, because he didn't, the database/website/customers/users will continue to experience failures in this application forever. Those higher-ups will never "give up" the ability to make these kinds of changes. That's WORSE than failure. |
|
Please tell me which bank this is so I can never, ever go there. Seriously (no pun intended), that's beyond WTF.
|
To be politically correct: VBDBs = heebie-jeebies = heebie-sheebies. |
Where do you see a lock? I love this one because it is almost impossible to imagine any way in which the application could be worse without being so unusable that even the most idiotic exec wouldn't. |
|
The amusing thing is that Excel can only handle 65,535 rows...what if the bank took on a 65,536th customer?
|
At that point, the macro I wrot would kick in. It simply performs a SUM of all 65,535 columns and places the total in MY ACCOUNT!! |
|
The amusing thing is that Excel can only handle 65,535 rows...what if the bank took on a 65,536th customer?
The application creates a new worksheet? I hope it doesn't store data at the individual account level. |
here's a better idea than VBDB
2007-09-18 17:54
•
by
shadow of an elf
(unregistered)
|
|
pipe your important data to /dev/null. much faster, cuts out all the middleware.
|
Re: One at a Time, Please
2007-09-18 18:04
•
by
CynicalTyler
(unregistered)
|
|
(Of course I was being sarcastic...)
But it's a sort of lock in an abstract way. It doesn't allow other people to read or alter the data that will be in the system once VBDB is closed. Sure, it doesn't tell you you can't insert rows, and it doesn't tell you that the reason the entire database is empty is because someone else is looking at it, that's why it's non-flagging. :) |
|
Step 6 isn't a WTF. If it is a multiuser system, someone else might have updated the database while the spreadsheet user was working.
|
|
Bit close to home this one. Whilst I would never do anything as crazy as deleting and recreating a database in this risky way, everything else in this article sounds about right.
I am currently working for an insurance company (one of the biggest) as a programmer. I have designed, written, tested, trained staff to execute in my absence, a system built in visual basic for excel that is being used to adjust thousands of insurance policy premiums, and change covers, mostly automatically on another live and very complex mainframe system. Even though the company pours hugh amounts of money into developing in house software systems, as I work alone in a non-IT department for managers that know nothing about software development, not a single other person has ever been asked to look at or review any of my code. If something unexpected happens, even on another users computer I can press the magic Ctrl-Break key combination and single step and modify live running code! I can then save the program with a later version number and any other instances running on any other computers see the later number in the folder next time they check (after each policy) and update to it. The biggest WTF is that they have given me a new job title and it actually contains the words "best practice"! |
|
Hmm... must have been Northern Rock, then!
Captcha: a seriously nostalgic atari! |
|
i didn't know you could do that!
|
|
what happens if I the manager is out in the field trying to update data - can i have this application load the data onto my smartphone and then i can upload it back after the changes??
|
|
Fortunately with Excel '07 they can have more than 65536 rows! Now they just need to find the original moron...err..."dev team" and get them to upgrade!
|
|
Now I'll have to read some H.P. Lovecraft so I can sleep at night.
|
Re: One at a Time, Please
2007-09-18 20:18
•
by
didn't say before
(unregistered)
|
|
Does it have more than 255 (IV) columns?
I have a spreadsheet that is seriously just three columns short of this limit. |
|
I have a feeling that by "database" the author means "MS Access".
Sad on all counts. :( |
|
VBDB sounds like a sexually transmitted disease.
Both the name and the description. [shudder] |
|
This is bull shit no way you would have something like that in the bank. Sometimes I just wonder the origin of some of the stories posted here.
|
You sir, must be new to IT. Nothing posted to WTF surprises me anymore, and I've seen first hand, more than a few of them. |
Re: One at a Time, Please
2007-09-18 21:51
•
by
Salami
(unregistered)
|
I worked at a bank for a little while, and they have numerous databases, of varying importance. All banks are extremely anal when it comes to the important data, so I'm sure this program is used to change non-essential data that is easily reloaded. For instance, proposed rate changes that they want to fiddle with to see how it affects things. If the database is wiped out, they reload the rates and start over. |
Re: One at a Time, Please
2007-09-18 21:59
•
by
Joe Schmoe
(unregistered)
|
|
When you say "Developed Internally", do you mean by people who actually have computer science degrees?
Ah, you know, nevermind. It's actually obvious the answer to that question.. |
|
Dear WTF readers,
It's strange that a system could lose data by bad programming. We've _never_ lost data. Sincerely, Session variables |
|
Ya all know, previously I was also opposed to the idea of using Excel for editing the data in this way. In fact, I was forced to write it. But... In the end, I have to admit, it has its uses.
First, creating something like that is extremely quick and simple. Second, business users stay in their beloved Excel, which is (love it or hate it) - THE best spreadsheet tool out there and it is the best for editing tabular data. Third, when done right, it's quite user friendly and reliable. What I did - I had set up a data import wizards - nice dialogs leading the user through the whole process. It also had different transactional options that user could choose: submitting all the changes in a single transaction or one by one with optimistic concurrency. Is it bad? I don't think so, it all depends on the context. If you have - A very limited number of users, like 1-5 - Users almost never work on the same set of data - The data sets are small - under 50K records This method works just fine. Why not? Prove me wrong. Yes, it is not scalable. So what, by the nature of the application it doesn't need to scale at least in the next few years. Yes, it goes directly to the database - what the hell, most internal business desktop GUI applications do. So it has limited number of uses. But it can be implemented quickly, be user friendly and it doesn't require high qualification to develop and use. Which is what counts in many situations. Stuff like business analysis and forecasting often doesn't require 24x7 availability and scalability. But it requires quick development and flexibility. |
|
The biggest WTF here is the people here who think Excel is a database.
:) |
| « Prev | Page 1 | Page 2 | Page 3 | Next » |
codemonkey: