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.
Well, someone at the big bank David works at had the same idea. Checks and balances are for wimps. And out of this idea, Visual Basic for Databases was born. Developed internally (and not to be confused with commercial products with the same name that for all I know are good), VBDBs gave the user total control over the data using a VB-powered Excel spreadsheet.
VBDBs worked via the following workflow:
- User opens Excel spreadsheet.
- Spreadsheet automatically populates with data from the production database.
- The spreadsheet automagically deletes everything from the table in the production database. Seriously.
- User messes around, making data changes and playing with forms.
- User closes spreadsheet.
- The spreadsheet checks if the table has data in it; if it does, it gets deleted again (like in step 3). Seriously.
- Excel populates data in the spreadsheet into the production database.
Simple. But sadly, this application was broken by the introduction of a firewall into the network. A shame, since strange and wonderful things were sure to happen if, I don't know, more than one user was using the application at the same time.
In fact, there were only two people in the organization that had access to VBDBs; two super-high-ups in the bank. And they had used it simultaneously. It caused problems all over the place, which led to the original developer often restoring from backup. VBDBs crashed pretty often, and if it crashed after the tables had been cleared, all that data was lost.
The original developer left the company years ago, but the team he left behind is currently working on a new and improved web-based version of VBDBs.