put in this situation

M

Michael_Corral

I am working with an Access 2000 database that I did not create. The
original creator is not accessible. I am not an expert with access but not
bad either. My office skills, including MS, are on the high side. In any
case, do you have any suggestions on how to approach this problem when you
put in this situation?
 
R

Rick B

You have not told us your problem. You have taken over for someone. What's
the problem?
 
C

Chriske911

I am working with an Access 2000 database that I did not create. The
original creator is not accessible. I am not an expert with access but not
bad either. My office skills, including MS, are on the high side. In any
case, do you have any suggestions on how to approach this problem when you
put in this situation?
Click to expand...

this is such a vague question but what the hey, I'll give it a shot

do not badmouth the previous author
he could be a lot smarter than you and used shortcuts you have never
heard of

ask users what it does and how the database works
they know what the various buttons do and most of the time they where
the ones who asked for functionalities

analyze the database anyway you are acquainted to, use build in tools
or write it on a piece of paper, whatever

create a lot of copies, leave at least one of them untouched, no matter
what

take a look at the code, print it out if it is a lot
that way you get an oversight far more easier than with debugging

if it works, leave it be

access VBA is not that hard so you'll pick up easy if you already used
VBA for another office application

don't let your self be tempted to have an oversight of everything at
once

take a close look at the datatables and their relations, it's bindings
with forms and/or reports
therefor you can use name tracking or again whatever you are acustomed
with

then you can start to update parts by putting descriptions in the
fields that are to be used for it (if there isn't any info there yet
that is)
or create a document describing the workings of the database, a manual
is always a good idea

inserting comment in modules is another great help, what it does, what
parameters are required and off course what it gives back

and so on

grtz
 
M

Michael_Corral

Other than not understanding how she set this up, not happy that there are no
fail safes and or input masks, I have received errors from a query I believe,
in side a subform of a form that I cannot fix.

Any suggestions on how to fix something like that? Do you know how view a
subform in design view?
 
A

Albert D.Kallal

Hum, well, first make a backup.

The next thing is to printout the table relationships diagram. you need to
get a feel for the tables, and how they are connected.

Understanding the tables and how they are connected (related) is likely the
best thing you can learn.

After that, you will have to just use caution when you modify things. And,
if you split the database, then users can continue to use the original copy
while you modify, and update the "next" great version of the software.

Further, grab the mzw tools. They are FABULOUS for working your way out of
the dark. The tools can be found here:

http://www.mztools.com/

The reason why the above tools are so great is that you can be in a
subroutine/function, and have mztools show you what CODE CALLS that routine.
I mean, you COULD navigate" to a function by placing your cursor on the
function, and hitting shift f2..that jumps to the function..and you can
continue this drill
down through your code. And, shift-ctrl-f2 would un-cork back through your
code (this skill is invaluable for following new code and their sub calls).

However, mztools can tell what current routines call the existing code..and
that includes forms calls. *very* nice.

I don't think a big huge printout of the code is of any use..but the ER
(relationships diagram), and the mztools goes a LONG way to helping you find
your way in a dark unknown forest called someone else's application!
 
K

KARL DEWEY

Keep lots of notes - dated.
Copy code, SQL, criteria, etc, into a running Excel file with comments why
you made the change.
Remember to insert the date in the file name of backup copies as the date
Modified of the file is changed even if you do nothing but look.

Change a little then test - do not do it all at once. Ask someone else to
test what you did. See if they can work the database without asking
questions.

Write a book (two books) one for data entry and reports operator and then
one for the next database manager as it might be you. A year from now you
will not remember what and why you did something.
 
Top