Login ProductsSalesSupportDownloadsAbout |
Home » Technical Support » DBISAM Technical Support » Support Forums » DBISAM Enhancement Requests and Suggestions » View Thread |
Messages 1 to 10 of 12 total |
EDBManager - display of decimals |
Fri, Sep 4 2009 4:06 AM | Permanent Link |
Roy Lambert NLH Associates Team Elevate | Any chance of EDBManager displaying the decimals even if they happen to be zero ie 17.00 not 17?
Roy Lambert |
Fri, Sep 4 2009 10:31 AM | Permanent Link |
Tim Young [Elevate Software] Elevate Software, Inc. timyoung@elevatesoft.com | Roy,
<< Any chance of EDBManager displaying the decimals even if they happen to be zero ie 17.00 not 17? >> What data type are you using ? DECIMAL types should already be formatted, and FLOAT types don't currently use a specific precision (something that will be changing soon). -- Tim Young Elevate Software www.elevatesoft.com |
Fri, Sep 4 2009 11:05 AM | Permanent Link |
Roy Lambert NLH Associates Team Elevate | Tim
><< Any chance of EDBManager displaying the decimals even if they happen to >be zero ie 17.00 not 17? >> > >What data type are you using ? DECIMAL types should already be formatted, DECIMAL(20,2) >and FLOAT types don't currently use a specific precision (something that >will be changing soon). Err that might cause a problem, but I'm sure you'll be able to tell me an acceptable way round it. SCRIPT(IN Height FLOAT) BEGIN DECLARE HeightInMetres FLOAT; DECLARE HeightHeight VARCHAR; SET HeightInMetres = Height / 100; SET HeightHeight = CAST(HeightInMetres * HeightInMetres AS VARCHAR); BEGIN EXECUTE IMMEDIATE 'ALTER TABLE BodySize DROP COLUMN _BMI'; EXCEPTION END; EXECUTE IMMEDIATE 'ALTER TABLE BodySize ADD COLUMN _BMI DECIMAL(19,1) COMPUTED ALWAYS AS ROUND(_Kilos / '+HeightHeight+' ,1)'; END Without using FLOAT (I originally tried decimal(19,3)) I couldn't get the calculation accurate. The divisor it added (HeightHeight) was sufficiently out that I got 33.6 instead of 34.1 as the value of the column for the one row I can remember. Roy Lambert |
Fri, Sep 4 2009 12:58 PM | Permanent Link |
Tim Young [Elevate Software] Elevate Software, Inc. timyoung@elevatesoft.com | Roy,
<< DECIMAL(20,2) >> Okay, we've got an OnGetText event handler that is overriding this. I'll make sure that this is corrected in the EDB Manager. << Without using FLOAT (I originally tried decimal(19,3)) I couldn't get the calculation accurate. The divisor it added (HeightHeight) was sufficiently out that I got 33.6 instead of 34.1 as the value of the column for the one row I can remember. >> Did you try using DECIMAL(19,4) ? 4 decimal places should be enough precision if you want the result to use 1 decimal place. -- Tim Young Elevate Software www.elevatesoft.com |
Fri, Sep 4 2009 1:20 PM | Permanent Link |
Roy Lambert NLH Associates Team Elevate | Tim
I actually tried 3 but that didn't work and I was muttering about how it would be nice to have the same capability as with VARCHAR and not have to bother and I suddenly realised FLOAT did just that. As with a "no length required" VARCHAR I can see "variable decimal precision" being useful. Roy Lambert |
Fri, Sep 4 2009 1:47 PM | Permanent Link |
Tim Young [Elevate Software] Elevate Software, Inc. timyoung@elevatesoft.com | Roy,
<< As with a "no length required" VARCHAR I can see "variable decimal precision" being useful. >> That's what FLOAT does now. The missing ingredient is being able to say that you want the FLOAT values to only be 2 decimal places, etc. and have EDB do the rounding during assignment, etc. -- Tim Young Elevate Software www.elevatesoft.com |
Sat, Sep 5 2009 4:01 AM | Permanent Link |
Roy Lambert NLH Associates Team Elevate | Tim
><< As with a "no length required" VARCHAR I can see "variable decimal >precision" being useful. >> > >That's what FLOAT does now. I know >The missing ingredient is being able to say >that you want the FLOAT values to only be 2 decimal places, etc. and have >EDB do the rounding during assignment, etc. I'm obviously missing something here. If it does that where's the difference between FLOAT and DECIMAL? Roy Lambert |
Sat, Sep 5 2009 11:01 AM | Permanent Link |
Tim Young [Elevate Software] Elevate Software, Inc. timyoung@elevatesoft.com | Roy,
<< I'm obviously missing something here. If it does that where's the difference between FLOAT and DECIMAL? >> The difference is that one is a floating-point value that can have a much higher precision than the other that is *not* a floating-point value. DECIMAL values are internally implemented as Delphi Currency types, with a maximum scale of 4 decimal places. This also means that calculations involving the DECIMAL types don't use floating-point instructions, but rather integer instructions. -- Tim Young Elevate Software www.elevatesoft.com |
Sun, Sep 6 2009 3:50 AM | Permanent Link |
Roy Lambert NLH Associates Team Elevate | Tim
OK, so are all FLOATS going to need a precision? If so what happens to tables / triggers etc that don't have one specified? Roy Lambert |
Tue, Sep 8 2009 12:33 PM | Permanent Link |
Tim Young [Elevate Software] Elevate Software, Inc. timyoung@elevatesoft.com | Roy,
<< OK, so are all FLOATS going to need a precision? >> No, it will be optional, just like with VARCHAR in SQL/PSM. -- Tim Young Elevate Software www.elevatesoft.com |
Page 1 of 2 | Next Page » | |
Jump to Page: 1 2 |
This web page was last updated on Wednesday, August 14, 2024 at 07:31 PM | Privacy PolicySite Map © 2024 Elevate Software, Inc. All Rights Reserved Questions or comments ? E-mail us at info@elevatesoft.com |