search

joyfullservice / msaccess-vcs-addin

Synchronize your Access Forms, Macros, Modules, Queries, Reports, and more with a version control system.
Other
211 stars 41 forks source link

TableDefs exported "fieldProperty name=Required" #216

Closed Tanarri closed 3 years ago

Tanarri commented 3 years ago

Hi,

on my PC in my company I exported a accdb and "Build from source" on another PC. All went fine. Then I exported the newly created once again and I thought there should be no changes in the exported files.

But all the local access-tables become a new field properties in the exported "tabledefs\.xml". An example from the well know "usysribbons.xml" grafik

Did I do something wrong? Or is this ok?

Info: The souce database is a very old one. It was created years ago, but it is regulary used on the source PC. Perhaps the database was created at a time were access didn't kow about the field property? Like in #215

joyfullservice commented 3 years ago

What you are seeing here is a change in how table definitions are exported. We are now able to support extended properties for the table and fields defined in the table. Going forward, you will now see additional data that is added and modified when you make changes to a table, such as change the width of a column. This is the expected behavior.

When building the database from source, all these additional properties will also be used, so the rebuilt database will have all the fine details like column widths already set in the new database. It will seem like more detail at first, but it is a benefit in that it creates the database from source even more precisely than it did in previous versions of the add-in.

Tanarri commented 3 years ago

This is a very useful extension, which I find good.

Nevertheless, I want to summarize and point out a possible problem: On my PC in the company, with the source/original database I ran VCS 3.3.31 and these new properties ("orientation", "requried") were not exported there. However, on my private PC (also VCS 3.3.31), on which I then used "Build from source", and then exported the database again, the properties ("orientation", "requried") were then exported.

So as long as I don't use "Build from Source" on my PC in the company, no properties ("orientation", "requried") are exported there furthermore. So it becomes difficult to use VCS with github/svn, because always this difference is seen as a change in the table.

For a new user who encounters this behavior, it can be a problem.

So for me, I will now do the following: In my company I will also use "Build from Source" once to import the properties into my database.

We can close this issue from my side, but should keep this case in mind when the git integration is programmed sometime.

joyfullservice commented 3 years ago

Thank you for the additional explanation on this. It is expected that Microsoft Access may add additional properties to objects when they are modified in certain ways. For example, if you change the column width for a table, and save the table, you will see a number of new properties added to the table. From that point on, those new properties will stay with the table design, and will be exported to the source files. Queries have a similar behavior. If you edit a query in the designer, it saves additional details with the source file.

My goal with this add-in is that two computers can work on the same database and export source code, and the source code should match if there are no differences in the actual database objects. If you build from source for the first time, you may see some slight differences, but if both computers are using the same set of source files, they should be producing the same output.

In your case you should either build from source (at least one time) at both locations, or build from source at one location, and copy the database file to the other system, and use that for ongoing development.

What I have been doing with my projects is slowly transitioning them to where I do not keep the .accdb file in version control at all. I just keep the source files in version control. When I want to do development work on the database, I build from source. This constructs the database entirely from the source files. Then as I make my changes, only the changed items are exported as source files and committed to the same repository. On the original computer, I can then make sure I have checked out the latest commits, then build from source and I am back to a fully functioning database that includes all the changes I made using the other computer.

To give a practical example, for this msaccess-vcs-integration project, I do development work both from my home computer, and from my work computer at the office. At both locations I have cloned the repository using GitHub Desktop, and I build from source anytime I have changes that were made on the other computer. It is also very easy to switch to a different branch, and build that version from source. The build from source functionality is what makes it possible to resolve changes and collaborate on the source code level.

At some point I am wanting to finish out the Merge functionality which will allow you to merge in just the changed items, instead of building the entire database from source each time. This will make the builds faster, especially on large and complex databases. It will also make it more efficient when multiple developers are working on the same system at the same time. I don't have a timeline for that yet, but it is the direction I am headed. 😄

Tanarri commented 3 years ago

Thank you very much for your detailed explanation. I will start my own "sync" workflow as you described and try to optimize it. As you said, a build from source will be the best to start development on another computer. I look forward to seeing a merge functionality in the future :-) and I really like your development and this project.