The world of Henry Orient

Sometime around 1970/1, the BBC ran a series of Peter Sellers' films. Amongst those shown was a delightful number called 'The world of Henry Orient', in which Sellers plays a classical pianist who is better at being a lothario than playing the piano. As far as I was concerned, the focus of the film wasn't Sellers, but rather two girls on the edge of adolescence. I only remember all this because a few months later I wrote a poem which hints at this film. I tried looking for the poem yesterday - not because it was any good, but because it would give me a date - but couldn't find the folder in which it was stored.  [see end of post]

Fast forward nearly 40 years. The MGM movie channel showed TWOHO a few weeks ago, and I eagerly recorded it onto DVD. When watching it, I was instantly charmed by the film's youth, but discovered to my dismay that the physical media on which I had recorded the film couldn't keep up with the pace, and so it stuttered. Too often. So much so that in the end, I couldn't watch the film. It seems that the first 20 or so DVDs in the pack were ok, but then the quality went down, as a few other films which I recorded suffered the same fate. I have since bought better quality DVDs (or at least, more expensive ones) and am saving the cheaper ones for digital copies only.

TWOHO was screened again yesterday, and this time I made sure that I recorded it onto a good disc. One more technical gripe before I write about the film: the television set displayed the film with a strange aspect ratio, which ignored the bottom 10% of the picture, and sometimes caused faces to appear distorted. Fortunately, the DVD recorded the film with a better aspect ratio, showing everything properly.

As many have commented before me (check out the comments at IMDB), this is a lovely teenage movie made just before things were about to change. Instead of adding my own bumbling commentary, here is one of the comments from IMDB:

The sixties became The Sixties around the time of this film, 1964. There was a time, believe it or not, when kids played grown-up, instead of the other way around, as is the case today. Two cute girls are venturing from childhood to youth, in a benign Manhattan. They have a crush on a pianist-lothario who happens to be Peter Sellers. You can imagine the complications - and the hilarity.

What makes this film so appealing, is the way it portrays sexual awakening and same-sex bonding as a completely unsordid and sweet experience. Yes, there is pathos, when the two discover how adults have turned their world into Henry Orient's world.

Although the cast is sterling all around, Tom Bosley is a standout as father to one of the girls, who helps put things to rights.

If the Kennedy assassination and Vietnam are cultural watersheds, then this film is a wonderful cinematic artifact; it gives the lie to the condescending put-downs of the era by the current generation.

Another comment talks about "the magical, honest bond of best-friendship between girls". Whatever. I would like to be gender blind, and say that the film demonstrates the magical and honest bond of best friendships, something which I was encountering when I first saw the film. To me, that is more important than the plot involving Sellers, and especially more important than the film's ending (not the final scene, but the ten minutes which precede it).

In fact, the film could almost have been split in half: the first forty minutes, and the rest of the film. This is not to say the that the second half is any less good than the first, but rather the first part shows a specific world and emphasizes the values of friendship, whereas the second part develops a story.

I am not too sure whether the accompanying score is subtle or blatant; certainly whilst watching this film for the fourth or fifth time, I was paying more attention to the score than one normally does. During the Central Park scene at the beginning, note how whenever the girls are on screen, a 'youthful' theme is being played, but whenever the camera cuts to Sellers, the score consists of abstract piano chords, in keeping with his character.

The young actress playing Val - Tippy Walker - unfortunately did not stay in the movie business. Most of the time she looks to me like a young Diane Keaton; if one takes the Diane of 'Sleeper' and tries to imagine what she would have looked like ten years younger, then Val is the result.

[Edit from 22 July 2010: The poem referred to above was written on 16 Nov 1971, which means that the film was screened a few months before hand]

Nick Drake in "Ma'ariv"

The weekend culture supplement of the Israeli newspaper "Ma'ariv" has been running for several months a feature in which one of the editors presents a long forgotten record which is considered to be a classic. For example, a few weeks ago, the record chosen was Love's "Forever changes".

This week it was the turn of Nick Drake's "Five leaves left". Whilst it is true that there is no such thing as bad publicity, there were a few "facts" in the article which left me scratching my head. For example, did you know that Fairport Convention provided the accompaniment for the record? Did you know that Elton John was the second (recording) engineer? Did you know that the meaning of the record's title is unknown?

Maybe these "facts" upset my equilibrium so much that I was unable to concentrate on the rest of the article, but I'm fairly sure that there wasn't much of a case made which would make anyone want to listen to this record. Which is a shame.

I sent an email last night to the paper, and it will be interesting to read the response (if there is one).

For the record, although Ashley Hutchings, then bassist of Fairport, "discovered" Nick Drake and brought him to the attention of Joe Boyd, the only Fairporter present on the recording is Richard Thompson, and he played guitar on one track only. To be fair, Dave Pegg and Dave Mattacks appear on most of the tracks on Nick's second album, "Bryter Layter".

