Unanswered: Professional Question - Regarding Documentation
I'm not sure how many of the members on this board use Access professionally at their places of work. Currently, at our business we created these Access databases as more of a tool to help customer service representatives do their jobs more accurately and professionally.
Our Access forms are glorified VB forms if we, the programmers, could have access to Visual Studio (right now our IT department is forbidding us to use Visual Studio).
These databases were created by phone-facing representatives who have degrees in computer programming, and wanted to make their jobs a little easier. The representatives were then taken off the phones and asked to continue to build and maintain these databases that they have created for the whole company. We went from a team of three people, to a team of two people. It's been difficult to manage the workload between two individuals when we are allowed absolutely no overtime, and our titles do not reflect the work that we do.
Since we have had no formal training or introduction to the "IT World" at our business, we have had to come up with our own processes and procedures, but can never seem to find the time to create these processes due to the immense workload that we have.
I'm assuming that several of you work full-time in Access databases and have processes and procedures for your areas of business in relationship to documentations, etc.
I'm one of the two programmers, and I'm trying to come up with some kind of documentation for the sake of longevity on these databases in the event that we both call in sick, are on vacation, quit, etc.
Do any of you have advice on what we can do for documentation to help make our processes smoother? We operate OK right now, but that's only because we created the processes. We only recently realized that we need more/better documentation on the things that we do because a member of our team left to work at another company. (So we went from a team of 3 people to a team of 2).
Right now I'm writing a document that describes the folders where are databases are located, who maintains the folders, and what work needs to be done for the folders.
My next step is to go onto the massive lists of databases that we've created and do the same.
I'm not looking for "trade secrets", I'm just in need of some direction from some professionals so as to make our process a little easier. I would reach out to the IT department of our business but they refuse to believe that we exist and turn a blind eye to what we're doing, so we don't get any support there.
Thanks so much, and I apologize if this question was posted in the wrong area.
I use Access professionally since it's 2.0 version (I "played" with it before that). I work for the local branch of a multinational company but I'm given a lot of freedom. I receive the demands from users inside the organisation, analyse them and try to provide accurate answers in the form of applications, usually based on Access as the development tool for the front-end and MS SQL Server for the back-end, though three-tier solutions are sometimes implemented. When needed, I also develop in VB/VB.Net, C++ and php.
It's very important to document my work because I'm not part of a big team (we're only two) and someone else must be able to intervene in the programs I wrote, should something happen to me.
I don't know how others do but personnally I try to keep an accurate and up-to-date documentation about the programs I develop and maintain. I use several tools to help me, some of them are commercial ones but the main part consists in specialized programs or classes I wrote and improved over the years. You'll find a sample of what such a program can generate in the attached file.
One of the best piece of advice I can give is to document at each step of the development process. Don't wait until the program is totally written and use comments generously all around your code.
I can totally relate to your situation. I've worked with Access for over 10 years in different organizations. An Access database is usually born because an organization won't pay for a "real" solution, or the business side of the house can't wait for that "real" system to be developed. The databases then evolve into something bigger than intended, and stick around longer than expected.
I second the "use comments generously" advice above! Along those same lines, use long, descriptive variable names in your VBA, such as "lngCountOpenRecords" vs. "X". Other people have had to take over my code and said that helped a lot.
Some other ideas would be to create a process flow chart (person opens database, enters data, it's saved here, then X happens to the data, etc.), or screen shots of the forms, along with the queries and subforms that are used by the form. A description of all reports and the SQL behind them would be helpful. Also, when you build tables, use those description fields!! Access also has a documenter that can help.
There are more official ways to document systems called "requirements", but if there are just two of you, then you probably don't have time to be that thorough. The documentation you should do at a minimum depends on the functionality of the database. If it is mostly to crunch data, you might need to document how it's crunching data or when. If it's mostly a user data entry interface, then focus on the screen shots and process flow.