New Ivercy version 1.2.2

In the recent newsletter for version 1.2 I wrote: “we are planning to go back to more frequent, smaller releases”. When I wrote that, I had no idea how soon the next release would emerge.

It’s actually out now! – Just two weeks later.

We deliberately dropped some minor features from the last release due to time constraints. I didn’t want to defer that long overdue release any further. Still, I wanted to roll out those additions as soon as possible.

Additionally, there was a bug reported for v1.2 that was pretty annoying – though not critical.

These facts added up, made a compelling reason to release another version of Ivercy so soon.

Enhancements to the Object List Dialog

The main improvement in this new version is several small enhancements to the Object List dialog.

I was working on-site at a customer this week. Due to administrative constraints, he had the newest version not installed yet. Working with the previous version of Ivercy, I dearly missed the new status filter options in that dialog. – So, these changes might be only small, but they are incredibly helpful.

Status filter options

We removed some of the status filter items from the drop down that were not particularly useful und probably confused some of you more than they helped anyone.

The status filter values Modified (Local-SCC) and Modified (Local-Access only) were merged into the general Modified (Local) value.

Finally, we added the new, virtual status “New in repository” which is very helpful if you want to get new objects from the repository, which were added by someone else working on the project.

If you actually want to continue to use the more fine-grained old status filter options, you can set the UseSimplifiedSccStatusFilter-option to Yes.

Selected and problematic object counts

The Object List dialog shows the count of selected objects and the exact count of problematic objects with possible conflicts between the local and the repository version.

Differences Button

The Differences button in the Object List is now active and working. It enables you to invoke your Diff-Tool right from that dialog for the currently selected object. This is very handy if you want to take a quick look at the differences between two versions before deciding how to retrieve the latest version.

Support for integration into Japanese localized Access

This new version finally supports integration into the Japanese localized version of Microsoft Access. This was requested by several of you. Unfortunately, general support for a Japanese language environment is still not really there due to limitations in the MSSCCI-API-Definitions.

Bug fix – Create AccDE/MDE

When creating an AccDE/MDE from a controlled database with Ivercy 1.2 you would get an error message saying “The expression you entered refers to an object that is closed or doesn’t exist.”. – This error does not do any harm; everything still works as intended. But it is very annoying if you frequently create an AccDE/MDE from your project.

This error is fixed in the current release.

Improved error handling and logging

When Ivercy was exporting or importing the objects from Access some of you experienced error messages like “The search key was not found in any record” or “No current record”.

These error messages are caused by Access itself failing to import or export the object. The cause is most certainly some sort of corruption that object. We are still investigating these issues and will publish an FAQ article on this topic as soon as we know how to solve these issues.

In this new version of Ivercy, the error messages regarding such issues will display the Access object name that caused this error. – This should at least help to get to bottom of the issues.

Conclusion

Let’s wrap this up here. These are all rather small changes, but they are so useful that I absolutely recommend to download and upgrade to this new version!

Most Ivercy user do use Team Foundation Server version control as backend. This week we added some additional documentation on this combination.

Issues with TFS workspaces

The most frequent issues with Ivercy and TFS are related to messed-up folder mappings in the TFS workspace configuration. So we added an FAQ article explaining the cause of the issues and how to avoid trouble with TFS workspaces.

Rollback Changeset in TFS

I felt in the mood to record a video. A recent question on how to rollback changes on TFS is a topic than lends very well to be explained in a video.

I thought of it more as an experiment to do videos that are not limited to plain screen recordings but are enhanced with a bit of video footage of myself explaining the key points of the issue. So that’s what I tried to do.

I’m pretty pleased with resulting video so I published it on YouTube. You can watch how to rollback a changeset in TFS version control on YouTube or just start the embedded video below.

If you like this form of informational videos leave a comment or click the “Thumbs up” on YouTube.

Note: Japanese is the most relevant Asian language for us, as we had multiple request from developers in Japan, who would like to use Ivercy, but can’t for the reasons described in this post. So I frequently refer to Japanese in this post, but the issues are the same for any Asian language!

The last couple of days I struggled with supporting the Japanese Language in Ivercy. Today I have to admit defeat. - And I’m not doing this lightly.

There are two problems with using Ivercy in a Japanese language environment. As you probably are a software developer yourself and maybe interested in that, I’m going to describe the issue with quite a bit of technical detail. If you are not interested in that kind of detail, skip right to the bottom line.

The UI-Problem

