The Imperfect Crime

The following is a work of fiction. All characters and events portrayed below are purely fictional. Any resemblance or similarity to real persons or events is purely coincidental.

The following is copyrighted to Blogannath. All rights are reserved.

The Imperfect Crime

The perfect crime requires perfect planning. And perfect timing. And perfect execution.

Mike Kopesky had planned perfectly. He had returned to his suburban Detroit home after a weekend in California, to find his wife's body hanging in the basement, with a noose around her neck. There had been a quilt and a couple of blankets, and a toppled-over stool next to them on the floor of the basement.

After Mike "recovered from the shock", he had called police. Everything had gone according to plan as he had explained to the police that he had been away from home when it had all gone down. He was nowhere near his wife when she died, and the police seemingly had no reason to suspect him. It was an open and shut case of suicide.

So, why was he now sitting in an interrogation cell at the police station, getting the third degree from a couple of detectives playing good cop, bad cop with him? The detectives kept asking him how he had done it. And when he refused to answer, feigning ignorance, they would leave him alone for an hour or so, then come back and start asking him why he had done it.

Mike had been married for about 3 years now. The first year had been very good. Mike doted on his wife day and night. He took her out to expensive restaurants and bought her expensive presents. It was as if he was still dating her rather than being married to her.

But, slowly, Mike found out he was not made for married life. He missed the freedoms his single friends enjoyed. He listened with envy as they recounted tales of late nights at bars and even later nights in strangers' beds. They were having the time of their lives while it seemed he was having his life force sucked out of him slowly.

His wife was as accommodating as she could be while still being his wife. She never stopped him from meeting his old friends and going out with them. In the beginning, she had wanted to go with him, and get to know his friends better, but that changed over time too. Mike did not seem to want her around. She got the feeling he resented her. She got the feeling he regretted getting married to her. She got used to being alone at home alone while he went out without her more and more often.

But her frustrations with Mike often boiled over into angry arguments. Mike missed her birthdays and their anniversaries while he was out carousing with his friends. He hardly ate at home, and when he did, he always made disparaging remarks about her cooking. Mike's wife desperately wanted to make the marriage work, but things were not looking good.

When she finally and reluctantly brought up divorce, Mike had gone ballistic and threatened her with physical harm. Their arguments had become more and more common and frequent. At one point, Mike's wife had called the police because she was truly afraid Mike would hurt her. Mike had come to his senses quickly enough and apologized profusely. He was warned by the police to watch himself, but he had not been arrested or charged.

Mike was now convinced that his marriage was a dead end. He thought long and hard about divorce as his wife had suggested. Love had blinded him when he got married to his wife, though. He had not had her sign a pre-nuptial agreement at that time. This meant that he might be on the hook for substantial amounts of money during the divorce proceedings. He could also be on the hook long-term with alimony payments.

Mike had taken out a large life insurance policy on his wife soon after marriage. Mike had not taken out the policy with the intention of cashing out on it. He had actually considered it a demonstration of his love for his wife. He considered the insurance policy a testament to the value he placed on her life.

But now, Mike had started wondering if he could take advantage of the insurance policy to kill two birds with one stone. Perhaps, there was a way to be rid of his wife without having to pay a divorce settlement or alimony. And at the same time, make some money off the process of being rid of her too!

But, as with all such products, the insurance contract specified that for the first two years after the contract was in force, no payment would be made if the insured committed suicide. Mike started planning the perfect crime as soon as that part of the contract was no longer in force. Mike was convinced the perfect crime was a self-inflicted crime, with the criminal and the victim being one and the same person!

His research had lead to a plan he had considered quite fool-proof. And his execution had been completely flawless too, as far as he could tell. The coroner had indeed concluded that his wife had died sometime during the evening or night on Saturday. He had flown out to California on Friday night and had not returned until Monday morning. Mike was justifiably confused as to what had allowed the detectives to latch on to him as the prime suspect in his wife's death.

