-
Handeling Blank Dates
I have a file that contains a date field. Sometimes this date is blank and other times it's not. In my validation routine, I first check for null then for a valid date. If no date exists I simly write a null field to file. But I'm afraid later on if this field gets loaded into a timedatepicker or another control that requires a valid date, I'm gonna have problems. I know I clould handle it when it loads and not even sent it to the control, but I was wanting some feedback first.
So whats the proper way to write a blank date?
Last edited by rrjii2000; 07-06-2010 at 05:35 PM.
-
Hi rrjii... it has been a while.
And once again, that is one of those clear questions that have real meaning and importance, so I am always glad to try to help you.
There are different ways to handle this, depending on what you define as a "Null field". The meaning is quite clear in a database, and the framework has built-in features to help you deal with a database Null (the IsDBNull function, the Nullable type).
But in a file, you are the one defining what is Null or not.
The best that I now is never to use Nulls, either as empty values in a file (or as a Null value in a database either). Nulls were a handy way to save space when we had only 350Kb diskettes and 64Mb of memory (and even less, I have worked with computers that had only 2Kb of memory; anybody remembers the Timex Sinclair?). With the systems we have nowadays, although we still need to be careful about memory and disk use, this is less of a consideration. And Nulls are a pain in the "what you know" to deal with.
What is the best way to deal with a pain?
Not having it in the first place.
Personnally, I almost never use nulls in anything I do. I would rather use a dummy value that I treat as a Null. Sure there are cases where this is not convenient and nulls are the only way to go, such as having a field that store photos of products in the inventory. A Null then beats a dummy photo for a product for which we have no photo available.
But for most of the usual types of fields, it is easy to find dummy values, that can be easily identified as dummy. Here are a few examples:
- #01-01-1800# or #01-01-3000# for dates
- -1 for a number when negative values makes no sense, such as a Quantity Ordered field
- "<Undefined>" for Strings
When I write to the file or the database, I detect empty values and simply write those personal null values instead. After reading back the values, I check for those and treat them as if they were Nulls in my operations.
If you are careful enough, you will detect 3000-01-01 before putting it in a DateTimePicker and do whathever you want.
But if you forget to check for that value and send it in anyway, the DateTimePicker or other control won't choke. It will surely display a strange date, but the application won't drop dead on your user.
So to be short, "What is the best way to write a blank date?". Don't. Replace it with a dummy.
And this holds True for most types of values, not only for dates.
Jacques Bourgeois
JBFI
http://www3.sympatico.ca/jbfi/homeus.htm
-
as always, thanks for your help.
Similar Threads
-
Replies: 4
Last Post: 02-20-2010, 03:17 AM
-
By Neil Martin in forum VB Classic
Replies: 1
Last Post: 08-15-2002, 05:09 PM
-
By Neil Martin in forum VB Classic
Replies: 4
Last Post: 08-15-2002, 11:16 AM
-
Replies: 5
Last Post: 12-18-2001, 11:50 PM
-
By Jaikumar Sharma in forum VB Classic
Replies: 2
Last Post: 03-31-2000, 11:58 PM
Posting Permissions
- You may not post new threads
- You may not post replies
- You may not post attachments
- You may not edit your posts
Forum Rules
|
Top DevX Stories
Easy Web Services with SQL Server 2005 HTTP Endpoints
JavaOne 2005: Java Platform Roadmap Focuses on Ease of Development, Sun Focuses on the "Free" in F.O.S.S.
Wed Yourself to UML with the Power of Associations
Microsoft to Add AJAX Capabilities to ASP.NET
IBM's Cloudscape Versus MySQL
|
Bookmarks