Comments on: VFP: Not always fixed field structures

By: Rick Schummer

Rick Schummer — Thu, 02 Jul 2009 10:25:13 +0000

Subrat,

While your solution may not create errors, it certainly is not the best solution when you are completely changing the true value of the data.

By: Subrat

Subrat — Thu, 02 Jul 2009 10:07:41 +0000

USE TRANSFORM() FUNCTION TO SOLVE THIS PROBLEM.

FOR EX.

TRANSFORM(12345.1234,"999.99")

CAN FIT THE LARGE NUMBER 12345.1234
TO A 6.2 DIGIT FIELD WITH THE VALUE 0

By: Rick Schummer

Rick Schummer — Mon, 24 Jul 2006 19:04:26 +0000

Thanks for the additional discussion BOb. You are correct on the example. It is not until you round to a value with six significant digits.

** Works
REPLACE nCost WITH 99999.49

** Triggers data overflow error
REPLACE nCost WITH 99999.91

Any way you look at it, it will be something that can bite you in the behind when you least expect it.With disk space so inexpensive these days it makes sense to use large numeric fields.

By: Rick Schummer

Rick Schummer — Mon, 24 Jul 2006 18:55:02 +0000

I understand your concern Brian, but in this case the competancy of the programmer was the reason the problem was discovered. When converting data from one system to another programmers run into all kinds of problems. It is a natural course to follow. This is why we put in a check and balance system, to ensure the data is rock solid. The reason this problem was discovered was the numbers from the old system did not add up to the numbers in the new system.

So I am not accepting the error in calculation as you suggest. I am only accepting the behavior of the database product with a 20 year legacy of backwards compatibility, and conformancy to the DBF standard. You see, each database engine has its quirks and trade-offs. This happens to be one of them with DBFs.

When it comes to developing applications tracking numeric data, database developers add rules to the data to ensure the size of the data stored meets the guidelines of the columns in the data. That is why this problem rarely occurs and one of the reasons I have seen this a couple of times in more than 20 years of software development.

By: Anonymous

Anonymous — Mon, 24 Jul 2006 17:26:00 +0000

I hate to say this, but it is not a bug, but by design. N(5,2) means, Numeric, Length of five, percision of 2 decimals. This doesn't mean you MUST have two decimals. you can store 12345 in this field if you want.

What I think is a bug is if you do:

REPLACE MyField with 12345.1

and you still don't get a numeric overflow. But, 123.4 is a perfectly valid value for a 5,2 numeric field.

BOb Archer

By: Brian

Brian — Mon, 24 Jul 2006 10:16:00 +0000

I am not a database programmer so I don’t understand why that error is not a bug even if it “rarely” occurs. Either the calculation is correct or it’s not so why is it acceptable? If I were the client, I would be very concerned for a number of reasons, including; customer complaints, income reporting for tax purposes, etc. The acceptance of this calculation error by the programmer would also cause the client to question the competence of the programmer, the software and may lead to litigation against the company contracted to do the database programming.