Elton John worked as a session pianist before he became famous. The only connection with Nick that I can think of was that he was recruited by Joe Boyd to sing on a privately issued record (500 copies) which was intended to publicise songs published by Witchseason Music (Boyd's publishing company) in the hope that other artists would cover them. This record was mythological, until a few years ago when someone laid their hands on a copy and digitised it. Since then, it has been distributed here and there, and someone was kind enough to send me a copy a few years ago (I have to be vague here, as I don't recall who it was).

I spent half an hour looking for the disk, and was unable to find it, until I found an archived and compressed version, along with the Brad Pitt narrated "Poor Boy" audio documentary. After decompressing the songs, I listened and then remembered why I don't have an audio disk: EJ murders the songs! Or at least, he renders them unlistenable to anyone who knows the originals. His versions are blues infected rock, and whilst an unaware audience might find them interesting, to me he removes any subtlety which there might be in the songs (and there is subtlety a plenty!) and emphasises the wrong things.

Firebird date fields, continued

Following on from my previous post, I discovered that the code which I posted did not work.


What did work was a query with parameters:

update person set
dob = :a1, examdate = :a2
where id = :an

Here is the corresponding program code

with qDates do
 begin
  close;
  parambyname ('a1').asdate:= dob;
  parambyname ('a2').asdate:= examdate;
  parambyname ('ap').asinteger:= pid;
  execsql;
 end;

It's nice to know that this blog is being read by someone (see comment attached to previous post), and it's even better to know that we reached the same conclusion.

At the moment, the code which enters a new person into the database is split between two queries: one is an insert query, passing string literals, and the other (shown above) is an update query passing parameters. I now wonder whether it is possible to use only one query, which will insert using parameters. This will make the code run quicker and will also be clearer. Early days.

The port of the simple program from BDE to FB was completed last night with the above code. It's interesting to draw conclusions from the port:

