tbrown7777 said:
I recently took over an instrumentation and control group. We have a
database that we keep our calibrations in that has two files to it. I'm not
sure why is that because it's on a network?
I have been looking at it and there is duplicate tables in it, macros that
point to the wrong directories, tables that don't key to the correct piece of
hardware, etc. It's a mess. I am quite familar with excel vba so I am
challenging myself to get familiar with Access related VBA. Will it hurt
anything to copy both files and move then to my home pc to work on? I was
told someone tried this once in the past and it moved data rather than copy
it..... any guidance or links to info would be a huge help.
thanks,
Tim
A cautionary tale. I once joined a development group in a well-known
corporation. I had a smattering of relational theory and some VB, so I
was invited to take over an Access development which was "nearly
finished" as the developer was moving to another project where he had
specific skills. Cost me my job.
Looking back, instead of trying to make that thing work, I should have
got myself up to speed with Access independently (a couple of weeks'
intense study) and then gone back to the original specification and,
while checking occasionally what had been done before, built the thing
again from scratch.
It was never going to work - the table design was just wrong, so
everything that he'd built on top of it had to be wrong. My predecessor
had built everything using wizards, but when you come to an Access
project second-hand you don't see that, and focusing on the surface of
the monster concealed the incoherence at its heart.
Yes, my mistake - I spent far too long simply taking on trust that there
was value there that I had a duty to preserve, but it was a pile. I
could have built it three times over by the time my contract (not
renewed) was up. The original developer had built his
(not-quite-working) edifice in a couple of months, and his productivity
was much praised...
Access is potentially immensely complex, although there are great
facilities in the tool to help you deal with that complexity if you can
learn them. It's also immensely rewarding, as an experienced developer
can produce powerful applications remarkably quickly. However, few
developers document their work in the way that professional software
engineers should - there are so many "idioms" (patterns of doing things)
that after a while it feels unnecessary (I'm guilty too). So you end up
knowing what your precedessor's code does, but seldom why, unless you
have the experience to recognise those common patterns.
So, as a self-declared beginner in Access, at least consider a different
approach. The data should all be there, and Access is so powerful a
development tool that you may be able to recreate it in a way you
understand, starting with the most essential functionality and building
on bells and whistles as you come to understand them. If you need the
thing running quickly, get in someone who already has the skills.
The database will have two files if you have a "front-end" and a
"back-end" - good practice (and a hopeful sign). The back end contains
only tables, and the front-end contains any queries, forms, reports and
VBA modules which make the database an application. Back up both
regularly: the File > backup option gives you a useful dated filename.
If you're going to get up to speed yourself in Access, look at the
Access courses on lynda.com - the first few lessons are free, and you
can sign up for as little as a month at very modest cost. There are, of
course, loads of books - I've used the Access Bible.
Good luck!
Phil, London
