I’ve been discussing how I use version control in 2 previous emails / articles which you can find here:
Access Programming – What I do and Why (source control) | Access JumpStart
Access Programming – What I do and Why (source control part 2) | Access JumpStart
This is part 3 where I plan to get into the details a little more and how my process works.
How often do I commit changes?
So this is a two step process. First is saving the changes via OASIS so that they update the repository source folder.
OASIS will listen for the Ctrl-S combo and as soon as your code or object is changed it exports it immediately. Each Ctrl-S is updating my local working copy, but these changes are not tracked individually. They do not get saved to the repository server until I do a Commit action. Normally I do this via OASIS directly.
I use Ctrl-S as often as possible. Any changes I make, I typically follow it up with a Ctrl-S which will Save the object and Export it. I do this while I’m coding in the VBE environment or in the Access window when I have forms, reports, and queries open in design view.
For committing, I usually almost always force a commit, even with unfinished code, at the end of the day OR when moving to a different platform. I usually work on my desktop, but sometimes I’m working on my laptop and I then will update my repository on my laptop and copy my desktop Access database down to work on it there. They are both setup with working copies of the same repository.
Other than daily, I of course commit after testing and prior to a release. To me, it’s important to commit pretty often so that I have points to revert back to. Each commit can be restored and then I can import those objects back into Access to reset my database to a prior version. This makes things much easier and takes some of the worry out of making mistakes, although it’s not a simple process to restart from a prior version. It’s easy to get there, but you can’t erase the future revisions, so you have to start a new point of development by branching and then you have to update all your working copies to the new branch.
What about tables and data in the tables?
Let’s set aside SQL Server and linked tables for now and just discuss Access tables that are stored directly in the file.
OASIS can export table design and data separately. This is an option you have to select.
You can also choose which tables you want to save the data for. In my case I have temp tables which stay in the local database and get reloaded with appropriate data as needed by the app. It’s not data I want to save. For those temp tables I choose to save the structure, but not the data.
For other tables, for example, if the table is storing static data like the menu options for the database, I set those up to save the data as well as the structure.
In both of these cases I can use OASIS to import and export changes to design and/or data of local databases. If you have a local table that needs to have persistent data, say like the list of customer orders, I would recommend moving that to an external database or SQL server. It’s a benefit to separate your front end entirely from the customer back end data, although that is a completely different conversation.
Linked Access tables, ODBC tables, and/or SQL server database links and connections require a different approach. OASIS only will export their definitions although it can also export the data. Both of these change for me between installations for my dev work and the customer, so I just don’t export those. I manage a local configuration table that I use to reconnect the front end to the back ends it needs to talk to. Our product Access JumpStart has this ability built into it and it’s quite useful.
There are still some unanswered questions. I will continue this discussion in future articles and look at my process as it relates to design and data for remote databases.
- What about SQL Server back end databases?
- What about the data in the tables?