We have just switched all our data from dBASE files to DBISAM with
the consequential changes to the Delphi programs that access the
data - it was far less painful than I expected and I should have
done it years ago.

The following query runs against our weekly stats table and to
give percentages of users running the various flavours of Windows
week by week since we started collecting stats. win95, win98 ...
are the number of users recorded for that particular OS

Select datadate,
(win95+win98+winme+win2000+winxp) Tot,
win95*100/(win95+win98+winme+win2000+winxp) W95,
win98*100/(win95+win98+winme+win2000+winxp) W98,
winME*100/(win95+win98+winme+win2000+winxp) ME,
win2000*100/(win95+win98+winme+win2000+winxp) W2K,
winXP*100/(win95+win98+winme+win2000+winxp) XP
from statist
where datadate>'2003-04-20'

This ran fine under BDE (different date format of course) but
doesn't work under DBISAM: the Tot column is correct, the other
columns are full of apparently random numbers.

Is there a fix?


--
Tony Bryer SDA UK  'Software to build on'  http://www.sda.co.uk
Shareware Industry Conference 2006 sponsor   www.sic.org

"Tony Bryer" <tonyb@sda.co.uk> wrote in message
news:VA.00000001.00635556@sda.co.uk...
>
> Select datadate,
> (win95+win98+winme+win2000+winxp) Tot,
> win95*100/(win95+win98+winme+win2000+winxp) W95,

Probably some data conversion problem, try a CAST(Win95) as Decimal, and/or
other changes that would force the correct data type for intermediate
fields.

Robert

Tony,

<< This ran fine under BDE (different date format of course) but doesn't
work under DBISAM: the Tot column is correct, the other columns are full of
apparently random numbers. >>

What are the data types for the various columns being used ?  Also, are you
using 4.24 build 1 ?

--
Tim Young
Elevate Software
www.elevatesoft.com

In article <0C96EA49-C8F1-4D64-8A97-FE6379D44E07@news.elevatesoft.com>,
Tim Young [Elevate Software] wrote:
> What are the data types for the various columns being used ?  

They are all integers, which I guess is where the problem is coming from.
Presumably the BDE was implicitly changing them to floats (or now I think
about it, dBASE don't distinguish between integers and floats, integers
are just numerics with no dps). Should I use the Alter Table utility to
change them to floats and will the data be preserved?

> Also, are you using 4.24 build 1 ?

Yes

Supplementary question: in the Utility program, Alter Table option, there
is a column headed size which just says '0' and if you change it is
changed back. What is the significance of this?

--
Tony Bryer SDA UK  'Software to build on'  http://www.sda.co.uk
Shareware Industry Conference 2006 sponsor   www.sic.org

Tony Bryer wrote:
....
> Select datadate,
> (win95+win98+winme+win2000+winxp) Tot,
....

Is it possible that one of these fields is NULL?

Ralf

Tony,

<< They are all integers, which I guess is where the problem is coming from.
Presumably the BDE was implicitly changing them to floats (or now I think
about it, dBASE don't distinguish between integers and floats, integers are
just numerics with no dps). Should I use the Alter Table utility to
change them to floats and will the data be preserved? >>

Hmm, I tried this query:

Select (win95+win98+winme+win2000+winxp) Tot,
win95*100/(win95+win98+winme+win2000+winxp) W95,
win98*100/(win95+win98+winme+win2000+winxp) W98,
winME*100/(win95+win98+winme+win2000+winxp) ME,
win2000*100/(win95+win98+winme+win2000+winxp) W2K,
winXP*100/(win95+win98+winme+win2000+winxp) XP
from statist

with a table that defined all of the win* columns as integers (32-bit, not
smallints).  They contained the following values:

INSERT INTO "statist" VALUES (20, 30, 100, 200, 400);

and I got this result:

750, 2.66666666666667, 4, 13.3333333333333, 26.6666666666667,
53.3333333333333

The figures I'm getting seem to be correct.  What values are being used in
the table that you have ?  I suspect that there is an integer overflow
condition of something similar going on.

<< Supplementary question: in the Utility program, Alter Table option, there
is a column headed size which just says '0' and if you change it is
changed back. What is the significance of this? >>

The Size column is only used for string fields, byte fields as a length
indicator, or as a scale indicator for BCD fields.

--
Tim Young
Elevate Software
www.elevatesoft.com

In article <396F679A-EE7E-46E3-9D1E-BD14F7F0AAC1@news.elevatesoft.com>, Tim
Young [Elevate Software] wrote:
> The figures I'm getting seem to be correct.  What values are being used
> in  the table that you have ?  I suspect that there is an integer
> overflow condition of something similar going on.

Cracked it, and sorry for wasting your time. Unlike BDE DBISAM is returning
display values to the grid with 13 decimal places, and my default column
width does not accommodate this. What I was seeing was the last seven or so
figures of the result - see http://www.sda.co.uk/query.png . All became
clear when I manually resized a column.

Putting a round() around each result has solved everything.

--
Tony Bryer SDA UK  'Software to build on'  http://www.sda.co.uk
Shareware Industry Conference 2006 sponsor   www.sic.org

Tony,

<< Cracked it, and sorry for wasting your time. Unlike BDE DBISAM is
returning display values to the grid with 13 decimal places, and my default
column width does not accommodate this. What I was seeing was the last seven
or so figures of the result - see http://www.sda.co.uk/query.png . All
became clear when I manually resized a column. >>

Ahh, that will do it.  I'm glad you found the problem.

--
Tim Young
Elevate Software
www.elevatesoft.com