Discussion:
Translate Error. Value out of bounds
(too old to reply)
John Noble
2008-11-17 09:53:05 UTC
Permalink
Im trying to create a field in a table that is numeric 5.2. with a default
value of 0. I save the table and everthing is OK. If I try and save the
table again I get a 'Database Engine Error: Translate Error. Value out of
bounds: C:\....\Tem57.tmp'.

If I change the default value back to null everything is OK. Why can't I
have a default value of 0. The problem does not appear to happen when using
a wider field size eg 10.2. To solve the problem I would have made the
fields wider but in some case I cant because the values represent a
percantage (up to 100.00).

Any ideas?

J
Mervyn Bick
2008-11-17 10:36:03 UTC
Permalink
Post by John Noble
Im trying to create a field in a table that is numeric 5.2. with a default
value of 0. I save the table and everthing is OK. If I try and save the
table again I get a 'Database Engine Error: Translate Error. Value out of
bounds: C:\....\Tem57.tmp'.
If I change the default value back to null everything is OK. Why can't I
have a default value of 0. The problem does not appear to happen when using
a wider field size eg 10.2. To solve the problem I would have made the
fields wider but in some case I cant because the values represent a
percantage (up to 100.00).
It works for me using dBase 2.6.0.1. What version of dBase are you
using? Could you put together a little example program showing this?

As an aside, there is no reason, other than wasting a little bit of disk
space, why one couldn't use a numeric field of length 10, decimals 2, to
store a persentage.

