Some time back I made the conversion to iBank for keeping track of our finances. Then last year an update to iBank 4 came out. I grabbed it and started the update. For a blissful 30 seconds it all looked good and then came the dreaded error message.

The operation couldn’t be completed. The backslash is a wildcard char, and cannot appear unescaped at the end of a string.

So starting last October a number of posts were exchanged on the support forums. It ended not so well with this post. Asked to once again supply the data that had taken a fair bit of time to prepare the first time around. I was tired of the dance and just walked away. How hard can this be I wondered? Being a database guy it seemed pretty obvious that this was a problem with a '\' being at the end of a string and not being escaped.

Fortunately for our purposes iBank data files aren't encrypted. Since the data is readily accessible the only thing left is to look at the data. Enter Navicat for sqlite. Navicat is a great tool that has paid for itself many times over. In the last couple of years they've added versions for several other databases including sqlite.

Downloading the full trial version of Navicat for sqlite was the first step. With that in hand it comes time to locate the iBank data file. For our example it is in:

In this case we'll setup a connection in Navicat to access the data. The full path to the sqlite file will be a little different and will look like:

The reason you need the full demo version of Navicat is to take advantage of filtering. Opening up tables there seem to be a few we should be interested in. The most likely suspects in my case looked like:

• ZSMARTFILL
• ZTRANSACTION

Going to each of these and looking for memo/title sorts of fields I applied a filter to each for the '\' character. Sure enough there were a handful of transactions -- automated payroll transactions -- that ended with a '\'. Editing each of the dozen rows to remove these backslash characters and then closing Navicat updates the data file.

Going back to iBank 4 and running the update this time worked like a charm. So I'll reluctantly be plunking down cash for the upgrade. Why reluctantly? Well frankly it's a bit disconcerting that such an error could take months to get resolved. Even so it's resolved not because the developer took an interest in getting it fixed but because I got tired of waiting for the obvious to be tried. Someday with a little luck we'll have a really good personal/family accounting system available which isn't stuck in 1980's models and understands that there are multiple people using such systems... but that's another topic for another day.