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]]

zz12 wrote:

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.
--
Microsoft MVP -- ASP/ASP.NET
Please reply to the newsgroup. The email account listed in my From
header is my spam trap, so I don't check it very often. You will get a
quicker response by posting to the newsgroup.

[zz12]

I wonder what it could be then? The asp code hasn't changed and it used to
work fine.
"Bob Barrows [MVP]" <re******@NOyah oo.SPAMcomwrote in message
news:%2******** ********@TK2MSF TNGP05.phx.gbl. ..

zz12 wrote:

>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.
--
Microsoft MVP -- ASP/ASP.NET
Please reply to the newsgroup. The email account listed in my From
header is my spam trap, so I don't check it very often. You will get a
quicker response by posting to the newsgroup.

[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 wrote:

I wonder what it could be then? The asp code hasn't changed and it
used to work fine.
"Bob Barrows [MVP]" <re******@NOyah oo.SPAMcomwrote in message
news:%2******** ********@TK2MSF TNGP05.phx.gbl. ..

>zz12 wrote:

>>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.

--
Microsoft MVP -- ASP/ASP.NET
Please reply to the newsgroup. The email account listed in my From
header is my spam trap, so I don't check it very often. You will get a
quicker response by posting to the newsgroup.

[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("FloatF ield")? Something like...

response.write CINT(rs("FloatF ield") + 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]" <re******@NOyah oo.SPAMcomwrote in message
news:eP******** ******@TK2MSFTN GP06.phx.gbl...

>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 wrote:

>I wonder what it could be then? The asp code hasn't changed and it
used to work fine.
"Bob Barrows [MVP]" <re******@NOyah oo.SPAMcomwrote in message
news:%2******* *********@TK2MS FTNGP05.phx.gbl ...

>>zz12 wrote:
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.

--
Microsoft MVP -- ASP/ASP.NET
Please reply to the newsgroup. The email account listed in my From
header is my spam trap, so I don't check it very often. You will get a
quicker response by posting to the newsgroup.

[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 wrote:

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("FloatF ield")? Something
like...
response.write CINT(rs("FloatF ield") + 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]" <re******@NOyah oo.SPAMcomwrote in message
news:eP******** ******@TK2MSFTN GP06.phx.gbl...

>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 wrote:

>>I wonder what it could be then? The asp code hasn't changed and it
used to work fine.
"Bob Barrows [MVP]" <re******@NOyah oo.SPAMcomwrote in message
news:%2****** **********@TK2M SFTNGP05.phx.gb l...
zz12 wrote:
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
particula r 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 .

--
Microsoft MVP -- ASP/ASP.NET
Please reply to the newsgroup. The email account listed in my From
header is my spam trap, so I don't check it very often. You will get
a quicker response by posting to the newsgroup.

--
Microsoft MVP - ASP/ASP.NET
Please reply to the newsgroup. This email account is my spam trap so I
don't check it very often. If you must reply off-line, then remove the
"NO SPAM"

[zz12]

Will look further into this. Thanks a bunch for your info Bob. Is very
helpful and appreciate it much.
"Bob Barrows [MVP]" <re******@NOyah oo.SPAMcomwrote in message
news:el******** ******@TK2MSFTN GP05.phx.gbl...

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 wrote:

>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("FloatF ield")? Something
like...
response.write CINT(rs("FloatF ield") + 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]" <re******@NOyah oo.SPAMcomwrote in message
news:eP******* *******@TK2MSFT NGP06.phx.gbl.. .

>>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 wrote:
I wonder what it could be then? The asp code hasn't changed and it
used to work fine.
"Bob Barrows [MVP]" <re******@NOyah oo.SPAMcomwrote in message
news:%2***** ***********@TK2 MSFTNGP05.phx.g bl...
zz12 wrote:
>Hello, is there a setting in IIS 5.0 that would quickly fix the
>followin g 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
>particul ar 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
mismatche s.
>
>

--
Microsoft MVP -- ASP/ASP.NET
Please reply to the newsgroup. The email account listed in my From
header is my spam trap, so I don't check it very often. You will get
a quicker response by posting to the newsgroup.

--
Microsoft MVP - ASP/ASP.NET
Please reply to the newsgroup. This email account is my spam trap so I
don't check it very often. If you must reply off-line, then remove the
"NO SPAM"

[=?Utf-8?B?T2xkIFBlZGFudA==?=]

"zz12" wrote:

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("FloatF ield") + 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.

[=?Utf-8?B?T2xkIFBlZGFudA==?=]

"Bob Barrows [MVP]" wrote:

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/libr...86(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/libr...7h(VS.85).aspx

If you ever get a decimal value from a DB, as in
whatever = RS("someDecimal Field")
if you then do
Response.Write VarType(whateve r)
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 variantChangeTy peEx( ) function and *IT* is capable of
understanding and converting many more variant types than VBScript is aware
of.

[=?Utf-8?B?T2xkIFBlZGFudA==?=]

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/Newbi.../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
variantChangeTy peEx( ) 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