Mike was getting confused about a lot of other stuff too. He had been sitting in this interrogation cell for the better part of two days now. The police station backed up to a rail line with constant freight traffic. The passing of trains made the whole building vibrate. The loud horns of the trains made him jump. Most of his food intake seemed to be hot, strong coffee to keep him awake. The bright light shining into his face constantly blinded him.

When he fell asleep in brief spells, he always awoke to a dream in which he was running down a long tunnel. He was trying to exit the tunnel before a train entered the tunnel from the other side. A train with a bright headlight and a loud horn. Initially, he had made it closer and closer to the end of the tunnel before the train smashed him to bits on its front grill, but lately, he was getting weaker and weaker. His legs felt like they were made of rubber and his lungs felt like he was breathing from under a wet pillow. The train's light was getting brighter every time too, and had turned into a wall of light rather than a train with a headlight.

Mike's head was pounding with a fierce headache when he awoke once again from his dream, to the sound of detective Steve's voice. Steve was saying something about evidence and puzzles. Mike came out of his dream a little more. Steve looked into his face and asked him whether he understood what he had said. Mike shook his head yes, then looked bewildered and shook his head no. All he wanted to do was go to sleep on a soft bed with a stomach full of food. And he wished he would never hear the sound of a train whistle for as long as he lived.

Steve sat down in front of him and started talking to him again. Slowly this time. As if he was talking to a second-grader who was having trouble understanding him. He said, "Mike, we know you killed your wife. We have enough circumstantial evidence to convict you and put you away. We don't know the full details yet. But we may be able to do something to convince the prosecutor to seek a lower sentence for you if you come out with the truth yourself. Give us the details and we can all get this behind us." Steve was obviously the good cop in the good-cop-bad-cop duo. Steve continued on, "if you do come out with it, I will make sure you get a good meal, and you can sleep in a soft bed with the lights turned off. Come on, don't make life more difficult for yourself."

Mike's brain was high on caffeine while at the same time it wanted to nod off given half an excuse. His eyes were burning holes in his head and he could barely keep his head up at this point. Having a good meal and sleeping in a soft bed, at least once, seemed like a good deal, to trade for his confession. The part of Mike's brain that wanted to sleep got the better of the part of his brain that wanted to hold out. The sleep-deprived part of his brain seemed to have a direct connection to his mouth too!

And once he got going, there was no stopping him. Steve's audio recorder and the video recorder in the interrogation room caught the entire confession as it came pouring out of Mike's mouth.

Mike had planned his California trip after his plan had been finalized. He did not explain to his wife why he had to go to California that weekend, but his wife had come to expect little in the way of explanations for his actions in the past few months. At least in the past few days, he had shown some signs of extra kindness to her, asking about her health, staying home instead of hitting the bars with his friends, helping out with the chores around the house, etc. Mike had to learn about her normal schedule and activities to be able to do what he had in mind without arousing suspicion!

On Friday, Mike had opened one of his wife's prescription sleeping capsules, and emptied the contents of 3 more of those capsules into this one. Her doctor had given her these capsules to enable her to sleep better. Ever since Mike and his wife had started fighting, she had had trouble sleeping properly. Mike knew his wife used sleeping pills, but not the details until he started doing the research. Perfect planning was a big part of the perfect crime!

Mike had learned in the week before his trip that his wife took one of these capsules after dinner. He also learned that the capsule contained flurazepam, a very long-acting sedative that usually ensured she got at least 6 to 8 hours of sleep. With the contents of 4 capsules in this one capsule, she was going to be asleep for at least 24 hours if not more.

Mike's plan had been for his wife to sleep on top of the ice while the ice melted slowly. He had calculated that the ice would melt by about a couple of feet in about 18 to 20 hours. He wanted his wife to die at around that time, when he was in California. If she died any earlier, it would start looking suspicious, so he wanted to make sure he got it just right. But he did not want the ice to to take longer than 18 to 20 hours for it to melt by two feet because he wanted his wife to still be asleep when the ice had melted about two feet. Perfect timing was a big part of the perfect crime too!

