Can't open DBF table

[Chris]

Hi Dimitar,

I agree, if it is a widely used "feature", then we need to look into it. Can some more VFP develoeprs step in here please, so we can hear some more opinions?

[robert]

Dimitar,

We do support Nullable fields in the DBFVFP driver (our VFP compatible DBF driver) as well as the other VFP types such as Integer (with autoincrement), DateTime, VarBinary etc.
And it is not impossible to implement this strange behavior for numeric columns as well.
But I would really like to hear from other VFP developers if they think we should support this.

Robert

[kevclark64]

I've worked in VFP for decades and have never relied on this odd behavior regarding overflows for anything and I can't imagine a situation in which I would. Of course, that doesn't mean no situation exists in which someone does rely on it.

VFP is not consistent in handling overflows because if you use REPLACE to try to put 10000 in a N(3,2) field you will get a numeric overflow error but if you use UPDATE or INSERT you won't. That doesn't make any sense to me but perfect compatibility would require duplicating that behavior as well I guess (assuming inline SQL is supported at some point).

So it comes back to the overall question of exactly how much should X# recreate things which arguably don't make sense. I don't have an answer for that.

[Eric Selje]

I've never had or seen a table that needed a N(3,2) field, and I would never think to rely on this "bug" in production.

Eric

[pluisje]

I second that.
Never saw it and i'll never use it in this way.

[FoxProMatt]

About 5 years ago when upsizing my data from DBF to Sql Server, I discovered that I had a few records here-and-there in a few tables where this situation existed, but it was not intentional that I had allowed for it in my code base; it just happened somehow.

I believe my fix was to increase the field width in Sql Server on the left side of the decimal so I would not lose data values.

So, my point is that people may have this situation in some DBF's and not even know about it, nor was it intentional, as that's what happened to me.

[dexter]

The following sentence is copied from VFP help regarding Numeric field types:

"In fields with Numeric data type, the length of the decimal portion is determined at design time when you create the field. The length of the decimal portion is part of the total length. For example, if you specify a length of 6 for a numeric field and a decimal setting of 4, the field can store values up to 9.9999."

This clearly states what has been found is clearly a bug. The problem is what do you do when you find such case in X#? Why the DBF is considered corrupt and what would happen if you have N(5,2) having a value that does not exactly match the structure (i.e 10000)?

Dimitar

[robert]

Dimitar,

The DBF is considered "corrupt" for the N 3,2 field because our driver validates the DBF header and sees this as an invalid field definition.
If you change the field definition to N 4,2 and assign large values (> 9.99) in VFP and then open the DBF inside X# then the value will be read as you would expect.
When you write a value > 9.99 in X# then we will format the number with STR(newValue,4,2) and this will generate a string "****"

Robert

[dexter]

Thanks Robert,

That make sense. Its not unmanageable our side for sure (I mean determining fields with bad length) and update accordingly.

I'm surprised you keep entering **** for overflowed values. I know its STR who produces it but this cost more troubles than benefits. Do you consider throwing exception in this scenario?

Dimitar

[robert]

Dimitar,
I have to correct myself. Str() will generate the "****". Writing to the DBF will generate a runtime error: Data width error.
Robert