I was in the offices of a client in Brussels, Belgium, last week. My client has its headquarters there and offices in Milan, Italy; Madrid, Spain; and Lisbon, Portugal--it's a small but successful Pan-European organisation. Naturally, a computer WAN joins the offices. Like many companies, my client runs Banyan VINES but is seriously considering Windows NT.
I was working on SQL databases and issuing queries against a SQL Server box in Milan. Whatever I did, I couldn't get sensible results out of the system. The application is trivial--an Access 95 front end talking via Open Database Connectivity (ODBC) to SQL Server 6.5. With a host of servers in different countries to choose from, I tried to run the app on the local server in Brussels and it worked fine. But point the app at Milan, and Foom! It fell apart. Point the app at Madrid or Lisbon, and I had equal but different problems.
Then the solution hit me. The problem was in a currency field. It was throwing hilariously silly results onto my query form. Although the databases understood the concept of currency, they didn't know which currency I was dealing in. So the application displayed my Italian lira with the Belgium franc symbol, but with far too many numbers to be credible. (The Italians do love a currency measured in micro-units.)
The application, of course, thought it was getting currency and formatted itself accordingly. But at no point did the application actually know, let alone warn me, that the currency definitions at both ends of the WAN link were different.
This situation is madness. How are we supposed to work in a WAN environment spanning several countries when currency is such a brain-dead concept? The reason for this disaster is simple: People in America think only in terms of dollars. Anything else is foreign and hence not worth worrying about. I bet most databases containing currency data in the US happily assume that the world works in dollars only, and that almost no one in the land of super-cheap petrol (sorry, I mean gas) does a query that joins an English pound sterling to a French franc to an Italian lira.
But over half of Microsoft's sales are global! And none of its products understand currency as a concept in any meaningful way.
I have a solution that Microsoft can implement in the OS. A database that stores currency values can include a field to indicate the type of currency. This way, you know that the value 2000.00 means $2000.00 not £2000.00. A huge leap forward, this currency identifier can let you know what currency you're looking at, preventing the vagueries of your local desktop national settings from overriding reality.
Let's take this idea further. Create a currency server that runs on the machine and receives conversion queries through an open API. The server can receive the number, the original unit of currency, and the required unit of currency. A currency server can use a call such as ConvCurrency( 2000, USDollar, OutputValue, Sterling) to convert the currency from dollars to sterling for display purposes. In the currency server, a table that a simple desktop applet in Control Panel can configure will let you manually update the conversion rates. All applications (Access, Excel, SQL Server, etc.) can use this currency server as a singular common repository of currency conversion information.
Let's go forward again. Because Microsoft continually sings the praises of Distributed Object Linking and Embedding (OLE), the currency server can run on an NT server on your network. All of your currency calls can route through that networked resource. And this configuration can give a singular point of update for all currency conversion rates--allowing a realtime moment-by-moment update, if necessary.
And for the power banking users, let's allow for commission offsets in the server. That way, you can automatically add the buy or sell commission rates as appropriate.
The key point is this: We need a currency server that runs as an open and published OLE automation API and lets you have the size and scope of server you require. And you can always know what currency you are looking at.
I can think of no excuse for this conversion nonsense. If Microsoft wants its products to be taken seriously in the financial context of the world stage, the time has come to put its currency house in order. Oh, and a note to Mr. Gates--email me to negotiate the rights to the idea. Thanks!
Foot, Meet Gun
OK, so the idea was sound enough: Microsoft launches FrontPage to
the world by giving it away free on the Web. The program has a time bomb that
expires at the end of June, by which time Joe Public can buy the commercial
version from a local software emporium. Brilliant.
Boy, did it fall apart in Europe. Microsoft screwed up big time with this release. The company has no shrinkwrap version--Microsoft is not manufacturing FrontPage at its Dublin, Ireland, plant, but instead is importing the program from the US. Microsoft has no FrontPage stock in Europe, and the time bomb has gone off. The company does have a fix (all 7MB of it!), but it's not on Microsoft's Web site--you have to call a crummy Microsoft BBS to get it. To make matters worse, Microsoft makes the fix available only two days before the imposed expiration date, and no one knows about it or where to get it.
Anyone seen a more pure and perfect example of how to unravel all that goodwill in one easy step? And Microsoft's marketing people get paid to do this?
Future Conferences
Thinking of attending a conference? Here are some dates for your
diary. The Visual C++ Developers Conference is on 4 to 6 November in London,
England, and 11 to 13 November in Frankfurt, Germany. For more details, check
out www.bearpark.co.uk/eve.html.
Given that flying around Europe is often more expensive than flying to America, note that Netscape is holding its second Internet Developer Conference in New York on 16 to 18 October. Last year's conference was in San Francisco, and Netscape's managed to leap 3500 miles to the east for this year's conference. Maybe the conference will make another 3500-mile hop over The Pond to Europe next year.