The integration into Access is partially dependent on the UI-Language selected in Office. So Ivercy needs to know and understand the Japanese terms for Query (???), Form (????), Report (????) and so on. This is required for the UI-Integration into the Navigation Pane.

Access and the .net Framework, which Ivercy is implemented in, use Unicode Strings. So any character set can be represented in a simple string. So, this first issue can (and is) solved by simply adding a translation table between the Japanese terms and their English counterparts. This solves the UI-Integration issue and will be included in the next release of Ivercy (version 1.2.+x) and will be available soon.

The MSSCCI-API- Problem

The second issue with supporting Japanese is the MSSCCI-API. Unlike any Win32-API, the MSSCCI-API has no Unicode (…W) declaration/implementation of its functions. The functions are only available in an ANSI implementation, which uses the LPCSTR-Type or an array of LPCSTRs for character data.

Codepages and character encoding

With Western languages that can be represented by the Windows Codepage CP1252, it is fairly easy to pass data to the functions of the API. You simply declare the LPCSTR parameters as Strings and you are good to go. The .net runtime will sort out the marshalling of the data automatically.

Now, if you have got a file name (derived from an object name in Access) that consists of Japanese Characters, it will be automatically mapped using Codepage 1252. The result will be something like this: “????????????????”. - The question mark replaces any character that cannot be properly mapped. As CP1252 was never intended to represent Asian Characters, none of them can be mapped and the resulting data is completely unusable.

Now, the .net Framework supports all Windows Character Encodings, so it is possible to convert the Strings using the appropriate Codepage for Japanese (CP932). The result is a byte-array containing the string’s representation in the correct Codepage. – So far, so good.

Marshalling in the .net runtime

The conversion to the correct Codepage leaves us with an array of bytes that represent the Japanese character string

Now, for simple LPCSTR parameters it is pretty straight forward to implement. You would use an Byte() type in the declaration of the function and just pass our array of property encoded bytes to that. – Done.

Unfortunately, it is not that simple. Most of the functions in the MSSCCI-API do not use just simple LPCSTRs, but arrays of LPCSTRs. They would translate to an array of byte-arrays in our declaration – Byte()().