Very soon after dinner, he had solicitously offered her his home-made capsule with a glass of water and asked her to rest. His wife had taken the capsule with no suspicions, but was surprised at how quickly sleep overcame her. She had not even had time to walk up to bed before she was fast asleep.

As soon as she dozed off, he carried her down to the basement. During the day, he had ordered and received a large block of ice (it had been a challenge keeping his wife from knowing about it, but his luck had held at that point) from a factory that specialized in supplying ice for ice sculptors. They were quite surprised that he wanted the ice delivered to a basement rather than a room where one would hold a party, but he convinced them he was going to make several small sculptures rather than one large one.

He had spread a couple of blankets, quilts and comforters on the block of ice (he made sure they would not get wet because the top of the ice was covered in a plastic sheet). He then fashioned a noose out of rope he had picked up a while back in a hardware store. He slipped the noose over his wife's head, and carefully placed her in a sitting position on top of the block of ice. This part was not as easy as he would have like it, and he had to adjust the length of the noose several times to get it just right. But, finally, he managed to get it positioned so that the noose would not constrict around her neck until the ice melted a couple of feet or so. Mike had been proud of his ability to work things out perfectly, even if it took some time and effort. Perfect execution was the linchpin that made his whole plan come together and work!

He had then put a stool on its side next to the block of ice, and left for the airport.

The basics of Mike's plan were quite simple. His wife would sleep on the block of ice with a noose around her neck. As the ice melted, her weight would be transferred to the noose, which would asphyxiate her. And since she would be asleep when this happened, she would not be able to save herself. He did not have to be anywhere near her when it all happened if his calculations were correct. Perfect planning, perfect timing, perfect execution!

When he came back, things looked like they had gone exactly according to his plan. The ice had melted at approximately the rate he had predicted, and was, in fact, completely gone by the time he found the body. The sheets and quilts had protected the parts of his wife's body that were resting on the ice so that they weren't frost-bitten. She had indeed died of asphyxiation, while still deep asleep. The rope had made satisfying bruise marks around her neck, proving that she had been alive when the rope had choked her to death. And she had died late on Saturday evening, a time when he could establish beyond reasonable doubt that he was 2000 miles away, in California.

The perfect crime had been committed, except for some reason, the police weren't blown away by its perfection. In fact, on the contrary, they had firmly concluded that it was his doing, not his wife's.

At the end of this confession, the detectives charged Mike with murder and took him to a holding cell from the interrogation room. They gave him a burger to eat, and the cell had a cot to lie on. When Mike fell asleep, his dreams still had trains in them, but he was now running away from them rather than towards them. He was running towards the dark rather towards a bright light. And the dreams seemed to go on forever, with him never knowing whether the train hit him or not.

Mike awoke the next morning, slightly confused about his new surroundings. How did he get from the interrogation room to this cell? And then things came back to him in small and large pieces. He had admitted to murdering his wife. He had confessed to killing her. He had been pretty clever about his plan too. But something had not worked. The police had arrested him and managed to extract the confession from him. They were no doubt busy preparing their case against him with receipts from the hardware store for the rope, and the ice factory for the ice.

The detective, Steve, brought him breakfast along with a neatly typed up sheet of paper with his confession on it. Mike already knew he was defeated. His confession on tape was more than sufficient to have him convicted. The sheet of paper was just a formality. Mike read through the confession, remembering only the odd detail about his long and ranting confession in the interrogation room the previous evening. The confession could have been more succinct, but the details were all there, and mostly correct as far as he could tell. He signed the confession and returned the sheet of paper to Steve.

