read the documentation and jump into the code?
Fredou
2009-10-27 18:50:05
That advice is quite general.
Tony Toews
2009-10-27 19:17:29
@Tony, and what is wrong?
Fredou
2009-10-27 19:20:44
The vast majority of Access apps have no documentation precisely because the nature of most Access apps it that they grow organically and accidentally with no real plan. This is a FEATURE of Access, not a drawback, but it can make it hard for someone coming along later (even an experienced Access developer can by stymied by WTF solutions that often boil down to "this is the only way the original developer could figure out how to do it").
David-W-Fenton
2009-10-27 20:54:39
@David W. Fenton: Clearly, you have no change control and no good excuse.
onedaywhen
2009-11-02 14:44:57
@onedaywhen: how could I have change control over an app I wasn't involved in until long after it was created? Secondly, a lot of Access is self-documenting because of the way the tools used to create the app work. That is, structure is discoverable without outside documentation, particularly when standard Access approaches to a problem are used. Granted, if a developer insists on manually coding things that Access can do without code, that ups the importance of written documentation. But I'd call that incompetence -- why re-invent the wheel?
David-W-Fenton
2010-03-12 18:49:17
@David-W-Fenton: have you ever heard of a null hypothesis, falsification as an exercise in discovery? Take an assumption ("I cannot apply change control at this late stage", "All Access code is self-documenting") and invert it ("I can indeed apply change control at this late stage", "Some Access code fails to be self-documenting") and test the inversion. If you do so you may see that these assumptions you seem to hold are in fact fallacies. I cannot do this for you. You need to do the leg work. The question is, can the leopard change his spots? New tricks for the old dog? Peace :)
onedaywhen
2010-03-15 11:43:44
@onedaywhen: that was complete gibberish and I haven't a clue what you're intending to say. And it's not because I don't fully comprehend the concept of the Null hypothesis. I think it's because you're talking about something completely different than I and you've not explained yourself clearly enough to make it comprehensible what the hell you're talking about.
David-W-Fenton
2010-03-15 22:29:18
@David-W-Fenton: let's take it slower, then. Experience tells us that Access code is not self documenting. Even if it was designed by a competent software engineer (as distinct from a well meaning MS Office 'power user' or similar) an external data dictionary is required. A good online example is that of the UK's National Health Service e.g. jump in here: http://www.datadictionary.nhs.uk/data_dictionary/attributes/p/person/person_gender_code_de.asp?shownav=1
onedaywhen
2010-03-16 10:58:05
Still not getting your point. Your example looks like information that should be stored in your data tables. I have never felt a need for a "data dictionary" functionality in any of my apps, no matter what database I built them in. But it seems to me that you are confusing Jet/ACE and Access. Access can use a database engines data dictionary if it's exposed with an interface that is usable by Access/Jet/ACE. I just don't see your point here (though at least this last comment is not gibberish).
David-W-Fenton
2010-03-17 17:54:47
You confuse 'database' with 'DBMS' and 'schema information' with 'data dictionary', so you are not (yet) a professional data modeller. You do not use source control or change control, so you are not (yet) a software engineer. I've got to be one of the SO users *least* likely to confuse Access with Jet, so you are not (yet) with the community spirit. I say 'yet' because I suspect you are only one decent mentor away from conquering your demons.
onedaywhen
2010-03-18 11:32:07
...Until then all you are doing on SO is staying in your comfort zone, exercising you ego, picking fights and validating your preconceptions (many of which are misconceptions). Not that I judge you for these things that I am often guilty of myself :) What I mean to say is that you are seemingly squandering your potential. That's why I urge you to seek a mentor. My guess is that if you had a sounding board you would start to challenge yourself again.
onedaywhen
2010-03-18 11:32:41
I liked you better during the couple of months where you didn't post on Access topics. Your silence was vastly preferable to your massive condescension.
David-W-Fenton
2010-03-18 21:40:02
@David-W-Fenton: I have no intention of posting anything more on Access topics (because I think Access topics aren't appropriate for a software engineering site such as SO, among other reasons) therefore you and I should now get on like a house on fire. Keep in touch ;)
onedaywhen
2010-03-24 15:18:58
+1
A:
If you have a good understanding of VB / VB.net you should have no problems to easily dive into MS Access and fix / update issues
JonH
2009-10-27 18:53:50
+5
A:
Pretty much the same as you would do taking over any other project. Read the documentation, understand what the program is expected to do, get with the stakeholders and determine the current status and pending work items, see the software in action, play around with things as much as you can to get a good understanding.
Then you can go into the code to figure out what it is doing.
MS Access usually has
- Tables
- Queries
- Forms
- Reports
- Macros
- Modules
Review all of these in your MDB and figure out how they are used.
Imp points:
- Make sure you have backups before you change anything.
- work in Dev, not in Prod :)
- Use VSS (or any other source code control system that Access ties into)
Raj More
2009-10-27 18:58:52
The starting point is the tables and relationships as that is the foundation of the Access app. These are, or should be, in the backend MDB/ACCDB. To locate the backend MDB hover over a table link in the FE to view the path and file name.
Tony Toews
2009-10-27 19:16:49
+1
A:
All the other answers are good, but here are some practical tips from doing exactly what you've likely been doing (!):
- Check the startup code [Access 2003 · Tools menu · Startup...] for: an initial form/page ['Display Form/Page:'], an icon, etc.
- Check any custom menu bars [Access 2003 · Tools menu · Customize...] and then right-click on the menu bars you should see [you are opening the .mdb while holding down Shift (to prevent startup code from running), right? (so you can see all the menu bars in case they're being hidden for some reason by the startup code)]
- Check for a Macro named Autoexec (or alternately-capitalized versions thereof) – that macro is evaluated when the .mde / .mdb is opened (unless the Shift key is held down)
As for the rest, you'll have to follow the advice above and simply follow the code.
Kenny Evitt
2010-03-12 06:50:10
Good advice. I find menus/toolbars in an existing app that I'm coming to late in the game particularly hard to absorb and troubleshoot because the interface is not easily discoverable. It's especially the case for apps that date back to Access 2, when you could only do menus with macros. Ack.
David-W-Fenton
2010-03-12 18:50:41