My First Ever MS Access Job

05/28/2012

4 Comments

 
My first Micrsoft Access problem was linking. I remember back in about 1994 when I was an Informix DBA and programmer. Our company purchased some data-mining software to monitor our production data. As part of this project, the software company had to produce an Access 2 database to manage the production data. The first version of the database came out, and our company tested it and made comments.

The second version of the software was delivered, and we hired a data entry temp to punch thousands of lines of data into it. Naturally, the instant real data had to be added to the database and issues arose, we contacted the developer. He came back with these comments: "You will have to stop the data entry, put the database on a floppy disk, send it to me by courier, and I will send it back when I've made the changes (in two days)."

This process was not ideal from our company's point of view, so I started to read the help manual (yes, there was one in those days), and there on page 13 was a section that detailed the importance of splitting the database. We informed the developer (who, we found out, was new to Access), and he promptly split the database and our data entry temp got back to work. So too did the developer!

If there is a managers takeaway to this story, it is that  it helps if you can look your developer in the eye and give him well researched advice like I did with the Database Splitting wizard.
4 Comments
 

What to do when the database gets too complex

04/07/2012

1 Comment

 
Welcome to this new blog that has managers as the key focus, not the great MS Access and Office programmers that have followed me for 20 years. Enough said, here is my topic for the day...

What do you do if you are a manager and you find that the application (read Access database) that has helped run your group for a long time just seems to be too comolex for developers and users alike ? I pondered this recently from two angles, first we were asked to help manage two really big MS Access databases and secondly Basecamp,a tool that we use for online times and project correspondance decided to start again.
To Basecamp first: there are a few million users of this simple project management tool that has been around since 2004. The other day they told us that they had started Basecamp again with reasons discussed in this post by Jason Fried. Wow I thought, that is a bold move and if you read the arguments of improved design and simplicity in Jason's article, you have to contemplate the approach.
But further down the article in the commencts section is a great link to an article by Joel Spolsky that takes the side of improving the software that you have. In this article Joel makes the point that software is complex becuase it took a long time for the developer to design software to match the real world.
So what do I think we should do with complex databases, rewrite or stick with it. I suggest rewrite if  
  1. The underlying database model is poorly designed and as a consequence the software has become complex.
  2. Your database is really successful and should be ported to a web or blended into your larger corporate environment
  3. The database is pretty well designed but the developer was an amateur who never really got anything right.

If this doesnt describe your sitation, this means the database is naturally complex and worthy of further improvement.

My programmers blog is here

Garry Robinson
 .
1 Comment