Well, yes, I more or less adapted the system to the way the users were accustomed to do their business. But using a single unit (at least, internally) does seem simpler.

I remember seeing some conversion program which understood common prefixes, like m for 1/1000, n for 1/1e9, etc. This might be an interesting addition to consider.

>I think we're going at it just about the same way, but here was my thinking...
>
>I chose to do mine with moving everything saved in SI numbers because that way you only have to do one conversion-- You need to figure out what measurement system they want, then divide your data by it to figure that out...
>
>I would do it only in meters or km, because you can find any distance in SI (say you store meters, they want km), by just dividing your number by 1000.
>
>The other reason for saving just one type of data (and this is mostly from a SQL viewpoint, I have yet to spend any time learning what there is to know about xml) is simplicity of your table. By having say, km, meters, and mm, you have to do some calculations to get the total number of meters so you can do a conversion to another type (ie meters = meters + (km*1000) + (mm*.001), and that added complexity doesn't do anything for your cause.
>
>By having more than one type of saved measurement input possible (inches or miles or feet or meters or km, or whatever), you will have to A) figure out what type the measurement is. (mile, yard, meter) B) move it to some standard measurement (meter), then C) Move it to the measurement you expect them to want (of course, you may get lucky, and they always want the type of measurement it's put in as, in which case this whole thing is null, just regurgitate what they gave you, and, well, this question would be silly in that case.
>
>
>
>Mark