But Mike's mind was a whirlwind of confusion. Why had the police concluded that it was murder rather than suicide? The coroner had concluded that she had died only on Saturday night. He had found flurazepam metabolites in her blood, but that was to be expected since she had a prescription for the stuff, and took it regularly. She had died of asphyxiation by the noose, that is what the coroner's report said. What part of his plan had failed? Hadn't the planning been perfect? Hadn't the timing been perfect? And even if he did say so himself, he had executed the plan perfectly too. So, what had been the fatal flaw? He begged Steve to tell him how the police had figured it out. He wanted to know it now, not during his trial in court.

Steve looked at Mike with pity and said, "so you really want to know?" Yes, nodded Mike. Steve then said, "I guess there is no harm in letting you know now. Well, when we found her, your wife's feet were 28 inches off the floor. The stool was only 24 inches tall." A stool, a stool, the rest of my life for a slightly taller stool! Mike put his head in hands and took a deep breath. The large details were 90% of his perfect plan. He had just found out that the small details were the remaining 90% of his perfect plan!

The perfect crime requires perfect planning. And perfect timing. And perfect execution. The perfect crime also requires perfect measurements!

The End

Microsoft Access Tips & Tricks: Full Outer Joins

Joins are one of the essential features of relational databases. In fact, it would not be an exaggeration to say that relational databases owe most of their power to joins. A properly normalized relational database would be close to impossible to use without joining multiple tables. Only an extremely simple or simplistic database would be capable of producing any usable results without the use of joins between multiple tables.

If you are interested, you can find my earlier posts on finding the median, the mode, the geometric and harmonic means, ranking every row in a query, selecting random rows out of a table, calculating running sums and averages, calculating running differences, creating histograms, calculating probability masses out of given data, calculating cumulative distributions out of given data, finding percentile scores, percentile values, and calculating distinct counts.

There are five main kinds of joins that are commonly recognized. They are inner joins, left outer joins, right outer joins, full outer joins and cartesian joins. A join usually consists of two tables, but in general, joins can involve any number of tables. In this post, we will deal with all kinds of joins in general before we actually come to the solution of how to code up a full outer join in Microsoft Access.

There are two main ways to code up a join in SQL. One of these ways involves the actual use of the keyword JOIN in the query.

The common syntax for this type of join is as below:

select * from table1 INNER JOIN table2 on table1.keyfield = table2.keyfield

The SQL above obviously codes an inner join. By changing INNER to LEFT or RIGHT, you would be able to code a left or right outer join respectively.

select * from table1 LEFT JOIN table2 on table1.keyfield = table2.keyfield

You can also code left or right outer joins by explicitly mentioning the word OUTER in the join as below:

select * from table1 LEFT OUTER JOIN table2 on table1.keyfield = table2.keyfield

There is a second way to code up an inner join is by using a where clause instead of the actual term JOIN in the SQL. An example of a join that works this way is shown below:

select * from table1, table2 where table1.keyfield = table2.keyfield

Note that in each of these statements above, the two tables could be the same rather than two separate tables in the database. A join that involves joining a table with itself is referred to as a self-join.

So, how does a join actually work? This is clearer when analyzing the statement that uses a WHERE clause, so I will use it to explain how a join works.

What a relational database does when it encounters the SQL statement "select * from table1, table2" is as follows. The database pulls up the first row of table1, and pairs it up with each row of table2. It then goes back, pulls up the second row of table1, and again pairs it up with each row of table2. This process goes on until the database has paired every row of table1 with every row of table2. This kind of join is commonly referred to as a cartesian join or cross-product. If table1 contains row1 rows and table2 contains row2 rows, the result of this cartesian join or cross-product will contain row1 x row2 total rows.

In general, cartesian joins are not very useful. In fact, under most circumstances, cartesian joins can bring a database to its knees because of the resource-intensiveness of a cartesian join involving two large tables. Consider the fact that most tables that contain 10,000 rows would be considered modestly sized in a relational database. However, a cartesian join between two such tables would result in a result set that contains 100 million rows!

