On 06/03/2012 16:01, Leyne, Sean wrote: > This is why BroadView hasn't made the move from Dialect 1. The numeric rules > imposed by Dialect 3 would have required a huge amount of re-coding and > testing to ensure that our calculations/reports generated the expected > results. > > BTW, unless I have missed something, there is no posting which has said that > Dialect 1 needs to be eliminated in order for the BLR version to be > increased. So, changing the BLR levels has no dependencies on the question > of on-going support for Dialect 1. The subject of dialects came up due to a > question from Alex about whether the support for the old BLR versions was > necessary for Dialect 1. > > > As for Dialect 1, it is my opinion that the Dialect 3 intermediate numeric > rules are half-baked (at best) and that until such time as they have been > have been made intelligent that support for Dialect 1 needs to be maintained > (do I hear a Dialect 4? == Dialect 1 math rules, plus 'new' Boolean, Date, > Time, Timestamp and INT64 datatypes). > > I think the solution (not hacks with dialects) to this problem is not difficult.
Firebird don't need to change the way it does numeric/decimal arithmetics and introduce another dialect leaving current and previous one for decades. Firebird is right on the way it does. So, add a new datatype NUMBER(x, y) who does BCD arithmetics like it's done in Oracle. No secret then. Everybody would be pleased without these dialect hacks which make a single thing to act in different ways. Adriano ------------------------------------------------------------------------------ Keep Your Developer Skills Current with LearnDevNow! The most comprehensive online learning library for Microsoft developers is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3, Metro Style Apps, more. Free future releases when you subscribe now! http://p.sf.net/sfu/learndevnow-d2d Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
