Placeholders in export files

[juergen-bullinger]

Hi,

first I'd like to thank you for making this tool available to the public. I think in our project, we can benefit from it.

I have some question, which is related to this ticket: Possibility to export all Access databases to a subfolder #139

I think it is a great idea to support placeholders. In my current project we use the convention, that the file names for the access databases contain a version reference already and we would now like to use your plugin. But I guess because of the version reference in the file name (like in ISP_Kartentool_V025.accdb), we would run into problems with git if we use the predefined %dbName%). So we would rather like to unstrip the version info from the file name, or use properties of the database settings dialog as placeholders. I mean the properties defined here:

I know, that we probably also could configure the target directory of the source for each database individually, but I guess that would mean, that all developers would have to put the checked out git source under the same absolute path on their machines, right?

Kind regards & thank you in advance Jürgen

[hecon5]

We ran into similar issues. We instead use a database property with the version name and tags in git; then we keep all the "versions" in a linear history in git, and end users know what version they're using.

[joyfullservice]

I know, that we probably also could configure the target directory of the source for each database individually, but I guess that would mean, that all developers would have to put the checked out git source under the same absolute path on their machines, right?

The export path is saved as a relative path (when possible) so you can do something like this:

This works in the current version of the add-in, and allows you to build from source into the original file name. (It uses a relative path, so the developers don't have to have the same full path on their machines.)

The difficulty would be if you were trying to export multiple file versions into the same source folder. Then if you build from source, you might have problems building to the correct version.

As @hecon5 alluded to, I would recommend seriously considering adjusting your file naming to not include the version number. Since git history is based on file names, it is designed to operate with source files having consistent names throughout development iterations. It will be a little bit of adjustment initially, but I think you will be glad in the long run to work with the toolset instead of around it. 😉 I used to include version numbers in the file names as well, but it works so much more smoothly and seamlessly in version control to keep the name consistent and use branches and tags in git as well as custom database properties to store the version number.

Hope that helps!!

[juergen-bullinger]

Hi Adam and Hecon, for

thank you for your answers. You don't have to convince me about file naming. I didn't introduce this and what I try to do is just to make the use of a real version control as simple as possible for my colleague, who is used to copying database files of several hundred MBs size to create "versions". That's the idea behind it.

Btw. what does relative path mean in that respect? is it always relative to the directory where the .accdb file sits as your screenshot suggests?

Kind regards Jürgen

[joyfullservice]

Btw. what does relative path mean in that respect? is it always relative to the directory where the .accdb file sits as your screenshot suggests?

Yes, relative in reference to the path of the .accdb database file. The simplest and recommended approach is to place your source files in a subfolder of the database location. It can work in other scenarios, but I find this to be the simplest and most portable approach for version control. (I also highly recommend each developer working on their own local copy of the database and source files on their own computer, not trying to use version control on a network share.)

In regard to the file naming, one approach might be to have a non-versioned name that you introduce for the purpose of version control, and let your colleague copy out the database file and add the version to the name when he deploys it. Eventually he may recognize that this additional step may not be needed... 😄

[juergen-bullinger]

Thank you for your advices. Just to make sure, in terms of GIT you would just suggest to use a local clone of the GIT repo, or would you even not recommend the usage of a central GIT repo? and if so, why?

We would work on local checkouts of the central GIT repo. But in our case up to now there is only one person working on it (one pushing changes and one other who at the beginning will only pull the source for read access).

At the beginning we would probably only extract the sources into the local git repository (my colleague, who programs in Access) and push it to the central library and maybe later also use the build functionality, but at first probably we do not need it unless there is a very good external code editor that adds functionality to the build in IDE capabiities of Access. Are you by chance aware of such a thing?

[joyfullservice]

Yes, I recommend a local clone of the GIT repro. The repro can be shared by multiple developers where each developer checks out their own copy to their local computer for development or review. The scenario you want to avoid is when someone checks out a GIT repro to a shared network location, and multiple people work in the shared checkout. That's where it can get really messy.

The build functionality in the add-in is what allows you to work on two different parts of the database at the same time, pull in the source file changes, and build an updated version that includes changes from both developers. We also exclude the binary accdb file from GIT so the collection of source files becomes THE source of truth for the database project. It is a bit of a mentality shift, but it is so much easier to maintain long term once you get used to it. It helps you move away from the black box of not knowing what might be different to the confidence that you can build from source files to construct the database at any point in the development workflow.

As to the IDE, I currently do most of my development in the VBA editor, although I am starting to experiment with using Visual Studio Code and the free Codeium plugin for AI augmented development. With the latest version of the Access VCS add-in, you can merge from source files, which allows you to make changes to VBA .cls files in VSCode, and easily merge those changes back into the active database project. You can work in both environments, you just need to make sure you are exporting and merging appropriately so you don't overwrite any work.

In the VBA IDE, I use the last free version of MZ-Tools, and love it. The latest version is no longer free, and not quite as light-weight. It may be well worth the investment if you do a lot of development work. I have tried RubberDuck a few times over the years, but it quickly bogs down in big projects and slows down the IDE.

[juergen-bullinger]

Hi Adam,

thank you for your suggestions. Without any doubt your tool makes development with Access much more professional. We will check out MZ-Tools.

I also would never recommend to checkout git repos on a shared folder so developers share it to perform their changes. This way you probably won't see any "collisions" between changes which usally pop up in merge conflicts. They are painfull indeed, but trying to supress them like this would just hide the problem so it probably pops up much later (maybe in production). And besides that, it also makes it much harder to attribute changes to the original developers and to the original requirements. Especially if a change spans several source files (e.g. queries and VB modules at the same time).