The WHERE clause in the second syntax is what converts a cartesian join into a different type of join. The where clause is applied to each row that would result from a cartesian join, and then the rows that return a true for the condition in the where clause, become part of the final result set. The other rows are thrown out. Thus, looking at the actual SQL above, we can see that the WHERE clause would cause the database would compare the keyfields of the two tables and only produce rows in the output where they match exactly. In most cases, this is exactly what we want from a join.

Obviously, all this is done without actually producing the result of the cartesian join first, so if you are sure that your where clause actually codes up an join that will produce a manageable number of rows in the output, it is safe to do it using the second syntax even when the tables involved are large.

This exact mechanism of how a join works is somewhat obscured by the syntax that uses the JOIN keyword in the SQL rather than the WHERE clause. This is one of the reasons why I sometimes prefer the second syntax over the first when I code up inner joins (the syntax is also easier to follow, at least for me). Unfortunately, it is not possible to produce outer joins using the syntax that uses a WHERE clause.

However, it is much easier to code up joins between multiple joins using the WHERE clause syntax. All you have to do is add the additional tables to the list of tables in the FROM clause of the SQL. In the absence of a WHERE clause, such an SQL statement would produce every row from the first table paired with every row from the second table, and paired again with every row from the third table and so on. The number of rows in the result set would be the product of the number of rows in each of the tables involved in the join. But, with the appropriate WHERE clause, you can make sure that only the correct combination of rows is produced in the output.

Now, you may think that when you use the WHERE clause, you can fine-tune the join to produce any combination of rows out of a cartesian join that you want. You are not just restricted to inner joins. And you may be thinking that this level of fine-tuning is not possible with SQL syntax that uses the JOIN keyword. In reality, this is not the case. What follows after the keyword ON in the syntax that uses the JOIN keyword is a boolean condition that is completely under your control (you can obviously do this only in SQL view in Access, not from the design view, which is very limiting). You can change that condition to anything that produces a true/false value, and the join would work (it will obviously include every row in the cartesian join for which the ON condition returns a true value). In fact, you can even call functions, do any number of mathematical calculations, etc. in the ON clause of a join just as you can in the WHERE clause of a regular query. This is very important to remember and take advantage of when appropriate. Most people do not know about this feature of an ON condition, that makes it as powerful as a WHERE clause.

To understand the differences between the different types of joins, let us consider two tables, TableA and TableB, with the data below:

TableA

ID    DataA
1     DataA1
2     DataA2
3     DataA3
4     DataA4
5     DataA5
6     DataA6
7     DataA7
8     DataA8
9     DataA9
10    DataA10

TableB

ID    DataB
6     DataB6
7     DataB7
8     DataB8
9     DataB9
10    DataB10
11    DataB11
12    DataB12
13    DataB13
14    DataB14
15    DataB15

An inner join between the tables above is coded in SQL as below:

select TableA.ID, DataA, DataB from TableA inner join TableB on TableA.ID = TableB.ID

or

select TableA.ID, DataA, DataB from TableA, TableB where TableA.ID = TableB.ID

The result would look as below:

TableA.ID    DataA    DataB
6            DataA6   DataB6
7            DataA7   DataB7
8            DataA8   DataB8
9            DataA9   DataB9
10           DataA10  DataB10

As you can see, the inner join only produces rows in the output where the keyfields (TableA.ID and TableB.ID) match exactly in both tables. As you can see, this is quite obvious in the WHERE clause syntax (the WHERE clause clearly tells one what the criterion is), not so clear in the JOIN keyword syntax.

A left outer join between the tables above is coded in SQL as below:

select TableA.ID, DataA, DataB from TableA left join TableB on TableA.ID = TableB.ID

or

select TableA.ID, DataA, DataB from TableA left outer join TableB on TableA.ID = TableB.ID

It is important to remember that in a left join, the table named in the query first is always the left table. The result of the left outer join above is as below:

