Posts from December 2007.

CaseDetective 1.3.4 released

I’ll let the release notes tell the story…

Changes In CaseDetective 1.3.4

Released 2007-12-13

  • Bug Fix: Error while creating indexs on the Attachment, Cases or CaseEvents table.
  • In some rare cases CaseDetective could not create indexes on it’s cache database due to non-unique data in a primary key, this has now been fixed.
  • Bug Fix: The previous change (1.3.3) for the above bug fix introduced some database incompatibilities.
    • In order to fix the problem across all supported database types, CaseDetective now requires MySQL 5.0+ as opposed to MySQL 4.0+. MS Access and SQL Server 2000+ are still supported as usual.
  • Bug Fix: Mac OS X 10.5 (Leopard) compatibility.
    • Updated tools and some third party libraries for better Mac OS X 10.5 (Leopard) compatibility.
  • Bug Fix: Support FogBugz 6.0 for non-administrators.
    • CaseDetective now supports changes made to the FogBugz 6.0 database schema for permissions, non-administrators can now see their cases!
  • Bug Fix: Improved permissions adherence.
    • Some changes were made to better support permissions, summary filters now correctly miss projects etc that a user does not have permission to see in FogBugz (4, 5 & 6).

    PLEASE NOTE: This does not mean CaseDetective fully supports FogBugz 6.0, it just means you may be able to use the “classic” filters in FogBugz 6.0 with CaseDetective 1.3.x, you will not be able to use the new search based filters introduced with FogBugz 6.0. Full support for FogBugz 6.0 and it’s new search based filters will arrive in CaseDetective 2.0 and CaseDetective On Demand by early 2008.

    As always, CaseDetective 1.3.4 for FogBugz is available from the download page.

    Oops, CaseDetective 1.3.3 pulled, working on CaseDetective 1.3.4.

    Oops, turns out CaseDetective 1.3.3 wasn’t so good for all database types and versions, so I’ve pulled it.

    I’m working on CaseDetective 1.3.4, but it’s a little trickier than I thought due to what SQL syntax is and isn’t supported across different versions of Access, SQL Server and MySQL.

    It may take a couple of days to fully test an alternative way of fixing the bug that was supposed to have been taken care of by CaseDetective 1.3.3.

    Thank goodness I upload the website for each version to a brand new directory and switch a symbolic link from old to new. So to revert to 1.3.2 simply consisted of logging onto my web server and switching the symbolic link from new to old.

    CaseDetective 1.3.3 for FogBugz released.

    Dumm, dumm, dumm, another one bites the dust, clap clap!

    CaseDetective 1.3.3 has been released with just one iccle fix.

    In very rare conditions CaseDetective would fail to get either attachments, cases or case events due to a “duplicate values in unique index” error.

    There was a little bit of Cartesian (black) magic happening, now vanquished!

    If you’ve not had the problem then chances are you’ll not need this update, but if you do need it you can grab it from CaseDetective’s download page.

    Weight off my mind.

    Phew, last night I killed a bug in CaseDetective 2.0 in less than 30 minutes of development that had been bugging me (pun intended) for well over 4 weeks!

    And what’s more, 30 minutes later after re-activating another feature that I’d disabled because I had a bug in that code that had also been bugging me for well over 4 weeks was also fixed, without me making any further changes!

    I hate (love) it when that happens! :-)

    The annoying thing is, my code for the first feature is virtually the same as before last night’s edits, I’d almost got the bug fixed before in that I’d whittled it down to a very specific block of code that I could hard-code around to get the results I wanted, but couldn’t get the proper solution to work, even though it looked absolutely right. I worked and worked on the area, making sure I fully understood the all the properties and events of the classes involved, but alas the solution failed to reveal itself.

    Out of frustration I switched one parameter to a function that should have absolutely no effect from “true” to “false”, fully expecting that the problem still existed. It fixed the problem. Fantastic! But also very very annoying. I can only assume it’s either a very subtle bug in the framework, or more likely me not quite fully understanding the event interactions of a couple of classes.

    I tell you, it feels great to have fixed these two problems, they were two great weights stopping me from progressing in important areas of CaseDetective, and stopped me from being able to efficiently concentrate on my work.

    A great weight has been lifted off my shoulders, full steam ahead!