• Support
• FAQ
• Why Ivercy flags unmodified Access objects as modified

Ivercy flags Access objects as modified that weren't modified

It happens frequently that Access-Objects are marked as modified (either by Ivercy in Access or by your SCC-System in the local working folder) even though you are absolutely sure you did not change anything.

There are two possible reasons for that.

1. Added or changed properties in the definition of forms and reports

There are several properties/properties in the Access source code files that are managed automatically by Access and may be changed by Access without you doing anything.

Some of those properties are simple Name=Value pairs, while other contain a block of data, usually binary data in hexadecimal notation, that is enclosed in Begin/End tags.

The most notorious of those properties is the NoSaveCTIWhenDisabled property in the source files. No one knows what it actually does, but it is added by Access 2010 to each form or report that is exported with the SaveAsText method. Sometimes this property is added multiple times to the same file and Access itself fails to re-import that file with the LoadFromText method. Of course whenever one of those lines is added to the exported file, it is considered modified by your source code control system.

As far as our experience goes, most of those properties have little or no effect on the way your Access application works. So one way to deal with those distracting changes to the sources is to completely remove those properties from the source files.

Up to Ivercy version 1.0.8 it was possible to remove single lines of code with the (now deprecated) RemoveLinesRegexps-Option. Obviously that solved only part of the problem, as it did not deal with the data block properties.

With Ivercy Version 1.0.15 we introduced the more sophisticated SourceProcessingSettings, which let you configure lines or blocks of code that will be removed depending on the source file name of the Access object.

Here is a list of those problematic properties you might want to remove in your source files to avoid objects being flagged modified with irrelevant changes. Most of them are more or less undocumented. Their descriptions are mostly based on our own observation and the little, mostly unofficial, information that is out there on the internet. We cannot guarantee for its accuracy.

• NoSaveCTIWhenDisabled

  • Property type: Line

  • Description: It's undocumented and to my knowledge nobody ever figured out what it does. CTI is usually an abbreviation of Computer Telephony Integration. Still I have no Idea what that could mean in the context of an Access object.

    It's completely safe to remove this line.

• Checksum

  • Property type: Line

  • Description: In previous versions of Access (until Access 2002 or 2003) this checksum value was actually used by Access to verify the integrity of files that were loaded with the LoadFromText method. From Access 2007 onward this property has no noticeable effect anymore and it is safe to remove it completely.

    

• GUID

  • Property type: Block

  • Description: Hexadecimal identifiers for a form and each of its controls. To our knowledge this has no effect in desktop databases at all. It might be different with web databases.

    It is not changed as frequently by Access as most of the other settings, so it is not as much of nuisance. We did not notice any negative effect after removing those properties from the sources.

• NameMap

  • Property type: Block

  • Description: This property seems to be related to the Name AutoCorrect feature of Access. Even if do use this feature in Access, you will probably not want to store the Name AutoCorrect information in your source code control repository. So we assume it is safe to remove this data.

• PrtDevMode, PrtDevModeW, PrtDevNames and PrtDevNamesW and PrtMip

  • Property type(s): Block

  • Description: These properties are actually part of the Access Object Model and are documented in the Microsoft Access VBA reference. They contain the printer settings for a report or a form. The problem with them is, that they are frequently changing. Unless you configured a specific printer for a report or a form it will be printed on the default printer. The default printer might be another printer on different computers or you might event change the default printer or it's settings from time to time.

    These settings are totally useless for a form and can be safely removed, unless you explicitly configured the form for printing. (You can configure a SourceProcessingSetting to be applied to forms only.)

    For a report these properties can be pretty important of course. If you just print a report to the default printer without any changes to the page setup (paper size, paper source, orientation, etc.) you can delete these blocks. For any report where you changed any of these settings you want to keep the information.

    So if you need the report's PrtDevMode or PrtDevNames properties, there is no solutions to avoid those changes being flagged by Ivercy.

2. The VBA-Editor changes the capitalization of your variable and procedure names

The second reason for modified source code files is a rather annoying habit of the VBA-Editor. If you declare a variable with the same name but with different capitalization as you did before, Access will change the case everywhere to the last typed variant.

You can reproduce the issue by copying and pasting these two procedures into any VBA module.

Public Sub Test1()
	Dim someid As Long
End Sub

Public Sub Test2()
	Dim SOMEID As Long
End Sub

Pay attention to the lower respective upper case of the variable someid. After you pasted these two procedures into a VBA module in Access, both of the variables will be either upper or lower case.

See the result here:

And it is even worse. This behaviour is not limited to code in the same module, but the changes are applied globally to all your VBA code within the whole Access project. So whenever you use a variable or function name you used elsewhere in your VBA code before, the VBA Editor will change it in all files to the last used form of capitalization and thus changing any number of Access Objects within your database.

Ivercy then detects those changes and flags all those objects as modified.

To deal with this issue, we introduced the new option IgnoreCaseModifications with Ivercy Version 1.0.15. If you set this option to Yes Ivercy will ignore case completely when checking files for modifications. This will solve the false-positive change detections, but it will also let changes to capitalization in string constants go undetected.