Type mismatch

[zz12]

Hello, is there a setting in IIS 5.0 that would quickly fix the following
error?:

Microsoft VBScript runtime (0x800A000D)
Type mismatch

It's strange because some of our .asp pages were working fine for the past
years but recently our website was updated in that old folders were renamed
and the new ones took on the existing name and was wondering why some our
..asp pages are now returning this error? I would think that since the code
hasn't changed and it used to work fine it should be a setting in IIS or in
the properties of a particular folder?

Thanks in advance.

 

[Bob Barrows [MVP]]

Hello, is there a setting in IIS 5.0 that would quickly fix the
following error?:

Microsoft VBScript runtime (0x800A000D)
Type mismatch
No.


It's strange because some of our .asp pages were working fine for the
past years but recently our website was updated in that old folders
were renamed and the new ones took on the existing name and was
wondering why some our .asp pages are now returning this error? I
would think that since the code hasn't changed and it used to work
fine it should be a setting in IIS or in the properties of a
particular folder?

You were getting away with poorly written code. Whatever has changed in
your updates has resulted in your no longer being able to get away with
it. You need to debug your code and fix the type mismatches.

 

[zz12]

I wonder what it could be then? The asp code hasn't changed and it used to
work fine.

 

[Bob Barrows [MVP]]

I don't know what else you expect us to tell you.
The only way to find out is by debugging, figuring out what line of code
is causing the error and fixing the cause of the problem. Start with the
error reported: typically error statements will show a line number. Use
some well-placed response.write statements to display variable values,
etc before the line executes. If that does not help you, post the guilty
section of code here.

 

[zz12]

