Null String Problem
I have a string that is loaded from a collection that is inturn loaded from a fixed length file. Sometimes the string is null, and when I use an IF statement to test this condition I get unexpected results. In the file, the string exists as a field of 15 spaces, sometimes blank sometimes not. When loading into my collection I use the trim() function to remove the spaces (or atleast I thought).
Here's the weird part, when I reference (display the value) of the string it will show a null value "". But if I use the Len() function, it returns a 15. and blows right through my IF statement when testing for null. I've even tried assigning it out to another var, and it tests the same way.
Even when WlNum is = "" it blows right through to ELSE.
If Trim(WlNum) = "" Then
WlNum = "(None)"
WlNum = item.WellNum
A space is a valid character. Therefore, if something contains a space, it is not null. Regardless of what it "looks" like to you, the computer sees a valid, non null, character. Try this
If WlNum = Space(15) Or WlNum = String.Empty Then
WlNum = "(None)"
WlNum = item.WellNum
Last edited by Hack; 04-14-2010 at 08:16 AM.
I don't answer coding questions via PM or Email. Please post a thread in the appropriate forum section.
Please use [Code]your code goes in here[/Code] tags when posting code.
Before posting your question, did you look here
Got a question on Linux? Visit our Linux sister site.
Modifications Required For VB6 Apps To Work On Vista
Thanks for your solution, but why does a trim statement remove spaces that are surrounding a string but does not nullify a string that only contains spaces?
It's still blowing through, even Hack's version doesn't make it work, something strange is going on and I'm not sure what it is. I'll keep you all updated.
I've even moved the code to the Class Property and used it as a validator, still no results.
It appears that a "" with a len of 15 comes right out of the file, and no matter how I try to trap the null, I'm unsuccessful.
.WellNum = InputLine.Substring(112, 15)
' From Immediate Win
Is it a function of not writing a null to this particular file type that's giving me my problem, I guess I could write a routine that puts values in those file fields but It probably would not detect the nulls either. I probably could use the len() to locate the nulls, but at this point i'm amazed that none of the above works, and I'd really love to know why?
Last edited by rrjii2000; 04-14-2010 at 02:04 PM.
I think the problem has stemed from an earlier file type. This file used to be a random access file and was converted to a filestream. I think somewhere along the line, something happened to the null fields. So today I'm going to loop through the file and rewrite all the null fields. The following code is the only thing I've found that will trap the nulls.
To solve this problem I loaded the suspect fields into a datagrid, at that point the null fileds displayed as "IIIIIIIII" (not I's, but a cluster of small vertical lines) It resembled a mini barcode. All null fields displayed these characters and at that point I knew what needed fixed.
Public Property WellNum() As String
Set(ByVal value As String)
If Len(value) = 15 Or Len(value) = 0 Then
value = "(None)"
_WellNum = value
Last edited by rrjii2000; 04-15-2010 at 12:56 PM.
Thanks, I met similar problem in my java bar code and it is solved now. Now I would not consider space as null.
If you get strange characters in the grid, it means that the string contains non displayable characters, such as 8, which is a Basckspace.
Some applications display those characters as bars (the Grid), others as little squares, other disregard them (the debugger). Trim does not remove them because they could be used for some purpose or to display special characters in particular environments.
Those caracters could have appeared there for many reasons. Two common ones is data imported from a mainframe or from a file in another language than English. These sometimes do not use the standard ASCII (search the Internet for "ASCII code page" if you are curious), and some caracters are not translated correctly when converted to Unicode, which is the standard used in modern systems, including Windows and .NET.
You might want to trap one of those "null" fields and see what you get as the first character with Asc(yourString.Substring(0, 1)). Assuming that all your nulls are the same format, you could thus identify them through the ASCII value of their first character.
Try not to use nulls in any of your work. They often lead to strange problems. An empty string is as valid as a marker as a null, and usually does not bring those conflicts.
By sara2j2me in forum Java
Last Post: 09-19-2005, 03:39 AM
By Colin McGuigan in forum Database
Last Post: 04-15-2002, 07:43 AM
By Martin in forum VB Classic
Last Post: 12-03-2001, 03:53 AM
By reddy in forum Database
Last Post: 06-06-2001, 04:38 PM
By Bob Hines in forum Database
Last Post: 04-27-2000, 11:14 AM
-- Android Development Center
-- Cloud Development Project Center
-- HTML5 Development Center
-- Windows Mobile Development Center