Diff after build from source (v4.0.34)

[IamMille]

Hi, just wanted to verify one thing.

We have a pretty old project running. So building from source is obviously a big thing and a lot of old stuff is possibly still in the file, even from upgrading between Access/Office versions.

I'm getting diffs in basically all my queries, it looks like this;

On basically all forms I'm getting this;

I'm mostly asking since they are removed, not added defaults (like papersize). Is everything in order?

[joyfullservice]

Great questions! These are two different things, so let me comment on them individually.

Regarding the queries, I would just verify that the resulting query has the same (correct) column names. Assuming you are outputting the SQL for queries, you could diff the *.sql files as a quick way to verify that. If the column names are correct, you should be good to go. If not, let me know an we can look into that further.

Regarding the color changes in form controls, I sometimes see this in databases that have been upgraded from older versions of Access. In some cases the color information is incomplete in the exported source file due to some missing information in the form definition. The good news is that I have seen this before, and we actually have a built-in utility to repair the color definitions!

On a copy of the original database (before the rebuild), run the utility to Repair Colors, and see if this fixes the issue. (It is normal to see some source changes on the first build from source, but you generally shouldn't be losing color information.)

After building from source, you can review some of the actual forms and ensure that the colors look correct in the freshly built database. Typically, once you resolve any color issues, you should be good to go, and not have to do anything special in the future. There is an extended discussion on colors, sanitize levels, and color block definitions in #183.

It looks like I need to add a page to the wiki to provide some documentation for the Advanced Tools utilities... I will try to do that sometime when I have a chance.

Hope that helps!

[IamMille]

@joyfullservice Thank you for taking the time to explain everything in great detail. I noted a couple of more things, but they are probably more of an Access/VBA issue, but affects the version control.

If you do a "compile" in the VBA editor, there are quite some things that changes;

Form placements(?):

Code letter case of variables:

SQL query - order in query string (!!!):

... so it seems very important to not forget to "compile" before exporting everything.

Is there a way for this VCS add-in to force a "compile" automatically (which ultimately also checks for errors) before exporting, to minimize this kind of behavior?

[joyfullservice]

@joyfullservice Thank you for taking the time to explain everything in great detail. I noted a couple of more things, but they are probably more of an Access/VBA issue, but affects the version control.

If you do a "compile" in the VBA editor, there are quite some things that changes;

Form placements(?):

This is usually due to differences in window position or monitor sizes. If you run the export with the Access window maximized on the same monitor each time, you shouldn't see as many changes to these layout properties.

Code letter case of variables:

This has more to do with coding convention and style. Mike Wolfe has a great article on this.

SQL query - order in query string (!!!):

A change like this in the query is most likely due to Microsoft Access "compiling" the query. If you always edit the query the same way, (either the visual designer, or the raw SQL view) these changes should settle down to a consistent output. I have seen slight changes like that, but typically it is just one time. They don't flip back and forth between builds.

... so it seems very important to not forget to "compile" before exporting everything.

I frequently compile the project during my development work, so I haven't seen this to be an issue in my projects. (I like to make sure the code can compile before making a commit to the git repository.) It is also a good idea to save your work before exporting.

Is there a way for this VCS add-in to force a "compile" automatically (which ultimately also checks for errors) before exporting, to minimize this kind of behavior?

Yes, there is a way to do that, utilizing the BeforeExport() hook, but this may not really be necessary after implementing the suggestions above.

It is not uncommon to have a few things that adjust after building from source for the first time, but in my experience, the additional "noise" (extra changes) are pretty minimal after that.

[hecon5]

Since it appears this is related to the noise caused by upgrading to the new export tools, and not a bug, should this be closed?