Gallup Happiness report 2025

As in previous years¹, the Gallup happiness report has been released, and once again Israel is in the top ten, being ranked 8^th. As I wrote then, One thing is clear: maybe we were happy, but not in 2023! I suspect that the 2024 report will show a sharp decline in Israel's happiness. Then I was referring to the proposed ruin of the judicial system. The events of Oct 7 were six months in the future. 

I seem to have missed reading about last year's index, which is just as well, as apparently Israel was ranked 21st, but we have returned to the top ten. I quote from the Globes article:

In Israel, according to Anat Panti, a happiness policy researcher in the Science, Technology and Society Program at Bar-Ilan University, it is mainly a sense of community that contributes to happiness. "The deep sources of Israeli resilience: family, community, faith, a sense of belonging and strong social ties - still manage to keep large parts of society well above the global average," said Panti. She says that one of the particularly striking figures this year is that, broken down by age group, Israelis under the age of 25 are ranked as the happiest age group within the Israeli population and in third place in the world. "The fact that Israel still ranks eighth in the world, and in particular that young Israelis rank third, is indicative of the strengths of the population in Israel relative to other countries," she said. However, in other indicators examined, there was a deterioration in Israeli responses. In the indicators about worry, sadness and anger - negative emotions experienced by the population - Israel jumped from 119th place before the war to 39th. In the Corruption Perceptions Index, it fell to 107th place, compared with 80th place in 2021.

"The rise in the indicators about concern and anger and the erosion of public trust make it clear that resilience is not immunity," added Panti. According to Panti, the survey on which the current ranking is based was conducted in July 2025, after the campaign against Iran but before the release of the hostages from Gaza. In her assessment, the level of negative feelings in the Israeli public would have decreased if the survey had been conducted after October 2025.

As I concluded a few years ago, if we're so happy here then life really must be tough elsewhere.

