Ivercy has many options to adjust its behavior to your specific needs and preferences. This documentation chapter describes the purpose of the different configuration files and the configuration options.
There are several Ivercy configuration files. All of them contain the same settings but with a different purpose or scope.
Location: %programfiles%\ivercy\ivercy\Template_IvercyConfig.xml
The global configuration template is stored in the directory %programfiles%\ivercy\ivercy (%programfiles(x86)%\... on x64 operating systems). This file will be deployed by the ivercy setup and never changed during normal program execution. Whenever a user starts ivercy for the very first time on a particular computer, this file will be copied to the user’s %appdata%\ivercy directory and by this it will become the global configuration file for this user on this computer.
There is no user interface in Ivercy to edit the options in this template file.
Location: %appdata%\Ivercy\Ivercy\IvercyConfig.xml
The file %appdata%\Ivercy\Ivercy\IvercyConfig.xml stores the global defaults for the options settings for each user. To edit these settings go to the Backstage in Access, go to the Ivercy group and klick on Global Options. This file will be opened in the property dialog and configuration changes are saved to this file.
Whenever you create a local Access database from your source code control repository, or add a new, local database to your repository, the settings from this file will be copied to your project’s settings and stored in the project folder.
Location: X:\your\local\project\path\yourDbName_IvercyConfig.xml
These are the actual options that will be used by Ivercy during operation. As these options are stored individually for each project (each Access Database), you can adjust the options for each project in this file.
You can view/edit these options by clicking the Options button in the Ivercy Ribbon.
This chapter describes all the individual options
The default settings shown in this document are our recommendations for production use. Beta releases of Ivercy may have different default values preconfigured.
Possible values: Yes, No
Default value: Yes
Description: If set to Yes Ivercy allows you, to include new objects in the change set whenever you check in your work. If there are new and existing, modified objects within the change, set you don’t need to bother with two consecutive similar operations. Ivercy will handle that for you. But be aware that there still will be two independent transactions submitted to your source code control system for the change set to be checked-in.
Possible values: Yes, No, Ask
Default value: Yes
Description: If set to Yes, Ivercy will automatically check out the files that are affected by a merge (the merge result), if No these files will remain checked in. With the option ask you will have to decide each time.
Possible values: Yes, No, Ask
Default value: Ask
Description: If set to Yes, Ivercy will automatically check out the files that are opened in design view in Access, if No these files will remain checked in.
Possible values: Yes, No
Default value: Yes
Description: If set to Yes a check-in-comment is mandatory when you check in changes.
Possible values: any string (needs to be a valid regular expression)
Default value: (none/empty)
Description: You can enter a regular expression here. The check-in-comment has to match this regular expression.
You can use this to enforce more meaningful check-in-comments.
Example: Task.\d{4,}
This will require each check-in-comment to contain the word “Task” followed by at least a four digit number to create a cross reference to bug/task-tracking-application.
Possible values: Yes, No
Default value: Yes
Description: If Yes you will have to confirm each undo-checkout operation. – Yes is recommend, as undo-checkout will by definition discard your local changes.
Possible values: Yes, No
Description: Some source code control systems will sometimes not recognize that your local version is less recent than the version in the repository. This is particularly annoying if you want to get the latest version of an object and your source code control system just does not get it.
To deal with this situation Ivercy uses a crude but effective hack. If this option is set to Yes, Ivercy will delete the local file(s) you want to get the latest version of. This forces the source code control system to really get the latest version.
Possible values: Yes, No, Ask
Description: If Yes, Ivercy will automatically get the latest version of an object before it is checked out. – See ForceGetLatest as well!
Possible values: numeric, integer, positive only
Default value: 14
Description: Ivercy keeps a backup of every file it deletes (e.g. by ForceGetLatest). The file will be kept for the number of days you enter here. The value 0 disables the backup!
Possible values: Yes, No
Default value: Yes
Description: Sometimes Access modifies the case of your variable and function names in code. As VBA is case-insensitive this does not have any effect on the way the code works. But Ivercy will still detect changes to the code. – We recommend our FAQ article on automatic capitalization changes in VBA to fully understand the issue.
If you set this option to Yes, Ivercy will ignore changes to the VBA code in your Access objects that only changed the case of text. Keep in mind that changes to string constants will go undetected then as well. These changes might very well be relevant and affect the behaviour of your application.
Possible values: Yes, No
Description: If set to Yes Ivercy will start your diff/merge conflict viewer utility whenever a conflict is detected. If set to No Ivercy will only warn if conflicts are detected and ask you to confirm proceeding with a possible loss of changes.
This option will be effective if UseLocalChangeTracking is set to Yes only.
This options is deprecated and has been replaced by the SourceProcessingSettings option with Ivercy version 1.0.15 and later.
Possible values: List of Strings
Default value: NoSaveCTIWhenDisabled =1
Description: Sometimes Access is adding stuff to the Form- and Report-Files, that does not make sense and you rather want it removed (e.g. the NoSaveCTIWhenDisabled-Property added by Access 2010). This configuration option allows you to enter regular expressions (one per line) that will trigger removing matching lines in the source files. Be careful with this. If a line in the code file matches a regular expression entered here, the complete line will be removed.
Possible values: Yes, No
Default value: No
Description: If Yes, shows the Ivercy Object List with the textual representations of the current SCC-Status after you refresh the status.
Possible values: Numeric, Integer
Default value: 3
Description: Ivercy has an output window to display informational output provided by the source code control provider or about its own operations. This window will show automatically for the number of seconds entered in this option.
If you want to disable the Output Window, set this Value to 0.
Possible values: Numeric, Integer, positive only
Default value: 5 (or 10, depending on version)
Description: StatusRequeryInterval determines in which intervals Ivercy updates the SCC-Status of the Access objects. The value is the update interval in minutes. This is the time it might take at longest until you see status changes by some else.
If you want to disable automatic status updates, set this Value to 0.
New in version 1.0.15 of Ivercy.
Description: Access maintains some of the attributes/properties in the source files on its own. Many of these properties and their modifications are irrelevant to how your application works, but they are still detected as changes by Ivercy and result in the affected objects being flagged as modified. You may read the full description of the issue in our FAQ on objects wrongly flagged as modified.
Ivercy processes each source file before it is imported into Access and after it has been exported to the file system. With the SourceProcessingSettings you can define lines or blocks of code (including form/report definitions) that Ivercy removes during the processing. That results in those files not being detected as modified. So you will not be distracted by those irrelevant changes and you source code history will not be clogged with revisions that do not have any effect.
Please understand that using these settings will instruct Ivercy to actually modify your source files when getting the latest version from the repository or checking-in a new version of a file.
So if you add or edit the SourceProcessingSettings it will cause files to be marked as modified. You need to check-out all affected files once and check them back in again.
All members of your team should use the same SourceProcessingSettings configuration.
The SourceProcessingSettings are actually a collection of settings. Each item in the collection has these properties.
Name – Informational only. Write anything that helps you to identify the item in the list of settings.
Action – Possible values either Line_Remove or Block_Remove. This defines if the processing will be applied to a line or a block in the code.
Here is a sample of a single line property:
And here is a sample of a binary block property:
ForFileRegexp – This is a regular expression that the processed source file name must match for the removal to be applied. You can easily distinguish between forms and reports by their file extension .ACF and .ACR. Yet any pattern can be used to be matched against the file name. This way you can define settings that are only applied to some of your source files.
SourceMatchRegexps – This is a regular expression that will be compared to the actual source code in the files. If a line or block (depending on the Action setting) matches this expression, it will be removed.
The SourceProcessingSettings rely on regular expressions. If you want to test/validate your regular expression before saving them (recommended!), you can use a regular expression test tool like the Online Regex Tester.
Possible values: Yes, No
Default value: Yes
Description: If set to Yes, Ivercy will work in local change tracking mode. It will not only track, display and manage the status information provided by the source code control system but will additionally track the modification status of the Access objects within Access. This is extremely useful as otherwise you might be missing out on changes you made to objects in Access that have not been exported to the file system. Furthermore Ivercy will try to ignore changes that have been made automatically by Access, but that usually will have no relevance for you.
It is not possible to enable this option for an existing project!
If you want to enable this for a project, you should turn this feature on in the global configuration (via the Access Backstage) and then (re)create the local database from your source code control repository.
You can disable this feature for an existing project, but you will not be able to switch it back on later without recreating the project as describe above.
This option comes with a performance penalty as it requires additional computations and disk operations. Still we think its advantages by far outweigh this performance hit, so we recommend having this turned on for all projects.
To take full advantage of this feature you should review/adjust your MergeProgram and MergeCommandline settings.
Possible values: ApplicationDataDir, TempDir
Default value: ApplicationDataDir
Description: This options configures the location of the Ivercy log file.
ApplicationDataDir is %appdata%\Ivercy\Ivercy
TempDir is %temp%
Possible values: None, Exception, Warning, Info, Debug
Default value: Warning
Description: This options controls how much information will be logged by Ivercy in its log file.
The more information is logged, the higher the performance penalty will be. For production use we recommend setting this to Warning.
Possible values: String
Default value: (none/empty)
Description: Command line, including parameters, for your local diff/merge-utility
See MergeProgram for more information.
Your diff/merge-utility needs to know, which files you want to compare and merge and where to put the result. Usually these file names are supplied to the utility via the command line. You do not need to worry about where the actual file paths will point to. Ivercy will take care of that. This option is only about building the proper command line for the merge utility.
Ivercy expects placeholders in the supplied command line to insert the actual file names in the right spots. These placeholders should be enclosed in angle brackets.
Supported placeholders:
accFile - The file your Access object is exported to. This is the local input file to the merge.
repoFile - The repository file that is the other input to the merge
baselineFile - The baseline file to the merge. Both input files will be compared to this file.
outputFile - This is the file, the merge result will be written to and that will be processed after the merge.
accTitle - Optional – The title for the Access object’s file
repoTitle - Optional – The title for repository file
outputTitle - Optional – The title for the output file
Example of a command line for Sourcegear DiffMerge:
-m "{accFile}" "{baselineFile}" "{repoFile}" /result="{outputFile}" /t1="{accTitle}" /t2="{outputTitle}" /t3="{repoTitle}"
Possible values: String
Default value: (none/empty)
Description: Path to your local Diff/Merge-utility
To get the most out of Local Change Tracking, Ivercy allows you to do some merge operations independently of your source code control system. For that you need to have an external Diff/Merge-utility installed on your computer and Ivercy needs to know which program you want to use.
Most source code control system will have a diff/merge utility included.
If you don’t have a diff/merge utility or rather would like to use another utility you could check out these tools:
Or have a look at our list of diff/merge-tools.
This configuration section is used to store the settings for the MSSCCI-Provider. It will be automatically written by Ivercy when you create a new project. In the template and global configuration this section should not contain values.
These values should not be edited manually. Therefore we include only a very brief description here.
UserName - Your user name to log in to the source code control repository. – Some provider manage identity externally, than this will be empty.
ProjectName - The project name in your source code control system
LocalProjPath – The local folder for this project
LocalProjWorkingDir - The local working folder for this project. This equals LocalProjPath with an appended “\yourDbName_ivercyTmp”.
AuxProjPath - The full path to address this project with you source code control provider
SccProviderLibrary – The library (.dll) implementing the MSSCCI-API for your source code control system
IgnoreTempFolderAtWorkingFolderPathEnd – Ivercy will not append it temp folder name, if a folder of that name is already at the end of the working folder path.