Mervyn.
Mervyn Bick
2008-11-17 20:12:36 UTC
Permalink
On Mon, 17 Nov 2008 20:52:23 +0200, Bruce R. Roland
John
FWIW I have run into and found that an appropriate sounding width for
numeric data fields in a database always seem to give me trouble if I do
not allow at least an extra width of 1 to accommodate the decimal point.
I can't remember where it's documented and it is so well hidden that I
can't find it now but it is there somewhere. <g> The length needs to
include the decimal point and the minus sign if one is likely to store
negative values ie to store values between -999.99 and 9999.99 the field
needs a length of at least 7 with 2 decimals. Back in the days of dBase
II when data was stored on 135kb floppy disks it was important to optimise
table size but today when entry-level harddrives start in the Gb range I
never bother to change the default length of 10 for numeric fields unless
I'm dealing with BIG numbers or if I was to expect millions of records.
(Never had one of those yet. <g>)
For example you stated that you were using this numeric field to store a
percentage with two decimals (5,2). That would presumably allow for
three(3) whole digits and the two decimal values (i.e. 100.00 for
100%). However in my experience DBase will have problems with the value
100.00 in a field with a width of 5,2 because of the decimal (it needs
its' own space) and so rather than 5,2 for 100.00 I need to make my
field width 6,2 which then works fine.
I have seen dbase also display a number such as 100.00 as "**.**" when I
use the 5,2 width instead of the 6,2 width as well.
dBase will store -100.00 in a n(5,2) field as -100 and it will store
100.00 as 100.0 without throwing an error or resorting to asterisks.

In an earlier reply to John I noted that I couldn't reproduce the
translate error that he was experiencing. Since then I've been playing
with this a bit more and I managed to generate the error by trying to save
a value that was substantially too big for the field and the field was too
small to hold the value in scientific notation. I guess that's what the
translation error is about.

If a number is too large for the field, dBase will either store it as
asterisks, in scientific notation or if can't use one of those it throws
the "Database Engine Error: Translate Error. Value out of bounds"
error. I haven't, however, been able to pin down the boundaries as I
don't have the time at the moment to tackle this methodically but it
looks as if dBase will only use scientific notation if the field length is
7 or greater. I was able to generate the asterisks by using a value that
was too big for the field but I haven't been able to determine at what
point dBase will change from asterisks to the error message.

The answer to the whole problem is to make sure the field is big enough in
the first place. <g>

Mervyn.
Bruce Beacham
2008-11-18 16:03:55 UTC
Permalink
FWIW I have run into and found that an appropriate sounding width for
numeric data fields in a database always seem to give me trouble if I
do not allow at least an extra width of 1 to accommodate the decimal
point.
I allow 1 to accommodate the potential negative.


Bruce Beacham
Mervyn Bick
2008-11-17 18:58:50 UTC
Permalink
Post by Mervyn Bick
It works for me using dBase 2.6.0.1. What version of dBase are you
using?
2.6.1.5> Could you put together a little example program showing this?
I have attached the table in question. I tried to add a numeric field #49
called KgPrice (5,2) with default value of 0. After I save it then save
it again (Ctrl + S) I get the error
I'm at a loss. I had no problem adding the field. Ctrl-s saved the
modified table. Further use of ctrl-s appeared to have no effect at all.
The existing records both had 0.00 in the field. I added a record in a
form and the correct value was saved to the field.


Structure for table C:\dUFLP\Examples\dailyorders.dbf
Table type DBASE
Version 7
Number of rows 3
Last update 2008/11/17
-------------------------------------------------------------------------
Field Field Name Type Length Dec Index
1 orderRef NUMERIC 10 N
2 orderDate DATE 8 N
3 orderTime CHARACTER 5 N
.........
47 transportPencePerKg NUMERIC 10 2 N
48 recordtype CHARACTER 2 N
49 kgprice NUMERIC 5 2 N
-------------------------------------------------------------------------
** Total ** 320


Mervyn.
Bruce R. Roland
2008-11-17 18:52:23 UTC
Permalink
John

FWIW I have run into and found that an appropriate sounding width for numeric data fields in a database always seem to give me trouble if I do not allow at least an extra width of 1 to accommodate the decimal point.

For example you stated that you were using this numeric field to store a percentage with two decimals (5,2). That would presumably allow for three(3) whole digits and the two decimal values (i.e. 100.00 for 100%). However in my experience DBase will have problems with the value 100.00 in a field with a width of 5,2 because of the decimal (it needs its' own space) and so rather than 5,2 for 100.00 I need to make my field width 6,2 which then works fine.

I have seen dbase also display a number such as 100.00 as "**.**" when I use the 5,2 width instead of the 6,2 width as well.

Again, I presume this is because of the decimal and that you need to allow an extra space of width for the decimal point (i.e. 100.00, while it actually has only 5 digits needs a width of 6 - 5 for the five digits plus 1 for the decimal point - to store the value properly).

Hope this helps.

Bruce
unknown
2008-11-18 09:10:13 UTC
Permalink
On Mon, 17 Nov 2008 13:52:23 -0500 Bruce R. Roland
Sender: Bruce R. Roland <***@velocity.net>
wrote the following in:
Newsgroup: dbase.programming
Post by Bruce R. Roland
John
FWIW I have run into and found that an appropriate sounding width for numeric data fields in a database always seem to give me trouble if I do not allow at least an extra width of 1 to accommodate the decimal point.
For example you stated that you were using this numeric field to store a percentage with two decimals (5,2). That would presumably allow for three(3) whole digits and the two decimal values (i.e. 100.00 for 100%). However in my experience DBase will have problems with the value 100.00 in a field with a width of 5,2 because of the decimal (it needs its' own space) and so rather than 5,2 for 100.00 I need to make my field width 6,2 which then works fine.
I have seen dbase also display a number such as 100.00 as "**.**" when I use the 5,2 width instead of the 6,2 width as well.
Again, I presume this is because of the decimal and that you need to allow an extra space of width for the decimal point (i.e. 100.00, while it actually has only 5 digits needs a width of 6 - 5 for the five digits plus 1 for the decimal point - to store the value properly).
See the OLH on Table designer fields:

"You can set decimals to a maximum of 2 less than the width value you define. The total width must
be 20 characters or less. This includes decimal settings, the decimal point, and an optional minus
sign."

See the OLH on SET DECIMALS:

"Excess digits are rounded when a number is displayed. For example, with the default setting of two
decimal places, the number 1.995 is displayed as 2.00."


Ivar B. Jessen
Bruce R. Roland
2008-11-19 01:46:38 UTC
Permalink
Ivar

Thanks for the input. this brings two things to mind. First, with respect to the rounding I did have some trouble with that as well though I did not mention it in my post. I had found precisely what you had said with respect to allowing extra width to solve this problem. Sometimes the best learning curve is the one with which you struggle to find a solution through trial and error.

Second, I often also find my self saying "I know I saw that somewhere" but often have difficulty finding the thing again. To some degree this speaks RE the OLH and its organization (i.e., often the answer is there - its just hard to find it). Your notation on the decimal is something I found out through trial and error but I was not aware that one needed to also allow for the "-" sign as wel. I don't think I have ever had to use this and so have never had problems with that but it certainly is good to know should I ever see that.

Again, Thanks for the info.

Bruce

Loading...