On other quotidian matters, yesterday was a strange day. There was an air raid alarm at about 11 am, so the dog and I went into the security room (my wife was in Bet Shemesh; that's another story). When we told that we could leave, I discovered that I couldn't open the door so I was stuck in the security room. Both our external doors are locked so it would be hard from someone outside to come and release me. Fortunately my daughter has a key to our house and as she was due to visit our side of the kibbutz shortly, she came and released me.

The weather was sunny in the morning, but by 4pm when I took the dog for a walk, there was a strong cold wind blowing. As we were coming home, sporadic drops of rain fell on us. Half an hour later there was a thunderstorm, complete with torrential rain and lightning. 12.9 mm fell. At about 23:30, we had an hour of continuous air raid warnings.

Internal links
[1] 1736

---

This day in blog history:

Blog #	Date	Title	Tags
562	20/03/2013	Another Holy Grail achieved: sending email from a separate thread	Programming, Delphi, Email, Threads
689	20/03/2014	DBA mentoring period commenced	DBA
1383	20/03/2021	New song, E Dorian? B minor?	Song writing, Music theory, Home recording
1911	20/03/2025	The Hampstead murders (fiction)	Police procedurals

Two methods for creating pivot tables with Firebird 2.5

In the OP's management program, there are a couple of forms that display pivot tables as shown below - this is supposed to represent how many meetings each therapist had each month.

Therapist	1	2	3	4	5	6	7	8	9	10	11	12
John	4		13	6	12	1		1	1	4	8	1
Judy	12	11	10	9	8	7	6	5	4	3	2	1

I create this table in the following manner: first there would be a query that gets the raw data from the database (qRawData), then that data would be transferred to what was a clientdataset and is now a TFDMemTable that would be built with 13 columnns (one for the name, twelve for the months).

qRawData.sql statement:
 select therapists.name, extract (month from meetings.perfdate) as monthnum, 
        count (meetings.id) as meet
 from therapists
 inner join meetings on meetings.therapist = therapists.id
 where meetings.activity = :p1
 and meetings.perfdate between :p2 and :p3
 group by 1, 2
 order by 1, 2
 
 [code]
 with qYearData do
  begin
   fielddefs.add ('therapist', ftWideString, 24, false);
   for m:= 1 to 12 do
    fielddefs.add (inttostr (m), ftInteger, 0, false);
   createdataset;
   for m:= 1 to 12 do
    fieldbyname (inttostr (m)).DisplayWidth:= 6;
   open
  end;

 with qRawData do
  begin
   close;
   parambyname ('p1').asinteger:= activity;
   parambyname ('p2').asdate:= encodedate (year, 1, 1);
   parambyname ('p3').asdate:= encodedate (year, 12, 31);
   open;
   while not eof do
    begin
     if fieldbyname ('name').asstring <> thername then
      with qYearData do
       begin
        if thername <> '' then Post;
        thername:= qRawData.fieldbyname ('name').asstring;
        append;
        fieldbyname ('therapist').asstring:= thername;
       end;
     amonth:= fieldbyname ('monthnum').asinteger mod 12;
     if amonth = 0 then amonth:= 12;
     qYearData.fieldbyname (inttostr (amonth)).asinteger:=
          fieldbyname ('meet').asinteger;
     next
    end;
   close
  end;

I wondered whether there was a better way of doing this. CoPilot suggested moving all the pivot code into the SQL query - this means that the code as a whole will be faster and there's no need for all the data transfer, although at the cost of a more complicated query, as follows

select therapists.name, 
sum (case when extract (month from m.perfdate) = 1 then 1 else 0 end) as m01,
sum (case when extract (month from m.perfdate) = 2 then 1 else 0 end) as m02,
sum (case when extract (month from m.perfdate) = 3 then 1 else 0 end) as m03,
sum (case when extract (month from m.perfdate) = 4 then 1 else 0 end) as m04,
sum (case when extract (month from m.perfdate) = 5 then 1 else 0 end) as m05,
sum (case when extract (month from m.perfdate) = 6 then 1 else 0 end) as m06,
sum (case when extract (month from m.perfdate) = 7 then 1 else 0 end) as m07,
sum (case when extract (month from m.perfdate) = 8 then 1 else 0 end) as m08,
sum (case when extract (month from m.perfdate) = 9 then 1 else 0 end) as m09,
sum (case when extract (month from m.perfdate) = 10 then 1 else 0 end) as m010,
sum (case when extract (month from m.perfdate) = 11 then 1 else 0 end) as m011,
sum (case when extract (month from m.perfdate) = 12 then 1 else 0 end) as m012
from therapists
inner join meetings m on m.therapist = therapists.id
where m.activity = :p1
and m.perfdate between :p2 and :p3
group by 1
order by 1

This is the sort of code that I write once and never look at again. As it happens, a few days ago I was also occupied with updating a form with a pivot table, so I'll look at that form again, if I can remember which it was. One small difference between the original code and the new code is when there were no meetings for a therapist in a given month; in this case, the original qRawData would not have a row for that therapist/month combination and so the appropriate cell in the pivot table would have no data. Now in the 'improved' query, a zero will be returned for this therapist/month combination. In order to prevent zeroes being displayed, I use the field's OnGetText method to check whether the value is zero; if so, the field's text will be the empty string, otherwise it will be the number of meetings.

I'm using Firebird 2.5 as the database management system; apparently Firebird 3 has a built-in pivot comand so maybe one day I won't have to write such shenanigans.

---

This day in blog history:

Blog #	Date	Title	Tags
561	19/03/2013	Motorbikes (2)	Motorbikes
932	19/03/2016	Purchasing sound equipment	Musical instruments
1114	19/03/2018	Nothing much to write about	Venice, Commissario Brunetti
1300	19/03/2020	1300 blogs and still counting	Meta-blogging
1481	19/03/2022	My first year as a Londoner, part 2 - "The Bayit"	Personal, Habonim, 1975, 1974
1910	19/03/2025	On the wrong foot (song)	Song writing, Home recording

Analysing my lunch

The health app on my phone (from my health fund) records my daily steps; I noticed yesterday that I can also photograph meals and get points for doing so.

So today I photographed my lunch via the app; I could see that the app scanned the photo three or four times, and then to my surprise told me that on the plate there was 125 g quinoa, chicken, broccoli and sauce. I don't recall the weights of the other items except for the quinoa. Now I can't restore that dialog and I also can't see how I can get the photograph itself (maybe next time I'll photograph outside of the app and inside). But I can see how much of each macronutrient there was: 1.1 portions of vegetables (and I thought that there was less broccoli than usual), 0.3 portions of fruit (I wonder where that came from), 106 g carbohydrates, 56 g protein and 20 g fats. The quinoa is responsible for 97 g carbohydrate, 21 g protein and 9 g fat, whereas the chicken contributed 31 g protein and 3 g fat. The broccoli contributed 5 g carbohydrate and 2 g protein, whereas the sauce had 5 g carbohydrate, 2 g protein and 8 g fat. Althogether 845 calories, 36% of my daily requirements (that means 2,347 calories that seems a bit high). I'm impressed that the quinoa was identified properly and not mistaken for cous cous or the Israeli invention p'titim (literally 'flakes' as in snowflakes) which are also cous cous - semolina. They look quite similar from a distance.

