Icon View Thread

The following is the text of the current message along with any replies.
Messages 1 to 5 of 5 total
Thread Displaying bad values
Wed, Jan 10 2007 9:16 AMPermanent Link

This is one for anyone to consider please: I have an application that
handles numbers. The user is able to select data from a spreadsheet, and
then paste it into the application, which stores it in a DBISAM database -
columns being floating point values.

Now, users being users, they sometimes have bad values, like "N/A" or
"ONE". I'd like to be able to manage this better, and seek thoughts on
what others do or ways around it.

In the current release, I just store 0.0 in the value, which as it happens
can't be used and the user has to fix it before continuing. One suggestion
is that I should use NULL instead ("missing data"). But the ideal would be
that the data "looks" like the original data in the grid (dev-express grid
if it makes any difference).

The way I think it could work, is to have an event for each field in the
GetDisplayText (or similar). If it the value is NULL, then I'd read from
another table on a row/column key to find the original value, and then
return that. Is it possible? Does this make sense at all?

Another idea I had was to add a memo field that was hidden, and add
original values to that if they can't be converted. Then if any were
output, I'd simply display the column so they can see the info, but that's
not at all nice really.

Just one complication to mention - the user can also add text and date
values, but the text is not an issue, and the dates would use the same
scheme I guess.

I look forward to your thoughts on this.

/Matthew Jones/
Wed, Jan 10 2007 12:11 PMPermanent Link

Roy Lambert

NLH Associates

Team Elevate Team Elevate

Matthew


It depends what your app does with the data. If it simply displays it then I'd recommend using a text field and just storing what the user enters and then have some calc fields displayed.

If you do any processing or sorting using the data this wouldn't be a goer.


Roy Lambert
Wed, Jan 10 2007 4:49 PMPermanent Link

The numbers are needed as numbers, and speed is important, so I do need to
have them as numbers. One (rejected) idea was to have a string and a
number for each value. The string would be displayed and the number used.
The two obvious problems are that the text and (hidden) number would get
out of step, and the text would have to be stored either as a long string
to cope with the maximum, or as a less efficient memo.

I'm not prepared to lose the speed of raw numbers, plus the fact that the
product is all written around the db as is, and the data validation only
applies to the "data entry" part.

/Matthew Jones/
Wed, Jan 10 2007 5:37 PMPermanent Link

Tim Young [Elevate Software]

Elevate Software, Inc.

Avatar

Email timyoung@elevatesoft.com

Matt,

<< The way I think it could work, is to have an event for each field in the
GetDisplayText (or similar). If it the value is NULL, then I'd read from
another table on a row/column key to find the original value, and then
return that. Is it possible? Does this make sense at all? >>

That's what I would do.  We use OnDisplayText in lots of places in the EDB
Manager to affect the way BLOB fields, etc. are displayed in the grid.

--
Tim Young
Elevate Software
www.elevatesoft.com

Thu, Jan 11 2007 6:50 AMPermanent Link

Excellent - useful to know it actually can be done rather than just in
theory.

/Matthew Jones/
Image