Is the application written in the legacy language, or are you changing it, too? What language was/is it in?
The TCL language library has the ability to link functions to the engine. Such functions can affect coercion of the data into a different type, so that storage and presentation of the data need not be the same. Combining the functions with triggers and views might do what you need. Choose function names wisely, and the SQL could still be portable. Doug -----Original Message----- From: John Stanton [mailto:[EMAIL PROTECTED] Sent: Friday, September 30, 2005 2:49 PM To: sqlite-users@sqlite.org Subject: [sqlite] NEW DATA TYPE IN SQLITE First a disclaimer. I am a new user of SQLITE and have not dug very deeply into the code and literature, so my question may be trivial. I have a system from an emulation of a legacy commercial language processor which uses a very handy fixed point decimal number system. The numbers are of arbitrary precision and held in right justified display format. As you can imagine arithmetic on such numbers is not blindingly fast but for general commercial usage they are truly excellent. Commercial applications are not calculation intensive but are display intensive so the time saved in radix transformation and editing far exceeds the time lost in divisions. This type of fixed point display format number with automatic rounding makes it very easy to produce reports which balance to the penny and incredibly easy to generate financial reports. Such a number type does seem to fit in with the SQLITE concept of loose typing, since it is actually just a text field. There is actually an obscure ANSI standard which defines these numbers. How feasible and how difficult would it be to add this type to SQLITE? The numbers store as text strings so what is involved is adding the new numeric type and inserting the arithmetic functions so that they are recognized by the SQL processor? If anyone has a quick answer I should appreciate it. PS, with such fixed point numbers you would have 5.0 / 2.0 = 2.5 exactly.