Isn't AI wonderful? I'll try and photograph my meagre supper (a piece of 'white' pizza left over from yesterday). It will be interesting to see what the AI makes of my breakfast; I suspect that not all of the ingredients will be visible. 

---

This day in blog history:

Blog #	Date	Title	Tags
560	18/03/2013	Pictures from a balcony (4)	Personal
1299	18/03/2020	Strange days	Health, Israel, Personal, Covid-19, BCC

Continuing the migration, supplemental

Today I will write about something that I meant to include in the previous post but forgot: when does one need a TFDMemTable (hereinafter, TMT)? After all, one can define a TFDQuery, include an SQL query to retrieve data from the database, connect the query to a datasource and thence to a grid: the data will be displayed. Also, in a simple 'edit' form, there's no need for a TMT.

I have identified two cases when a TMT is required:

1. If the grid that displays the data has an OnTitleClick event - this allows the user to sort the data.
2. If the form allows the addition or deletion of data.

According to CoPilot, a TFDQuery doesn't have indexes whereas a TMT does. So when I migrate units with a grid, I first check to see whether the grid has an OnTitleClick event; if so, I know that I need to a TMT. Incidentally, there is a new flag that has to be set in the grid's options - OnTitleClick. This flag didn't exist in Delphi 7, and I came across it in one of the first units that I migrated. I was clicking on the title bar but the event did not fire ... because this new flag was not set.

If the grid does not have an OnTitleClick event, I check whether the form has a qGetOne query - this means that data has to be added - or a qDelete query. In the case of qGetOne, previously I used to iterate over the fields of the query and add them one by one to the clientdataset. A TMT has a new method, AppendRecord, that allows for the data to be added in one statement (never mind that beneath the hood, the data is still being added field by field). I have used this everywhere, apart from one or two special cases where AppendRecord seemed not to be appropriate.

The TMT comes 'naked' without fields. Here is my methodology for adding them (this may not be optimal). First I check that the query can be opened - it frequently happens that fields are defined automatically as ftString when they should be defined as ftWideString. So I fix all these before I even start with the TMT. When the query is defined properly, I open the 'fielddefs' property of the TMT and begin to add fields. The size of the fields is very important when the field in the query is a ftWideString; the default size is 20 but this should be changed to match the size of the query's field. When all the fields have been defined in the 'fielddefs' property, I then open the TMT's fields editor. This will be empty so I press on 'add all fields' and the fields that I added in the 'fielddefs' property now become persistent fields. I then iterate over the fields in the query, copying their displaynames to the TMT's fields, and finally I delete all the persistent fields of the query. I do this in order to highlight any use in the code of these persistent fields - it has happened that I received bizarre results when debugging and I discovered that these came from usage of the query's persistent fields. As the grid displays data coming from the TMT and not the query, progressing through the TMT gives different data in the persistent fields, whereas the query's persistent fields stay the same.

I wrote about changing column widths in a grid and saving them. I came across a very interesting problem with this: every form has a minimum width that is hard coded. I changed the column widths of one grid so much that the new width was less than the minimum width; as a result, there was a huge space on the left hand side of the grid before data appeared. How could I fix this? I made two additions: I converted the procedure that saves the column widths into a function that returns the total width with an extra 72 pixels for the scroll bar. I then wrote a procedure in the ancestor form that saves this new width. When the form is opened, this new width is compared to the minimum width, and if it is less, then the minimum width becomes this new width. Slightly messy but it works. Part of the problem is that the code for saving and restoring column widths is in a different unit from the ancestor form. Maybe I should move this code to the ancestor form - but not every form descends from this ancestor and maybe I would want to save column widths on such a form (unlikely).

---

This day in blog history:

Blog #	Date	Title	Tags
119	16/03/2008	Back to blogging	Office automation, Meta-blogging
120	16/03/2008	Chava Alberstein	Chava Alberstein
464	16/03/2012	Rubber duck debugging	Programming
1480	16/03/2022	My first year as a Londoner, part 1 - being a student	Personal, 1975, 1974
1593	16/03/2023	I contain multitudes	Food science, Non-fiction books

Continuing the migration

Over the weekend I worked for 15 hours on the continuing migration¹ of the OP's management program. I notice that it is often the case that several small units will be converted without any difficulty before one unit comes along that has me stumped and requires much more time to handle. Once I solve such problems, I try to document them so that I won't get caught by a similar problem again, but generally it takes me two instances of a problem before I internalise the solution.

So what have I learnt so far? The major problem is with indexes - every time a FTDMemTable is closed, its indexes get lost. So don't close the table! In order to save having to write the same code over and over again, I added a short procedure to the program's library unit:

Procedure LoadData (aq: TFDQuery; mt: TFDMemTable; idx: integer);
begin
 aq.open;
 if mt.active then mt.close;
 mt.copydataset (aq, [coRestart, coAppend]);
 buildindices (mt);
 mt.indexname:= 'idx' + inttostr (idx * 2);
end;

Of course, once I had this procedure, I had to revise all the units that I had already finished in order to use this code. 

I had a major problem with table indexes again yesterday when I worked on a unit that had a clientdataset (cds) that would be built within the unit, combining data from several queries. Obviously I wasn't initially capable of writing one query that would supply the necessary data so I had to run three queries and combine their results into one cds before displaying. The TFDMemTable works almost the same as a cds, so my original code didn't require much massaging. I had forgotten that I had already come across this problem; solved it and even documented² it. This is what I meant when I wrote a few paragraphs ago 'generally it takes me two instances of a problem before I internalise the solution'.

The order of writing should be as follows (see manage135):

1. Define fields, remembering to use ftWideString when necessary.
2. Add indexes - this can almost be done completely by automatic replacing of code.
3. Finalisation: createdataset, indexdefs.update then open.

Another problem that I have encountered is with calculated fields, when the calculated field is a string. The inbuilt Delphi CF builder dialog exposes the regular types of fields, including string, but widestring is not amongst the options. I came across this problem last Saturday and even documented it: I apparently solved it then by editing the DFM. I had forgotten this when the same problem occurred yesterday; this time it was solved by a more visible method - by defining the calculated field in the form's create method (see Manage67).

 f:= TWideStringField.create (mtReceiptsList);
 f.fieldname:= 'CashType';
 f.DisplayLabel:= 'סוג תשלום';
 f.fieldkind:= fkCalculated;
 f.size:= 20;
 f.dataset:= mtReceiptsList;

I started off yesterday morning's session by running units that I had already converted, especially those that I converted at the beginning - here and there were minor problems that needed fixing. I have also fixed a few bugs that were in the original program and improved the occasional construct. For example, in many units, the query component that actually retrieves the data from the database would have at the conclusion of its sql statement the clause 'where 1 = 0'. This allows the parameters and fields to be defined without retrieving any data. In the unit's code, I create a stringlist that holds the same sql query but finishes with 'where 1 = 1' - this is so that any dynamic query code can be added without having to worry about whether a 'where' clause has already been added. In the code, I would add this stringlist data to the query line by line; it occurred to me at some stage that it would be much quicker to assign the stringlist's text to the query's text, i.e. aquery.sql.text:= stringlist.text. 