1. One unit reads a text file (which is the output from the exam program), and inserts data into the 'people' and 'results' table. This is done using the TSQLQuery component with 'insert' and 'update' statements (should only be 'inserts' - I'll work on this tonight).
2. One unit allows the 'people' data to be edited - this is done at the moment with the trinity of TSQLDataSet, TDataSetProvider and TClientDataSet. Now that I think of it, one needs the 'trinity' only when a bi-directional dataset is needed, and in this case I am displaying only one record, which means that I may be able to use the TSQLQuery alone, in the same way that I used TQuery in BDE programs.
3. One unit displays all the people who have taken the exam - as this uses a dbgrid, the trinity is used.
4. Two units output data (to Word) - TSQLQuery.

So, apart from correcting the input unit (a simple matter), I should investigate whether the editing unit can be simplified.

One final 'gotcha': in order to use the program during development, the TSQLConnection has the appropriate database string and is automatically opened. This has to be changed after primary development has been finished, as the program must be deployed without a database string, meaning that the connection must be initially closed. I can't see a way of doing this automatically; I will have to remember to change the connection parameters before deploying the program.

Firebird date fields

In continuation of my previous post about problems of inserting/update date fields in FB databases, I did a little poking around and eventually - by trial and error - found the correct syntax:

update data

set datefield = '01/01/2008'

where id = 1;

It's going to be an interesting exercise producing code like that from Delphi, as the single quotation mark is the string delimiter, and it's always fun trying to create strings which include the quote. It'll have to be something like this:

with sqlquery.sql do

begin

add ('update data');

add ('set datefield = ''' + query1.fieldbyname ('datefield').asstring + ''' where id = 1';

end;

Let us not forget that the date is being passed from a query which is accessing the original BDE database.

Climbing the learning curve

I've spent the last week getting Firebird to work in my occupation psychologist's office. On my development computer, this is very easy, as the FB server runs on the same computer as the development system, but in the office, the FB server runs on a computer server, and the programs accessing this server run on different computers.

Eventually, after a lot of huffing and puffing, I got FB running in the configuration that I want: server program on server computer, client programs on client computers. In the process of doing this, I wasn't able to utilise the 'aliases.conf' file of FB successfully; this is a system in which each client program uses an alias to access the actual database data. The alias allows one to move the database file from location to location without having to redefine within the client program the physical location of the database file. This is fine in theory, but I couldn't get it to work in practice (the problem lies in the fact that at home, the file is on the same computer as the client, whereas in the office, it isn't).

In the end, I solved the problem by ignoring aliases, and storing the database location in the client computer's registry. I had originally intended to do this in the client program, but after a few minutes cogitation, I realised that this would not be a good idea, as the same code would have to be duplicated in every client program. Accessing the location from the registry is not the problem, but rather saving the data in the registry (which would involve a 'find file' dialog).

With this in mind, I sat down yesterday to write a small program which displays the data saved in the registry, along with the possibility of adding and editing this data (I'm not going to bother with deleting values at the moment, even though this would be simple). The program is akin to many other simple database programs that I have written, although with two very important differences:

1. the data is stored in the registry, not in a database, meaning that the access methods are completely different
2. the data is displayed in a list view and not in a dbgrid

I have never used a list view before, but was able to find simple code which explained what I needed to do.

I have also been porting a program from using the BDE to Firebird; to warm myself up, I took a simple program (actually two programs) which has a small database. As I wrote before, the screens which display data are fairly easy to convert. Adding data is more difficult, and this time I went a stage further than the first program which I ported: I learnt how to use a generator in order to provide an auto-incrementing value. In the BDE, this happens automatically, but in FB one has to do this manually.

The major problem in porting an application would seem to be converting the data from one database format to another. Whilst there is no problem in exporting and importing integer and string values, there is a minor problem with boolean values (BDE has them, FB doesn't), and a major problem with dates. This is the next problem to be cracked. Fortunately, the database which I am porting only has about 45 records (two dates per record), so I added the dates manually, but the major program suite which I will port in the near future has over 3,000 records (not a huge amount for mankind, but large enough) with two dates per record, and there is no way that I am going to add those dates manually.

So this week, I've learnt the following things

• how to install FB on a network
• how to access FB from client computers on that network
• how to use the list view component
• how to use an FB generator for auto-incremented integers
• how to insert/update a date into an FB table [to do]

That's enough for one week.

Fortunately (and purposely) my MBA load is very light at the moment, so I don't have to devote more than five hours on a Friday morning to this on-going project. The accountancy course is very simple - for me, as I spent years of my life working on the material which is being presented - but apparently is difficult for people when it's the first time that they come across it.

Moving office

The powers that be decided that our factory should be moved to a new building. I think that the decision was based on two factors:

1. Not being satisfied with our current arrangements (where the raw materials warehouse is 4km from the production areas!)
2. A reduction in the volume of orders means that the current leased floor space is too large

So we're moving to a brand new building, about 500 metres away. As it's new, everything has to be installed - primarily electricity, but also sprinklers, telephone wires, network cables, plumbing - and an office has to be built. Due to the scarcity of space, the office consists of two separate floors.

Each cubicle looks at the moment to be very small. I have been given to understand that my table will fit in the space allotted me, but I don't know what else will fit. Maybe it's time to start a diet, so that I will be able to slide between the wall and the desk in order to get to my chair.

The server room has also been reduced in size; I gave an estimate of the minimum amount of space that I need, and that's the size that I've been given. What I didn't know is that one wall of this 'room' - the outside wall - is mostly taken up with a window! This is bad on several accounts:

1. Anyone can break in through the window (so bars are supposed to be fitted)
2. Too much light comes in
3. Too much heat comes in
4. Valuable wall space is lost - there is equipment which could have been fixed on the wall in that area.

Today we spent a few hours packing up. It's interesting to note how many cartons have been left unpacked since our previous move, 20 months ago. I have a real problem with throwing things away, but this time I was able to part with ten (or more) old printer cables, an external modem, uncounted electricity cables, old ink cartridges for printers that no longer exist, a few L120 cassettes, ad infinitum. I could also part with documentation relating to the upkeep of my old Alpha server which was decommissioned several years ago.

Speed IV

Honestly, Ma, I tried as hard as possible using threads, but there was always some problem. So I dropped using threads and tried to improve my code algorithmically.

The problematic module is basically composed of four sections: an initialisation section, and three different queries. Most of the time was being spent executing the second query, so I concentrated my efforts here. The first optimisation was to note that data from one table was being read several times in several different queries; although it goes against the grain, it proved quicker to extract that data with a simple query, store the data in an array in the program code, and then simplify the other queries which would look up the missing value in the array. This speeded up the execution, but still not enough.

Then I went down to the metal. There was a query which basically was returning the same data again and again which would then be sent to an expensive operation. I had implemented a check before the expensive operation several months ago to make sure that the same data wasn't being sent, but now it was clear that the check was occuring too late. I was checking after the query had returned a dataset instead of checking before accessing data. Once I had repositioned and recoded the check, the program ran much faster.

So basically I've spent two weeks running around, learning about threads and emitting HTML code, when in fact I could have saved all that effort by concentrating on improving one query.

I read somewhere in this blog that SQL joins slow down a program and should be avoided at all costs. This sounds like shooting oneself in the foot, because if there are no joins, then all the power of SQL is lost. Well, not quite. Although it's messy, it makes no sense to extract the same data continually from the server; better to extract it once, save in in RAM and use lookup statements in code.