Have the Alpha5 folks given a reasion?

[Hansolo]

I am curious if the designers of Alpha5 understand the server limitation of evaluating numeric fields as 0 -zero- in place of Blank or NULL. Can anyone with the authority to speak for Alpha Software explain the rational for this design? What benefit they thought it provided?

If you read this forum it is littered with the bodies of those mathematically minded individuals that would like to use 0 -zero- as a number and not as the absence of a number.

I may be jumping the gun here as there may be a simple solution and there may in fact be a way to store no value in a numeric field or a date field for that matter. If so what is it? And no NULL.VALUE() does not provide this even when use in Operation Updates.

What type of databases are you all making out there where you do not have to distinguish a numeric -zero- from a blank field?

Thanks,

Chuck

[Lenny Forziati]

RE: Have the Alpha5 folks given a reasion?

The DBF format, which is the format used by Alpha Five, does not provide for storing null values. This is a limitation that goes back to the original DBF spec and is not something we have any control over.

With the client-server release, you will be able to use a non-DBF back-end. Depending on the back-end that you choose, you will gain the ability to store nulls.

-Lenny

[Hansolo]

RE: Have the Alpha5 folks given a reasion?

Thanks Lenny,

That is about as good a response to my question as I can get and I appreciate the candor.

Might want to add this to the FAQ or the help files in just the way you stated. If I had read your response eariler it would have saved hours of dead end effort for me and I bet many others.

Chuck

[Lenny Forziati]

RE: Have the Alpha5 folks given a reasion?

Chuck, you found out today that you're a year younger than you thought AND you want perfect documentation? Sheesh, some guys want everything :)

Seriously though, I'll pass your suggestion on to Ed, our wizard of documentation.

-Lenny

[Hansolo]

RE: Have the Alpha5 folks given a reasion?

Guess I was counting 0 -zero- as a year in my age. :-)

Seriously the documentation makes one think it is possible at least to the extent of experimentation but I guess if I had more experience with the DBF format I would have known.

Cheers,

Chuck

[Carol Lybrand]

RE: Have the Alpha5 folks given a reasion?

Found this topic by accident, but it is interesting. Could you clarify for me what this means, via an example or two? I'm pretty good at math, so hopefully I will understand what you're talking about ... if you give details. I don't want this problem to come up for me in future, if there's something I can do to avoid it.

The only thing I can think of that you may mean is that perhaps if you're looking for an average, e.g., then the null or blank numeric entries would not be counted. But couldn't you just use the total number of records in the database, range, or query, and it would force an accurate result?

I feel you must be referring to a completely different problem; so please explain further.

Thanks,
Carol in Atlanta

[Stan Mathews]

RE: Have the Alpha5 folks given a reasion?

For one....

Suppose you were evaluating records to validate that a sales tax rate had been entered. A zero value is possible. A null value would mean that no value had been entered.

As far as an Alpha table field value is concerned, you cannot tell the difference, except by visual examination.

[Hansolo]

RE: Have the Alpha5 folks given a reasion?

Great example and may I add..

1) Please enter the change in weight from last month to this month:

Well 185lb - 185lb = 0 so you enter 0 which is the same numerically as �0 = no entry by the user" according to Alpha5.

Wouldn't you like to know if there was no change vs. no data.

2) How about using a calculated field where Field1-Field2 = Field3. If field1 and field2 are the same number then field3 = 0 is valid and useful data. This is not the same as not entering data for field1 and field2 but field3 would still evaluate to 0 in Alpha5 (as would field1 and field2) which in this context is neither valid nor useful.

The real issue is the validity of the data in the numeric field. There is any number of reasons to accept the value in a database table�s field as 0 that could be both valid and useful information even and especially as the result of a mathematical expression. A blank or NULL that forces the table to store a numeric 0 in a field that is used to evaluate a real number is forcing an invalid expression of 0 in this context.

I take for example that many folks are using the expression �alltrim(str("value",250,2,"B"))� in a Display format for a textbox or label field in a grid to hide the fact that 0 appears otherwise. If you use the Hide if Blank (�B�) formatting when displaying your numeric data fields you are assuming that there is never an instance when that field may actually be 0 �zero-. This is a problem as a numeric field is to represent the set of all real numbers {-infinity " 0 " infinity}. Since 0 is a valid real number how can it also serve as a valid NULL or BLANK set.

Chuck