COMMENT - Systems lack the necessary cash in their chips

When a software company claims it is doing something good, you know you have to check to see if the lips are moving. Most new features are old ones regurgitated. Most of the time we get given what the software company can actually deliver, and this rarely has any great relevance to what we really need.

Take currency as a good example of this. We have spreadsheets that can do 'currency' formatting. In the database world, you can flag a field to have a datatype of 'Currency'. And this is supposed to be the solution to our currency needs.

Well excuse me if I get annoyed at this.

All that has happened is that the database stuffs on a default two decimal places for you. Gosh, how clever.

Now imagine the following scenario. With the rise of Wans that span not only one country, but half of the European Union, even mid-sized organisations are being faced with some truly bizarre currency problems. For example, I was recently in Brussels, and I was using a client/server application written in Visual Basic. The back-end database was SQL Server. To check some data integrity, I just wired up the client to a database held in Milan. At this point, I thought we'd won the Euro Lottery. So many Belgian Francs!

Naturally, I quickly realised what had happened. The database held in Milan was storing currency values in Lire, not in Francs. My client application knew no better, of course - it was all just 'currency'.

I then sat down and thought about this a bit more carefully. The currency symbol you get on-screen is determined solely by the regional settings held in Control Panel. Change it to dollars, and your defaults change across the board. Browse a foreign database and you are completely desynchronised.

The only reason you are aware that Italians have Lire is because you know that already. Staggering though it might seem, there is no way of storing the fact that it is Lire in a Microsoft database. You would think that when you selected 'currency' for a database field, the next choice would be 'currency type' and that this information would be stored with your data? Of course you would, but it isn't.

Naturally, things won't actually get any better when we have the Euro everywhere. Some of us will still do business with countries outside the EU region, and will need to invoice and process in some foreign currency type as well as Euros.

The reason we have this nonsense is frighteningly simple. The Yanks don't think that currency is an issue. After all, everyone works in dollars, don't they?

While I was in Redmond recently, I took the opportunity of nailing a senior Microsoftie's head to the lunch table and proposed that it really was about time that Microsoft took the currency datatype seriously.

I also proposed the following. There should be a system-wide currency server service, accessible from a Control Panel icon if necessary. This would be terribly simple - it would accept a request for conversion between two named currency types, and take a value in. The server would then reply with the value in the designated destination currency type. That way, you could store data in one value, but view in another, safe in the knowledge that the conversion was about right. Such a server service was an ideal extensible object. A corporate might run one master currency server, and update the rates held in it in real time. It might go further and allow for 'buy' and 'sell' rates too, for currency trading companies.

In use, I could then store everything in the database in, say, Euros.

But if I selected Japanese Yen as the format option in Excel, the conversion between Euro and Yen would transparently happen as the data was surfaced up to the application.

Unfortunately, as was pointed out by the Microsoft person, who was turning a nice shade of purple at this point, it would require across-the-board modifications to Microsoft's tools, applications and server services.

And this would take at least one major revision of every item for it to come together as a workable solution.

This is indeed the case. But just because it is difficult is no reason why it shouldn't be sorted out. If Microsoft wants to be taken seriously as a player in the Wan marketplace, supplying tools and services spanning from desktop to distributed servers, then handling currency in a long-trousers fashion is very much an overdue issue.

Jon Honeyball is a computer consultant, software developer and IT journalist.