Archive for July, 2012

IBConsole makes using ISQL tempting

Saturday, July 14th, 2012

I have been using Firebird for small projects for sometime now and FlameRobin for my GUI admin tool.  The combination has worked well for me, until I wanted to write a XPlatform appplication in Firemonkey and I had problems getting FlameRobin running on the Mac.  After viewing Stephen Ball’s webinar, I tried getting Interbase running on both platforms, and did so with some minor difficulty.

Today I was making some modifications to the structure of the database, adding a FK column to a table in addition to the lookup table.  The data showed in IBConsole as 0s for the ForeignKey, yet very time I tried updating a different column in the same table I received an error message that the Category_ID column had failed validation **null**.  Eventually I figured out there was no row in the Category lookup table, but inserting a row with an ID of 0 didn’t fix the problem.  I had to issue an update and set the Category_ID column to 0 even though the UI already showed it populated with 0s.

There are lots of such annoying issues in IBConsole v10.0.3.563.  When adding columns the controls for different edits show grey borders, and the Not Null checkbox appears as if it’s greyed out, even though it’s still enabled.

I’ve never liked the multi-window UI, and it seems to have become more cumbersome as features have been added.

It must undergo thorough QA testing since in the Constraints tab the control name is still displayed ;-)

Although tempted to start using the command line tools, I will continue with iBConsole for now, and hope it gets better with time…

Delphi Needs a Spring Cleaning

Wednesday, July 4th, 2012

If you’ve maintained a piece of software for any length of time, then surely you know that at some point decisions made in the past are no longer valid, or maybe have proven to be poor decisions over time, and you need to do some cleanup.

Delphi has been around long enough that it is showing signs that a cleanup is required.  One example is all the duplication of project and build settings between the DPROJ and DPK files.  A clear violation of the DRY principle.

Then there are new features, or changes implemented without considering the results.  I think Uwe would agree that the change of the Find dialog to a toolbar and the subsequent breakage of pretty basic functionality that also drives me nuts is a pretty good example.  I could also site changes to Ctrl+C code completion that I have QCed, but remains broken in XE2 (maybe they will fix it in XE3?).

Storing the currently selected target and project configuration in the DPROJ results in developers constantly being prompted ‘Do you want to save your changes?’.  Since there is no indication what actually changed, the safe answer is always ‘Yes’.  Then when you go to check in your source code, you’re either checking in redundant information all the time, or you have to scrutinize the differences to determine it was just the selected configuration and/or platform that changed.  Keeping user selections in a versioned file is simply a bad design because it’s lousy for team development.  If I decide to compile a project for Win64 to target Windows 7, but my colleague is working on the same project under Windows XP 32 bit, and checks out my update he has to contend with all my setting changes just to be able to recompile.

Makes you wonder if any dogfooding is being done in California these days….

Taking the Right Path

Tuesday, July 3rd, 2012

I thought I would share some additional information on Path issues that I discovered while migrating my current project to XE2, and making it compile for both Win32 & Win64.

If you decide to change the default Win32 DCP and BPL Paths to include the $(Platform) environment variable, be sure to change the the default DCP path in the Library search path to also include the $(Platform) variable, or when compiling interdependent packages you will get an error that Delphi cannot find package XXX.

Also make sure you have Delphi Update 4 installed.  There appears to be some bug fixes around environment variable handling.  Prior to Update 4 the above changes would result in a directory called %Platform% being created for the DCP and BPL output folders, and any presence of $(Platform)\$(Config) would be changed to %Platform%\%Config% which of course doesn’t work.