Other than a String or a simple byte array, the .net runtime cannot automatically marshal nested /jagged arrays. It should be possible to write a CustomMarshaler that would handle the marshalling of these types. There are actually some samples around on the internet. But I spend quite a bit of time trying to implement a CustomMarshaler for our jagged byte arras in Ivercy and simply could not get it to work. :-(

As I’m the developer with the most experience on WinApi and P/Invoke on our team, this is a pretty disappointing result.

Bottom line

You can use Ivercy in a Japanese edition of Microsoft Access and the icons and integration will work with the next version of Ivercy after 1.2.

But, you can only and strictly use plain English (western) characters in your object names in Access. As soon as there is any object in your Access database that contains a Japanese (or any Asian) Character, there will be exceptions all over the place and it will not be possible to work with Ivercy in that database.

We’re truly sorry about that. We might come back to this topic and try to address and fix the issues at a later time.

If you are an expert with Interop and P/Invoke in the .net environment and think you are able and willing to help with this, please get in touch. And we don’t expect your help for free.

I’m glad I can finally begin to write this. It has been 6 months since the last (public) release of Ivercy. That is a long time. Much too long.

While we never really stopped to work on Ivercy, for a multitude of reasons, we never made it all the way to a public release. - Until now.

During the last couple of weeks, we got several inquiries, if Ivercy is still actively developed. Yes, it is! And here’s the proof. – However, if you were waiting for some of the functional enhancements we have got planned, you might still be a bit disappointed.

Infrastructure

The overbearing topic of this release is infrastructure.

(Photo byGreg Rakozy, used here under CC0 licensing)

Soon after the last public release of Ivercy, back in April, we were getting more and more requests for things like supporting Access 64 bit, the .net Framework 4.0 and improvement of the installation options and experience in a restrictive corporate environment.

While the necessary changes to Ivercy itself were not that difficult to implement, and in fact are available via non-public releases to some of our customers for some time, the overall experience was ruined by the shortcomings of our installer. To overcome these limitations was one of the key issues holding this release back for so long.

.net Framework 4 support

Ivercy is built against the .net Framework 2.0, which was the basis of everything .net out there for quite a while. With Windows 10 (and 8) by default only the newer .net Framework 4.0 is installed. On these operating systems, you had to explicitly add the 2.0 Framework to use Ivercy.

This new release is still built against the .net Fx 2.0, but it works with the .net Fx 4.0 as well. During installation, our setup will detect whether you have got 2.0 or 4.0 installed and will configure Ivercy accordingly.

Ivercy itself work flawlessly with .net 4.0, but during our testing we discovered that some 3rd party components do not. For example, the MSSCCI-Provider for older versions of Sourcegear Vault will crash instantly if invoked from .net 4.0. For that reason, we play it safe. If both versions of the .net Fx are present, version 2.0 will take precedence.

Microsoft Access 64 Bit Support

I was surprised that we got quite a few requests to support Access x64. So we enhanced Ivercy to accommodate this requirement. Thanks to the .net Framework we were able to make Ivercy dual platform instead of building two separate versions of Ivercy. There is just one binary assembly running on both platforms. Only one small satellite component is actually platform dependent, so we deploy two versions of that and load the correct one at runtime.

Once again the installer makes things more difficult than necessary. An MSI-Package can either be compiled for 32bit or for 64bit, but not both. Considering that more than 95% of our users only need 32bit support, we do not provide a dedicated 64bit installer (yet).

If you want to use Ivercy in Access 64 bit, just install the 32bit version. After installation please run the batch script Ivercy_install_registry_x64.cmd in the folder Ivercy was installed in. This will enable Ivercy in the 64bit version of Access.

Before you get too excited about using 64Bit-Access, please remember: Ivercy requires an MSSCCI-Provider for your source code control system. This provider needs to be available for 64Bit as well! Most vendors of source code control systems do not offer a 64Bit-Provider yet.

Of the primarily supported SCC-Systems only Microsoft has got a 64bit-MSSCCI-Provider for TFS.

Improved Setup/Installer

We originally used a Visual Studio Installer project to create the MSI-Setup for Ivercy. That was a very simple solution that worked. – Sort of.

While it was easy to implement, it had lots of drawbacks. To name just two:

• The setup required administrative permissions.
• It would only work for the user actually running the setup.

These two combined were a major a nuisance, as each user that should have Ivercy available, would need administrator permissions during setup (at least temporary).

To get rid of these nuisances, we built an all new installer package for Ivercy. It will run with user permissions only, but still can be optionally run with admin permissions to install for all users on a shared computer or terminal server environment.

There will be more detailed documentation dedicated to sysadmins available soon. If you just want to install Ivercy for yourself on your computer, choose the “per user” installation and you are good to go.

Important bug fix for Get Latest Version

The new version does include several bug fixes. While I would consider most of the bugs fairly minor, there was one actually that was nasty.

I hate to lose work already done! So I am profoundly sorry that some of you experienced exactly this due to a misbehavior of Ivercy. – My apologies!

There were two situations where this could happen.

If you checked out an Access Object, which was already modified locally before checkout, and you activated the “Get Latest Version”-option in the checkout dialog, then Ivercy did not warn you about losing your local changes.

If you explicitly invoked the “Get Latest Version” command, it was possible to select Access Objects that were already checked out (and potentially modified) for the Get-Latest-Operation. If you continued any local changes were overwritten.

Both incarnations of this bug are fixed in the new version.

First and foremost, Ivercy now displays a highlighted warning message, if you are about to overwrite local changes with the repository version of an object.

Second, you can configure Ivercy to always exclude objects that are already checked out from the Get-Latest-Command. Use the ExcludeCheckedoutFromGetLatest-Option to control this behavior. Please be aware that this is enabled by default!

Other features

There are some other improvements, such as further reduced startup time, clarified configuration dialog showing the current configuration, the template configuration and global options (new) in a single tabbed form. As well as several other bug fixes.

So go to our download page and “check out” the new version and let me know what you think. – We appreciate any feedback!

Last weekend I pretty spontaneously decided to attend the Access Developers Conference (Access Entwickler Konferenz - AEK) in Düsseldorf, Germany.

I really enjoyed meeting and talking to all the other attendants. It is always nice to meet so many people in person I otherwise only interact with via email. Some of our customers were there as well, so I gathered some valuable feedback on Ivercy.

This year I haven’t had the time to commit to a full talk on the conferences main track. Still, I managed to hastily prepare a short talk for the more informal and much shorter evening sessions of the conference (AEK-Abend).

I did a short (11 Minutes) presentation on Branching and Merging with source code control to release bug fixes during longer development cycles. Just slides and theory, no demo. I recorded my presentation on video. You can watch it here; it is in German though!

The slides are available for download in PDF-Format as well.

If you are spontaneous and located in central Europe you can still register for the last AEK19 conference event for this year in Hannover, Germany on Oct. 15th/16th 2016.