Tag: databases

In 2014 we bought a car¹, registered in my name. It’s a little long in the tooth now and we’re thinking about what might replace it, but for the time being it’s a useful workhorse and especially valuable when we need to move the entire family and still have space for luggage.

This week, I renewed my driving license². While doing so, I was invited to connect the records of the vehicles I own. This would allow, for example, email notifications when my Vehicle Excise Duty is due on them.

How to register a car “wrong”

The newer of our two cars was easy to add: I provided the number plate; the website did some kind of lookup; and it was done. But when I tried to add the older car, I got an error message:

The website claimed that the details on my V5C – the vehicle registration certificate or “logbook” – didn’t match my personal information. So I pulled out the papers for both cars… and discovered that the personal information sections were identical. The front of a V5C has a section that shows your name and address, and on both my certificates looked the same: my name, followed by my address. So why was one failing to work?

I sat in a queue for their webchat service, and – after a lot of back-and-forth – the operator and I came to a conclusion about what was wrong: for this car only, my name had been entered into the “company name” field in their database, rather than the “name” field.

From the looks of things, this is what happened in 2014:

1. The dealership filled the V55/4 form to register the car to me.
2. The DVLA saw my unusual name³, figured “that can’t be a person’s name; it must be a company name”⁴, and put it into the “company name” field.
3. The DVLA database differentiates between company name and person name, but the paper version just prints whichever one is present at the top of the address: information is lost in the translation to paper.
4. So: the database was wrong, but the paper copy didn’t show that it was wrong.

Getting the problem fixed

Apparently if I send my V5C to them with the details “corrected”, with an accompanying letter explaining the the correction is to which field they should be storing the data in, then they’ll correct it within a month or so

And then they’ll issue me with a new paper copy. Which will, naturally, look identical to this one. The only change will be in their database.

What can we learn from this?

I wonder if there’s anything that could have been different to prevent this confusion? A simple change would be to improve the layout of the third page of a V5C certificate.

Perhaps instead of re-listing the name and address in the same format as on the front page, this page could list each field separately, perhaps with each alongside the corresponding field for changing it. This wouldn’t need much space, less than would be saved by consolidating submission instructions (which are repeated at least five times in some form or another, across the form).

There are other ambiguities and redundancies that could be cleared-up at the same time. For example, the company name field does double-duty as the title field, which is an unnecessary complication that I’m sure must make data entry harder. And the registration number and document reference number are duplicated many times on this page, even though the instructions prohibit separating the parts.

Maybe there’s something to be learned from this for all of us who work with databases and forms. Do you have any fields that serve double-duty? Do you produce output by concatenating fields in such a way that might result in ambiguous provenience? Do you have a process to validate that data has been entered into the right column? Are you unable to make changes without re-generating secondary resources (like paper hard copies), the the secondary resources are functionally unchanged?

But for now, I probably ought to get this form sent back to the DVLA. So they can change their database and send me back a near-identical form. Such bureaucracy!

×

×

×

×