Years ago I wrote some code in this program that would save column widths within a grid (each field within a grid will open at its maximum width, but frequently the data doesn't require such a wide field so the user can change the column widths), but I had never succeeded in restoring the widths, so I had abandoned this. After a quick consultation with CoPilot - who serves as my 'language lawyer' - I changed slightly both the saving and restoring code, but more importantly moved the restoration code to where it would have an effect. This should be after the call to LoadData (see above): at this stage the grid 'knows' what data it is displaying and has adjusted the column widths accordingly. Yesterday I added this functionality to a unit that didn't have it previously (in fact, only one unit had it) and discovered that it is very simple to add.

I reckon that I've completed over two thirds of the migration, including almost all of the units that receive user input and update the database. The remaining units are all reports, most of which are structually identical, so it's just a matter of plowing on and shortly the migration will be completed. Then will come the testing....

Internal links
[1] 2084
[2] 2082

---

This day in blog history:

Blog #	Date	Title	Tags
463	15/03/2012	Sequencing "Lost" / 2	Van der Graaf Generator, Peter Hammill, Home recording
688	15/03/2014	Boy, was I wrong - programming naivety	Programming, Delphi, ClientDataSet
1381	15/03/2021	A year of Covid-19	Covid-19
1592	15/03/2023	Goodbye, Dilbert (at least for the time being)	Personal
1731	15/03/2024	Jasmine Myra (2)	Jasmine Myra

Pollo Cacciatore

My last blog¹ and the silence since may have given the impression that life wasn't going well with me, but that's not true. I have been keeping well and working many hours on migrating the OP's management ERP system to Delphi 12, and as the OP said to me yesterday, "I should be thankful for the war" as it has allowed me the time to work on this project. Naturally, my day job has been very slow: I barely worked on Sunday and Monday and although the pace picked up slightly during the week, I also had time to program. And unfortunately I also had time for migraines: one woke me in the middle of the night a few days ago (this is the first time that I have ever awoken with a migraine) and one took out a few hours of Thursday.

As with the Prolog interpreter project², I don't want to fill this blog with daily updates of how the conversion process is going. I've identified some key points that I have to be aware of when migrating although almost every day has me coming across a new problem. I spent all day yesterday debugging the 'DoDockets' form that for the users is probably the most used form of all. There is still one problem to be solved, but I'm fairly sure that I know what the solution is. Once this is out of the way, I hope to get the rest of the input-receiving forms finished today and tomorrow, leaving all the report forms. Whilst there are many such forms, most are basically the same, so migrating these should be fast and problem free.

This is the blog entry that I intended to write a week ago before real life intervened. The title, pollo cacciatore, is Italian for "Hunter's chicken" and is basically a dish that mixes chicken with a multitude of vegetables. I came across it in the Kate Benedict book series; I thought that I remembered a discussion of this dish but couldn't find one when I looked for it. The cooking has got absolutely nothing to do with the stories themselves but add a certain amount of verisimilitude. Maybe I'll write about them at a later date.

Anyway, when the world was still young and innocent, i.e. last Friday, I made this dish as an experiment. The recipe that I used included browning the chicken pieces in a wide pot; this step has never seemed to have contributed anything to the final taste. I discovered that the pot wasn't big enough to include four chicken thighs and four drumsticks so I had to remove one of each. In order, the vegetables cooked were onion, carrots, celery, mushrooms, bell pepper and parsley. After cooking them for about 15 minutes along with shallots, I added a glass of red wine (this is, after all, an Italian recipe) and then a can of crushed tomatoes (ditto). This stayed on the gas ring for another hour. The result was quite tasty but the chicken did not fall off the bone as it normally does in my cooking.

I considered how the dish could be improved, both in terms of cooking time and the number of portions. It didn't take long for the answer to come: instead of cooking in a pot on the gas, cook in the usual oven tray that can hold 16-18 portions. So yesterday evening, I didn't bother with browning the chicken; I made the vegetable sauce in the same way as the week before, albeit with larger quantities. When the sauce was bubbling away merrily, I placed the chicken pieces in the tray, then poured the sauce on top (with an extra glass of water, just to be sure that there is enough liquid), covered the tray with baking paper then aluminium foil, then into the oven for 2½ hours at 175°C.

I thought that the chicken came out very well, but it didn't seem to absorb much taste from the vegetables and tomato source. The general appraisal was that the results didn't justify all the extra work, so next time it's back to chicken pieces with (uncooked) onions, shallots and mushrooms, along with fig sauce and onion soup. As this food is supposed to feed my wife and I during the coming week, there was plenty left over, and it may be that the taste will improve the longer the chicken is in the sauce.

Internal links
[1] 2085
[2] 2063

---

This day in blog history:

Blog #	Date	Title	Tags
341	07/03/2011	Post mortem on the Marketing exam	MBA, Marketing
553	07/03/2013	Alvin Lee, RIP	Obituary
1296	07/03/2020	Thesis dilemma	DBA
1478	07/03/2022	Rifts and drifts (song)	Song writing

The war stopped being remote and impersonal today

At about 2pm today, with no prior warning*, the air raid siren went off. My wife and I were in our security room within a minute; I had just shut the door when there was a terrific boom and a shock wave that seemed to shake the entire building.

Shortly after, we were informed that a ballistic missile had landed in Bet Shemesh and killed 9 people: a direct hit on a synagogue with an air raid shelter below. Nothing can withstand a missile coming from the upper atmosphere with a 500 kg warhead. 

Even though that missile landed 4-5 kilometres away from where we are, we felt it as if it were next door. Unsurprisingly, many houses in the vicinity of where the missile fell have been damaged from the shock waves. 

Bet Shemesh can hardly be considered a strategic target, although it is quite possible that the missile was aimed at an air force base maybe 10 km from where the missile fell, but because of poor guidance (or poor intelligence) the missile missed its target.

Until now, this operation and the 12 day war that preceeded it had seemed remote, impersonal and detached from our day to day existance. It's even been a little fun, having days off from work and social encounters that don't happen too often. But today has changed all that: it has brought the war almost to my doorstep.

* Normally a warning is sent out about ten minutes in advance that a missile launch has been detected, but I don't recall receiving such a warning before this event. Often there's a warning with no siren afterwards because the missile's trajectory has been computed more accurately and it's more clear when the missile is not going to land.

Internal links
[1]  1950

Bringing the Management ERP program to life

Yesterday was a very strange and frustrating day. Inbetween the many times that I spent in our security room, I continued to work on migrating the management ERP program to Delphi 12/Unicode/Win11. I continued in the same vein as Friday, migrating the forms needed to create a minimal version of the program that actually does something. 

By about lunchtime, I had a clean compilation with maybe 30 different units (I haven't counted them) but when I came to run the program, it didn't progress after the splash screen, displaying the error 'Class FMTBCD not known'. I recognised this name as it is one of three units (the others being SqlExpr and Provider) that dbExpress adds to units that use that kind of database component. I hadn't been diligent in deleting these units from the source files, so first I had to do a global search then removed them from about 15 different units. 

After recompiling, I still had this error, so the next step was to look for persistent field variables defined as TFMTBcdField (or similar). There were a small number of such variables, but replacing them was problematic as that definition came from the DFM files. So I added some more replacement rules to the DFM migrator to handle this case. I should point out that sometimes adding what seems to be a simple change to the migrator is actually quite complicated. For example, I had some such fields that had to be redefined as TFloatField, but as the fields in the original DFMs had properties such as 'precision' and 'size' that TFloatField does not have, these lines have to be excluded from the transfer - not so easy. These changes are required because Delphi 12 Community Edition deliberately excludes certain types.

Even after changing the type of these variables, I was still getting the error message. Eventually I tracked it down to one specific query in the data module, an 'invisible' query that has several fields defined as BCDs. Changing these was very difficult but eventually I succeeded. But was that the end of my problems? No - first there was TMemoField then TSmallintField. Fortunately it was easy to overcome these problems by directly editing the appropriate DFM file.

Then when I thought that I had a clean compilation and no run time errors, Windows' Access Control had to stick his ugly head into the process, so I had to spend a frustrating hour or so getting a certificate, saving it into the certificate manager and thence into the Delphi compiler. Fortunately I won't have to do this again, although I may have to copy what is equivalent to a small batch file when I work on another program.

Finally at about 7 pm, after a very long and stressful day, the program compiled and actually ran. I could bring up the list of customers! This may not seem much, but to get this far required fixing and compiling many units and overcoming what can only be described as overhead. Of course, very little on this form works at the moment, but the remaining problems here are relatively easy to fix. 

And once that's done, then I'll have to start the process over again, finding important forms that need to be compiled and then the units that support those forms. The 'DoCustomers' form is used for three different tables and requires 18 different user forms in its 'uses' statement, so completing this form will be an important milestone. Then there is the 'DoDockets' form with about 20 different supporting forms, and the 'DoTables' form with maybe 30 forms. Once these are completed, then 'there only remains' about 40 report forms, but these should be relatively simple to migrate as they are all based on the same template.

---

This day in blog history:

Blog #	Date	Title	Tags
67	01/03/2007	Donating blood	Health, Donating blood, BCC
236	01/03/2010	More MBA	MBA, Economics
338	01/03/2011	Pre-exam nerves	MBA, Randy Newman, Marketing
815	01/03/2015	Last of the luddites (2)	Computers