> Benoît Minisini a écrit : > ... > > > I think you are mixing a lot of different things: > > > > - When storing a amount of money in memory, you store it in a Long > > integer in 1/10th of cents. For example, storing 1234,56€ will be stored > > as 123456 > > I'm gonna test that, but it implies more load of the DB server side to > convert from one format to the other. > > > - When displaying an amount of money, you use Format$(), or your own > > function. > > > > - When getting an amount of money from the user, you have to convert a > > string into an amount of 1/10th of cents. > > > > - When getting an amount of money from the outside, or exporting an > > amount of money to the outside, you must use an standard exchange format > > based on a string. > > This is not acceptable: DB must be able to directly process numbers, > not to loose 95% of the time to convert a string to a number and > vice versa (many of my process aren't done by GB but into stored > procedures) >
"Outside" means "out of your control", or "out of the program internals". If it is a stored procedure you wrote, it will manipulate the integer values directly of course. But if you have to send or receive currencies from another program, you must use a standard exchange format. > > So I don't see any problem with that. Why are you talking about telephone > > seconds? We are talking about money, aren't we? Or there is something I > > didn't understand? > > Yep, but some amounts can have many more decimals than others (in > telephony, seconds are usually invoiced with @ least 6 decimals and > sometimes 8), so mixing that with other number of decimals isn't easy. > > This is why definable decimals numbers are so important. > Again we are talking about currencies. What's the matter with telephony seconds? If you want to say that you have to store 1/1000th of cents, ro more, just choose a more precise format. With a Long datatype and using 1/1000000th of currency unit (!), you can store up to 4,6 x 10^12 units. That should be enough. -- Benoît Minisini ------------------------------------------------------------------------------ Return on Information: Google Enterprise Search pays you back Get the facts. http://p.sf.net/sfu/google-dev2dev _______________________________________________ Gambas-user mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/gambas-user