Sorry for this novice question...when trying to perform an additon equation
on recordset values that are 'float' data types does one need to convert it
using something like CINT(rs("FloatField")? Something like...

response.write CINT(rs("FloatField") + 987.123456 : response.end

It looks like a co-worker had changed the data type that it uses on our SQL
Server from 'float' to 'decimal' and since the .asp code didn't have any
data conversion functions prior I am pretty certain 'float' data types don't
need to be converted when performing arithmatic equations using recordset
values since it never gave us the Type mismatch error before. It appears
that using CINT is needed for 'decimal' data types which does fix our
problem now but then it loses a portion of the data since we have values
that are 6 precisions which leads me to ask another novice question which
convert function can be used or how can 'decimal' recordset values be
converted without losing it's precision?

Thanks.

 

[Bob Barrows [MVP]]

No. CInt() is used for converting a value to Integer. You should only use it
if you can do without the decimal portion of the number. The vbscript docs
can be downloaded from http://tinyurl.com/7rk6. When you get them, look up
the CDbl and CSng functions, as well as looking for the descriptions of the
various datatypes (Integer, Long, Single, Double) involved.

In this case, I think your problem may have more to do with floatfield
containing Null values. Is the field configured to allow Nulls?

Incidentally, I agree with your co-worker's decision to move away from
Float.

 

[zz12]

Will look further into this. Thanks a bunch for your info Bob. Is very
helpful and appreciate it much.

 

[Old Pedant]

It looks like a co-worker had changed the data type that it uses on our SQL
Server from 'float' to 'decimal'

That's the killer! VBScript can *NOT* handle the DECIMAL data type!!!!

It can't do *ANY* arithmetic on DECIMAL values.

It can *hold* a DECIMAL value, because all variables in VBScript are
actually "variants" (if you don't know what that means, don't worry about it)
and indeed vt_Decimal is a valid variant.

So if all you do is *output* a DECIMAL value, the underlying COM code can
handily convert decimal to text for you and all is well.

But you simply can *NOT* do arithmetic using DECIMAL.

The correct answer is to *ALWAYS ALWAYS ALWAYS* convert *ALL* DECIMAL values
to DOUBLE using CDBL( ).

response.write CDBL(rs("FloatField") + 987.123456

Have you considered shooting the person who made that change in the DB
without testing *ALL* uses of the DB? In our shop, he'd be lucky to still
have a job.

&&&&&&&&&&&&&

There is another solution, by the way. You can convert the data from
DECIMAL to DOUBLE (or even to CURRENCY) in SQL. Whether this is easier or
harder than just finding all the RS("FloatField") occurrences and adding on
the CDBL( ) call is up to you.

&&&&&&&&&&&&&

p.s.: Bob Barrows is right; a NULL used with CDBL( ) would cause the same
error message. But given that the code worked until the datatype was
changed, I'm betting that NULLs are *not* the problem.

 

[Old Pedant]

Incidentally, I agree with your co-worker's decision to move away from
Float.

I have to VERY STRONGLY disagree with this statement!

Oh, it's nice in principal. But changes like this should NEVER be made
without testing ALL uses of the given database table(s) and field(s).

In this case, the change to DECIMAL indeed means that none of the simple
arithmetic that VBScript was doing will work any more. Every single usage of
those fields in VBScript that involve any kind of calculations will now need
to have CDBL( ) calls added to them.

Quite possibly or even probably, using CDBL( ) *is* the right long-term
solution. But to have it foisted on the site like this, because the idiot
changed the DB without thorough testing, is enough reason to put a really
really black mark on the person's record.

Move away from FLOAT? Okay. But *ONLY* after considering *ALL* the
consequences.

If you are curious about the details:

This shows that the OLEDB type dbtype_decimal is converted to vt_decimal by
ADO:
http://msdn.microsoft.com/en-us/library/bb231286(VS.85).aspx

This shows how DECIMAL is represented in a Variant *AND* shows that
vt_decimal has the value 14 (0x0E).
http://msdn.microsoft.com/en-us/library/cc251799.aspx

And this shows that VBScript does *NOT* understand vt_decimal:
http://msdn.microsoft.com/en-us/library/3kfz157h(VS.85).aspx

If you ever get a decimal value from a DB, as in
whatever = RS("someDecimalField")
if you then do
Response.Write VarType(whatever)
you will find that the answer is 14, thus demonstrating that VBScript
variables *CAN* hold values that VBScript doesn't really understand.

When you then do
whatever = CDBL(whatever)
you are calling COM's variantChangeTypeEx( ) function and *IT* is capable of
understanding and converting many more variant types than VBScript is aware
of.

 

[Old Pedant]

If you can't read all of this thread, the reason for this demo won't be
obvious. But it's just too much to copy into this msg.

But maybe the demo itself will be clear, anyway.

http://www.clearviewdesign.com/Newbie/Demos/DataTypes.asp

If you hit that page, you'll see a "dump" of ONE RECORD from a single Access
database table. I purposely put one field of each of the most usual Access
field types in that table, excepting only DateTime and blobs. Then I put
data into only one record, just for demo purposes. Both BIT and YESNO end up
as the same ADO type (and then of course the same VBS type).

So this page just "dumps" that one record from that one table.

But it "dumps" in what I hope is an enlightening way. The name of each
field indicates what type of field it is. I used a CREATETABLE sql statement
to generate the table, so that I could use both CHAR(10) and VARCHAR(10).
And, as you can see, those are seen as separate ADO data types, though by the
time they get to VBS they are both just strings.

Note that for data types where precision and/or numericScale are
meaningless, ADO supplies 255 as a default value. So the only data type that
shows *BOTH* precision and scale is, as expected, the DECIMAL field at the
bottom. (Currency always has a scale of 4, but I guess ADO doesn't care
about that.)

Note that, indeed as I predicted in an earlier post, the decimalField has a
VBS VarType( ) of 14.

But then notice the last cell in the table: AHA! An error!
"Variable uses an Automation type not supported in VBScript"
So even TypeName( ) can't use that variant type!

AND YET look at the VALUE column!!! There the DECIMAL value is in it's full
(18,6) glory! WHY? Simply because Response.Write *always* needs a STRING to
write and so, when asked to write this DECIMAL variant, it calls the COM
variantChangeTypeEx( ) function which happily converts the DECIMAL to STRING!!

And *THAT* is why you *CAN* use DECIMAL database fields with VBScript *IF*
you don't do any calculations on them! But also, as VarType( ) clearly
demonstrates, you can't do much of anything else with them.

And, yes, that clearly includes arithmetic. Of any kind.

-- Bill Wilkinson

 

[Old Pedant]

Incidentally...

If you are curious what the difference between char10Field and
varchar10Field is, aside from the ADO type number, just change the line
<TD><%=val%></TD>
to
<TD><%=Replace(val," ","^")%></TD>

If you do that, you'll see that none of the value displays change *EXCEPT*
for the char10Field, and its value is then displayed as
abc^^^^^^^

In other words, the char(10) field is space filled to the full size of the
field, just as you woud expect!!

 

[Anthony Jones]

I have to VERY STRONGLY disagree with this statement!

I'm rarely bothered by matters of nettiquete and am often irritated when
someone posts a reply merely to correct some matter of netiquette. However
the use of capitals in the above manner is considered to be shouting and you
seem to have a tendancy to use it. I think your opinion is well made and
there is no need to shout. If you would like to emphasise something use
_this point its emphasised_ or *this is also emphasised*.

So as not to break my own rules I have will agree that untested
refactoring is bound to lead to problems. However, I don't believe Bob
implied that it was ok to make the change untested.

 

[zz12]

Wow, very interesting information and am grateful for you all for your
helpful replies. Sorry if I've sparked some debate with my less than
expertise level but I'm sure everyone just meant well even if their forms of
communications/perspectives slightly differ and had good intentions in
helping me out. Thanks guys totally appreciate your speedy and informative
replies

 

[Bob Barrows [MVP]]

I have to VERY STRONGLY disagree with this statement!

It was late. I said "decision" when I meant "intention".
Of course testing should have been done.

 

[Bob Barrows [MVP]]

That's the killer! VBScript can *NOT* handle the DECIMAL data
type!!!!

It can't do *ANY* arithmetic on DECIMAL values.

That is not my experience. I never use float and I never have type
mismatches when doing math with the retrieved data.

Hmmm ... now that I think about it ... that may be because
1. I tend to do math in my sql statements, returning the results
and
2. I'm a stickler for doing explicit conversions, even when there is no
apparent need for them

I will need to do some testing when I have some time.

 

[Old Pedant]

I'm rarely bothered by matters of nettiquete and am often irritated when
someone posts a reply merely to correct some matter of netiquette. However
the use of capitals in the above manner is considered to be shouting and you
seem to have a tendancy to use it. I think your opinion is well made and
there is no need to shout. If you would like to emphasise something use
_this point its emphasised_ or *this is also emphasised*.

Well, if you'll just convert all my use of all caps to _stuff_ then that's
my intention.

But, yes, I'll try to work on that. I want to be able to use bold and
italic and coloring, and of course you can't do that in usenet. *sigh*

No yelling, intended, honest. Just trying to emphasize some things.
Actually, even as I wrote it I was bothered by the fact that I needed to keep
DECIMAL in all caps, to make sure it was seen as a language term and not just
text. So then my "shouting" was all the more confusing.

No guarantees I'll break the habit overnight, but I'll try to watch it.

Bill Wilkinson

 

[Old Pedant]

It was late. I said "decision" when I meant "intention".
Of course testing should have been done.

Yes, no argument at all about that statement.

And sorry for the apparent shouting. Believe me, I wouldn't shout at you.
(Some people, maybe. But I respect your opinions...even when/if I disagree.)

 

[Old Pedant]

Wow, very interesting information and am grateful for you all for your
helpful replies. Sorry if I've sparked some debate...

I think we are generally all in agreement. It was just my usual
over-enthusiastic response that Anthony (rightfully) objected to.

And I can prove my assertion about arithmetic and DECIMAL. Here, a
variation on that previously posted page:
http://www.clearviewdesign.com/newbie/demos/datatypes2.asp

This one doesn't make a lot of sense unless you go read the ASP source code,
via the provided button.

 

[Old Pedant]

That is not my experience. I never use float and I never have type
mismatches when doing math with the retrieved data.

Here, I owe you this for "shouting" at you.

http://www.clearviewdesign.com/newbie/demos/datatypes2.asp

Click on the button to see the source code.

I only did addition and multiplication, but that should be enough, no?

 

[Bob Barrows [MVP]]

Here, I owe you this for "shouting" at you.

http://www.clearviewdesign.com/newbie/demos/datatypes2.asp

Click on the button to see the source code.

I only did addition and multiplication, but that should be enough, no?

Absolutely. I'll take a look at it this weekend