TableA.ID    DataA    DataB
1            DataA1
2            DataA2
3            DataA3
4            DataA4
5            DataA5
6            DataA6   DataB6
7            DataA7   DataB7
8            DataA8   DataB8
9            DataA9   DataB9
10           DataA10  DataB10

As you can see, a left outer join, includes every single row from the left table (in this case, TableA, because it is named first in the queries above), and the data from the right table (TableB in this case, because it is named second in the queries above) when the condition in the ON clause is satisfied (where the two ID's match). Notice that a left outer join includes the results of an inner join when the ON clause is the same as that in an inner join.

Note that if you modify the condition inside the ON clause of a left outer join, the result would still contain all the rows from the left table. But data from the right table would be included only when the condition inside the ON clause returns a true value.

A right outer join between the tables above is coded in SQL as below:

select TableA.ID, DataA, DataB from TableA right join TableB on TableA.ID = TableB.ID

or

select TableA.ID, DataA, DataB from TableA right outer join TableB on TableA.ID = TableB.ID

It is important to remember that in a right join, the table named second in the query is always the right table. The result of the right outer join above is as below:

TableA.ID    DataA    DataB
6            DataA6   DataB6
7            DataA7   DataB7
8            DataA8   DataB8
9            DataA9   DataB9
10           DataA10  DataB10
11                    DataB11
12                    DataB12
13                    DataB13
14                    DataB14
15                    DataB15

As you can see, a right outer join, includes every single row from the right table (in this case, TableB, because it is named second in the queries above), and the data from the left table (TableA in this case, because it is named first in the queries above) when the condition in the ON clause is satisfied (where the two ID's match). Notice that a right outer join includes the results of an inner join when the ON clause is the same as that in an inner join.

Note that if you modify the condition inside the ON clause of a right outer join, the result would still contain all the rows from the right table. But data from the left table would be included only when the condition inside the ON clause returns a true value.

Note also that left and right outer joins change the results they produce depending on the order in which the tables are present in the query itself. So, it is important to keep the tables in the right order when one is coding up outer joins.

Before we see how a full outer join is created in Microsoft Access, let us see what the result should be for a full outer join first. We want not only data from both TableA and TableB when the key fields match, but also all the data from TableA and from TableB where they don't match. The result should look as below:

TableA.ID    DataA    DataB
1            DataA1
2            DataA2
3            DataA3
4            DataA4
5            DataA5
6            DataA6   DataB6
7            DataA7   DataB7
8            DataA8   DataB8
9            DataA9   DataB9
10           DataA10  DataB10
11                    DataB11
12                    DataB12
13                    DataB13
14                    DataB14
15                    DataB15

Unfortunately, SQL like below is not supported by Microsoft Access:

select TableA.ID, DataA, DataB from TableA outer join TableB on TableA.ID = TableB.ID

or

select TableA.ID, DataA, DataB from TableA full outer join TableB on TableA.ID = TableB.ID

So, it is time for some trickery! We notice that the rows in a full outer join contains all the rows from a left outer join and a right outer join, with the duplicate rows from both included just once instead of being included twice. So, all we need is a way to combine the outputs from the two queries and removing all but one copy of the duplicate rows. The UNION keyword provides us with exactly such a mechanism, so our solution to the problem of a full outer join in Microsoft Access is as below:

select TableA.ID, DataA, DataB from TableA left join TableB on TableA.ID = TableB.ID
UNION
select TableA.ID, DataA, DataB from TableA right join TableB on TableA.ID = TableB.ID

or

select TableA.ID, DataA, DataB from TableA left outer join TableB on TableA.ID = TableB.ID
UNION
select TableA.ID, DataA, DataB from TableA right outer join TableB on TableA.ID = TableB.ID

There are a few things to keep in mind about the solutions above. Notice that both solutions combine a left outer join with a right outer join. In both the joins, the tables are named in the exact same order. This is very important because left and right outer joins depend on the order in which tables are named to produce the results they produce. In fact, one can take advantage of this to create a full outer join without combining a left outer join with a right outer join. One can simply use two left or two right outer joins with the table order reversed in one of the queries to produce the same results:

select TableA.ID, DataA, DataB from TableA left join TableB on TableA.ID = TableB.ID
UNION
select TableA.ID, DataA, DataB from TableB left join TableA on TableA.ID = TableB.ID

Or

select TableA.ID, DataA, DataB from TableA right join TableB on TableA.ID = TableB.ID
UNION
select TableA.ID, DataA, DataB from TableB right join TableA on TableA.ID = TableB.ID

Also, notice that we are taking advantage of the property of the UNION keyword that eliminates duplicate rows in the result set. This makes sure that the rows that would be produced by an inner join between the tables are not repeated in the outer join. In fact, if one used UNION ALL instead of UNION to combine the two queries, then the rows that would be produced in an inner join would be repeated twice in the result of the outer join.

Another thing to keep in mind is that the use of the UNION keyword between two queries requires that both queries produce the same number of columns in their output (actually, contrary to the understanding of most people, UNION does not require the same data types for the columns in the two queries). Moreover, the column names used in the output are the same as the names or aliases used in the first query. So, please make sure the columns with the same meaning are lined up in both queries so that the results make sense.

Hope this post has been helpful in solving any problems you might have had with full outer joins in Access. If you have any problems or concerns with the queries in this lesson, please feel free to let me know by posting a comment. If you have other questions on Access that you would like me to address in future lessons, please feel free to let me know through your comments too. Good luck!

A Week With Some Computer Problems

If you work with computers, then you have had computer problems. Or you will! There is no escaping computer problems when you work with computers.

Most of my computer problems are self-made. I program computers for a living. As the saying goes, the computer is always right. Programmers are sometimes right. You can't argue with a computer. If it does something wrong, it is because you told it to do something wrong, not because it wants to do something wrong. So, when the computer is right and I am wrong, it is time for me to get into the deep and dark corners of my computer program and drive out the gremlins hiding there.

This past week, was gremlin-fest in program-ville. Especially programs-written-by-me-ville! The troubles started early in the week. The users of my programs are not very technical folks. Most of them have trouble finding their way around a spreadsheet (and I am talking about a spreadsheet with no macros or VBA or anything like that!). So, when something goes wrong with a program I wrote and support, they have no idea how to explain it in technical terms.

When the call comes in to me from the user, the symptoms are almost invariably as follows: The program is doing something wrong. It can take a bit of time for the user to explain to me how he came to that conclusion. If it is a good day for me, the user's conclusion is somehow wrong and I am able to explain that the result produced by the program is the correct result. At least I am able to convince the user that the result is what would be expected given the requirements of the program. That may then lead to the requirements being changed or added to, but at least I don't have to fix anything right away.

This week did not have any good days, unfortunately. I got a call on Monday morning, bright and early. It took a while to figure out what the problem was, but after a bit of investigating, the gremlin showed itself and I gave it the boot. Then another problem showed up on Wednesday. That problem is still being investigated because the users used a set of data to run the program on Tuesday evening that produced bad results. They have not been able to recreate bad results from other data they have had access to since then, and they did not think to save the data that produced the bad results right away. We may have to chalk it up to a gremlin that was passing through my program rather than planning on staying.

Hopefully, there will be no new problems in the coming week, and I can look back on this week and muse about how I earned my full 40 hours of pay, at least for that week!

But gremlins were afoot in other parts of the computing world too last week. My work computer usually stays on 24 hours a day, 7 days a week, for weeks on end. I don't like logging off all the systems I am logged onto at the end of each day and then logging back on at the beginning of each day. So, I leave my computer on at the end of each day, and when I come in to work in the morning, I pick up right where I left off the previous evening.

This week, for some reason, my email program (Microsoft Outlook, for those that are curious) started misbehaving. It stopped popping up reminders for the meetings in my calendar. I almost missed a couple of meetings because of this. I also noticed that even though I had set my computer up to lock itself after no keyboard or mouse inputs for 10 minutes, it did not do that. For some reason, my computer was lost in some timeless wasteland in the computing world!

In most cases, such lapses by the computer are easily rectified by rebooting the computer. So, when I left for home on Friday, I shut the computer down completely. I will restart it Monday morning and hopefully, the gremlins that have been plaguing it would have starved to death or otherwise decided to leave for warmer and more charged regions of the computing universe.

But things were a little funky at home too. I have three laptop computers at home. One of them is the first laptop I bought about 8 years back. Until then, I had used desktop computers, but I eventually tired of the incessant mess of wires and cords running every which way under the desk. So, I got rid of my desktop and bought a new Toshiba laptop using ebay.

Then a couple of years later, I bought another Toshiba laptop off ebay. My wife and I decided we each needed our own computers, hence the second computer. After a while, I ran out of disk space on this second laptop because I digitized all my video recordings on it. It was time for me to get another laptop and relegate this to a common computer that the kids could use. So, I bought a Gateway laptop with a 100 GB hard drive (the biggest available for laptops at that time).

Everything was fine for a while, but eventually, the second Toshiba's charger connection stopped working one fine day. Since the two Toshiba's used different batteries, there was no way to keep them both charged using one charger. The computer repair shop I took it to wanted $300 to replace the entire motherboard on the computer. I decided it had come to the end of its useful life.

So, I sold that computer on ebay for parts and bought an Acer laptop on sale for a ridiculously low price ($400 after all rebates were figured in). Everything seemed to be fine for a little while, but suddenly one fine day, the Gateway laptop's display went black. The backlight had failed on it. I was pretty close to running out of disk space on that computer too, so it was back to the shopping board for me.

This time, I got a Dell with a 250 GB hard drive. This computer I use as my personal laptop. The Acer is used as a common laptop in the living room by the kids. My wife continues to use the first laptop we bought even though it is showing its age. This week, it had more than its usual share of troubles as I got stuck repeatedly while browsing websites and was very slow overall.

I had to take it over for a good 2 hours, play around with every setting on it several times and reboot it a few dozen times to get it to work decently. My wife will be testing it out in the coming week to see if it continues working properly after this working over. She has a soft spot in her heart for this computer for some reason. It does not even have wireless internet, so it is wired to our home router pretty much on a permanent basis.

It is surprising that this computer has outlasted pretty much every other laptop that came into my home after it in the last 8 years. It has never had serious problems, and though it is slow, it works fine most of the time. If this week's troubles are the beginning of the end for this computer, it will certainly be missed.

Even though its LCD screen is the oldest, my wife and I agree that it looks the best among not just the computers we own right now, but among all the laptops we have owned, ever! And my work laptop is no exception to this either. The colors are bright and vibrant, and videos and movies look so much better on this laptop's screen than they do on the screens of the other laptops at home and work. The sound from the speakers on this computer is much clearer and better-sounding too. I thought technology was supposed to make things better, but I guess this is one more way computers can end up frustrating you! As manufacturers cut costs to make sure people get their technology fix for cheaper and cheaper, quality goes out the door too!!

I guess that is enough about my computer troubles for now. At least none of them affected my blog posting much. I published another post on Access, a short story and another lesson on Vedic Mathematics. After that came a post on PC Keyboards, and then a post on humorous warning signs.

My flag counter hit the magic number 100 this week. More countries keep coming to my blog for whatever reason, the latest being a visit from El Salvador. Maybe 100 is really the magic number where it all stops. Whether it does or not, I will let you know how it went next week! For now, there are chores to take care of, and I have to get ready to go to work for another week of nose to the grindstone!