Inconsistent results from Len function?

[MikeR]

This is a problem on a classic asp page which receives the results from a form submit.

QSOExists is a parameterized query in an Access db.
"SELECT count (*) AS QSOCnt
FROM Worked
WHERE UCall = [In_UCall] and WCall = [In_WCall];"

The fields of interest do exist in the database.

SanCall is set when the page loads, and doesn't change.
The 'In' result is SWCall and SZone respectively

This code snippet gives the results below. It seems one of the Len() calls is failing
for some SWCall/SZone pairs.

SZone = trim(Request.Form("TZone")(i))
SWCall = (UCase(Request.Form("TCall")(i)))
response.write "<br>In " & SWCall & " " & SZone
If (Len(SWCall)) and (Len(SZone)) then
ConnTemp.QSOExists SanCall, SWCall, QRS
response.write "<br> Count: " & QRS("QSOCnt") & " " & SWCall & " " & SZone

In ZD8UW 36
In ZF2NN 8
Count: 1 ZF2NN 8

This snippet gives the expected results. Note the difference in the 'If' statement

SZone = trim(Request.Form("TZone")(i))
SWCall = (UCase(Request.Form("TCall")(i)))
response.write "<br>In " & SWCall & " " & SZone
If (Len(SWCall) > 0) and (Len(SZone) > 0) then
ConnTemp.QSOExists SanCall, SWCall, QRS
response.write "<br> Count: " & QRS("QSOCnt") & " " & SWCall & " " & SZone

In ZD8UW 36
Count: 1 ZD8UW 36
In ZF2NN 8
Count: 1 ZF2NN 8

What am I missing?
Thanks, Mike

 

[Hal Rosser]

If (Len(SWCall)) and (Len(SZone)) then

ConnTemp.QSOExists SanCall, SWCall, QRS
response.write "<br> Count: " & QRS("QSOCnt") & " " & SWCall & " " &
SZone
This snippet gives the expected results. Note the difference in the 'If'
statement

SZone = trim(Request.Form("TZone")(i))
SWCall = (UCase(Request.Form("TCall")(i)))
response.write "<br>In " & SWCall & " " & SZone
If (Len(SWCall) > 0) and (Len(SZone) > 0) then
ConnTemp.QSOExists SanCall, SWCall, QRS
response.write "<br> Count: " & QRS("QSOCnt") & " " & SWCall & " " &
SZone

the Len function returns an integer rather than a boolean, and it looks
like you're depending on VB to convert those numbers to a boolean. Maybe its
best not to depend on that side effect of VB interpreting 0 as a false
boolean value.
According to msdn...:
When you convert between Boolean values and numeric data types, keep in mind
that the .NET Framework conversion methods do not always produce the same
results as the Visual Basic conversion keywords. This is because the Visual
Basic conversion retains behavior compatible with previous versions. For
more information, see Troubleshooting Data Types.

And the following was also in msdn
Boolean Data Type (Visual Basic) values are not stored as numbers, and the
stored values are not intended to be equivalent to numbers. For
compatibility with earlier versions, Visual Basic provides conversion
keywords (CType Function, CBool, CInt, and so on) to convert between Boolean
and numeric types. However, other languages sometimes perform these
conversions differently, as do the .NET Framework methods.

You should never write code that relies on equivalent numeric values for
True and False. Whenever possible, you should restrict usage of Boolean
variables to the logical values for which they are designed. If you must mix
Boolean and numeric values, make sure that you understand the conversion
method that you select.

 

[MikeR]

I believe the issue is that the length of zero can return a true result from the len function, as zero can be a length.

So it's necessary to set a minimum value for your test to be greater than zero.

Thanks Jon -
That makes some sense: the length was not zero, however.

 

[MikeR]

Thanks Hal -
I think you nailed it.

the Len function returns an integer rather than a boolean, and it looks
like you're depending on VB to convert those numbers to a boolean. Maybe its
best not to depend on that side effect of VB interpreting 0 as a false
boolean value.
According to msdn...:
When you convert between Boolean values and numeric data types, keep in mind
that the .NET Framework conversion methods do not always produce the same
results as the Visual Basic conversion keywords. This is because the Visual
Basic conversion retains behavior compatible with previous versions. For
more information, see Troubleshooting Data Types.

No .not involved ;->

And the following was also in msdn
Boolean Data Type (Visual Basic) values are not stored as numbers, and the
stored values are not intended to be equivalent to numbers. For
compatibility with earlier versions, Visual Basic provides conversion
keywords (CType Function, CBool, CInt, and so on) to convert between Boolean
and numeric types. However, other languages sometimes perform these
conversions differently, as do the .NET Framework methods.

You should never write code that relies on equivalent numeric values for
True and False. Whenever possible, you should restrict usage of Boolean
variables to the logical values for which they are designed. If you must mix
Boolean and numeric values, make sure that you understand the conversion
method that you select.

I had seen some code posted where the responder used it as I did. I wondered at the
time how it worked. The fact that it appears to work sometimes is more worrying that
if it failed consistently.

 

[Hal Rosser]

Thanks Hal -
I think you nailed it.

It looks like you're writing a program to keep track of your QSOs, it not
surprising to see a fellow Ham writing code. Its double the fun!
regards - de w4pmj

 

[MikeR]

It looks like you're writing a program to keep track of your QSOs, it not
surprising to see a fellow Ham writing code. Its double the fun!
regards - de w4pmj

Hal, you nailed it again. Our club is doing a contest following the CQ magazine DX
Marathon format.
73, Mike NF4L