«

Hi all,

One of our sites use classic ASP, and has been running without major
problems. However, some users are getting errors with some ADO functions
after "upgrading" to IE8, and I suspect that the issue is related to ActiveX
not being enabled on their system, as I can generate the same error by
disabling ActiveX or using a browser that doesn't support ActiveX. Anyone
know of a quick-and-not-so-dirty way to test for ActiveX using classic ASP?

Thanks,

--
Neil Gould
Terra Tu Technical Publishing
www.TerraTu.com

Neil Gould wrote:
> Hi all,
>
> One of our sites use classic ASP, and has been running without major
> problems. However, some users are getting errors with some ADO
> functions after "upgrading" to IE8, and I suspect that the issue is
> related to ActiveX not being enabled on their system, as I can
> generate the same error by disabling ActiveX or using a browser that
> doesn't support ActiveX. Anyone know of a quick-and-not-so-dirty way
> to test for ActiveX using classic ASP?
>
No, ASP is server-side technology so by definition it can't be used to test
client capabilities.

You will need to use client-side code for this. There is nothing beyond
trying to create an ADO object and trapping the error that occurs.

--
Microsoft MVP - ASP/ASP.NET - 2004-2007
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"

Bob Barrows wrote:
> Neil Gould wrote:
>> Hi all,
>>
>> One of our sites use classic ASP, and has been running without major
>> problems. However, some users are getting errors with some ADO
>> functions after "upgrading" to IE8, and I suspect that the issue is
>> related to ActiveX not being enabled on their system, as I can
>> generate the same error by disabling ActiveX or using a browser that
>> doesn't support ActiveX. Anyone know of a quick-and-not-so-dirty way
>> to test for ActiveX using classic ASP?
>>
> No, ASP is server-side technology so by definition it can't be used
> to test client capabilities.
>
> You will need to use client-side code for this. There is nothing
> beyond trying to create an ADO object and trapping the error that
> occurs.
>
Thanks, Bob,

I might have been clearer... your suggestion is what I had in mind. I
realize that ASP is server-side tech, and hoped that there might be a way to
initiate an action via script that would require ActiveX, then trap the
error if it isn't available.

Neil

Neil Gould wrote:
> Bob Barrows wrote:
>> Neil Gould wrote:
>>> Hi all,
>>>
>>> One of our sites use classic ASP, and has been running without major
>>> problems. However, some users are getting errors with some ADO
>>> functions after "upgrading" to IE8, and I suspect that the issue is
>>> related to ActiveX not being enabled on their system, as I can
>>> generate the same error by disabling ActiveX or using a browser that
>>> doesn't support ActiveX. Anyone know of a quick-and-not-so-dirty way
>>> to test for ActiveX using classic ASP?
>>>
>> No, ASP is server-side technology so by definition it can't be used
>> to test client capabilities.
>>
>> You will need to use client-side code for this. There is nothing
>> beyond trying to create an ADO object and trapping the error that
>> occurs.
>>
> Thanks, Bob,
>
> I might have been clearer... your suggestion is what I had in mind. I
> realize that ASP is server-side tech, and hoped that there might be a
> way to initiate an action via script that would require ActiveX, then
> trap the error if it isn't available.
>
I'm not really sure what you are asking. You already have a line of
client-side code that tries to initiate an adodb object don't you? Just trap
the error that is raised by that line of code using try...catch if jscript
or on error resume next if vbscript.

--
Microsoft MVP - ASP/ASP.NET - 2004-2007
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"

Bob Barrows wrote:
> Neil Gould wrote:
>> Bob Barrows wrote:
>>> Neil Gould wrote:
>>>> Hi all,
>>>>
>>>> One of our sites use classic ASP, and has been running without
>>>> major problems. However, some users are getting errors with some
>>>> ADO functions after "upgrading" to IE8, and I suspect that the
>>>> issue is related to ActiveX not being enabled on their system, as
>>>> I can generate the same error by disabling ActiveX or using a
>>>> browser that doesn't support ActiveX. Anyone know of a
>>>> quick-and-not-so-dirty way to test for ActiveX using classic ASP?
>>>>
>>> No, ASP is server-side technology so by definition it can't be used
>>> to test client capabilities.
>>>
>>> You will need to use client-side code for this. There is nothing
>>> beyond trying to create an ADO object and trapping the error that
>>> occurs.
>>>
>> Thanks, Bob,
>>
>> I might have been clearer... your suggestion is what I had in mind. I
>> realize that ASP is server-side tech, and hoped that there might be a
>> way to initiate an action via script that would require ActiveX, then
>> trap the error if it isn't available.
>>
> I'm not really sure what you are asking. You already have a line of
> client-side code that tries to initiate an adodb object don't you?
> Just trap the error that is raised by that line of code using
> try...catch if jscript or on error resume next if vbscript.
>
I'm trying to find a solution that "anticipates" a problem before the client
initiates an action. Put another way, not all of the ado objects seem to
need activex on the client side to run. For example, database operations
work from browsers that don't support activex, but file transfers don't. So
I'm hoping that someone knows which objects do and don't require activex on
the client as a starting point, and ultimately I'd like to be able to
initiate an action via server-side script that requires it so that I can
trap that error.

Thanks,

Neil

Neil Gould wrote:
> Bob Barrows wrote:
> I'm trying to find a solution that "anticipates" a problem before the
> client initiates an action.

That's the point I'm trying to make: you won't find it.

> Put another way, not all of the ado
> objects seem to need activex on the client side to run.

??? ADO is an ActiveX technology. What ADO object does not require an
ActiveX instantiation?

> For example,
> database operations work from browsers that don't support activex,

??? In client-side code? Can you give me an example?

> but file transfers don't.

?? File transfers don't need client-side activex, unless you're using an
activex client-side download manager

> So I'm hoping that someone knows which
> objects do and don't require activex on the client as a starting

ActiveX objects, by definition, require activex to be enabled in the browser
if you wish to run them in client-side code (not really sure why you need to
perform database operations in client-side code ... at the least, this is a
security hole)

So, if any of the following exists in the html being processed by a browser,
then activex needs to be enabled:

<OBJECT ... >
<script type="text/javascript">obj=new ActiveXObject("...")</script>
<script type="text/vbscript">set obj=CreateObject("...")</script>


> point, and ultimately I'd like to be able to initiate an action via
> server-side script that requires it so that I can trap that error.
>
Impossible. I thought you said you understood the demarcation between
client-side and server-side execution. The server code knows nothing about
the client capabilities beyond what is passed in the Request object ...
Sure, you can response.write a script block to be executed on the client,
but you don't need ASP to do that ...



--
Microsoft MVP - ASP/ASP.NET - 2004-2007
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"

Bob Barrows wrote:
> Neil Gould wrote:
>> Bob Barrows wrote:
>> I'm trying to find a solution that "anticipates" a problem before the
>> client initiates an action.
>
> That's the point I'm trying to make: you won't find it.
>
I'm getting that impression.

>> Put another way, not all of the ado
>> objects seem to need activex on the client side to run.
>
> ??? ADO is an ActiveX technology. What ADO object does not require an
> ActiveX instantiation?
>
>> For example,
>> database operations work from browsers that don't support activex,
>
> ??? In client-side code? Can you give me an example?
>
Login procedures and certain updates initiated by client-side actions.

>> but file transfers don't.
>
> ?? File transfers don't need client-side activex, unless you're using
> an activex client-side download manager
>
The various "pure ASP" upload processes I've worked with require it. They
fail to pull filename information from
<input type="file" ... > if it is unavailable.

I can accept that what I was wanting to do may not be possible, and am only
trying to expand my understanding of the ADO realm, not start an argument
about it all...

Thanks again for your help.

Neil

Neil Gould wrote:
> Bob Barrows wrote:
>> Neil Gould wrote:
>>> Bob Barrows wrote:
>>> I'm trying to find a solution that "anticipates" a problem before
>>> the client initiates an action.
>>
>> That's the point I'm trying to make: you won't find it.
>>
> I'm getting that impression.
>
>>> Put another way, not all of the ado
>>> objects seem to need activex on the client side to run.
>>
>> ??? ADO is an ActiveX technology. What ADO object does not require an
>> ActiveX instantiation?
>>
>>> For example,
>>> database operations work from browsers that don't support activex,
>>
>> ??? In client-side code? Can you give me an example?
>>
> Login procedures and certain updates initiated by client-side actions.

Please, provide an example. Are the database activities you are talking
about occurring in client-side or server-side code? I can guarantee you that
server-side ADO code absolutely does not depend on browser capabilities.

>
>>> but file transfers don't.
>>
>> ?? File transfers don't need client-side activex, unless you're using
>> an activex client-side download manager
>>
> The various "pure ASP" upload processes I've worked with require it.
> They fail to pull filename information from
> <input type="file" ... > if it is unavailable.

I don't think so. That input tag is pure html. It should not depend on
activex being enabled. Now maybe, just maybe ... IE is using a COM object to
cause the browse dialog to appear ... I'm going to test this after I send
this.

>
> I can accept that what I was wanting to do may not be possible, and
> am only trying to expand my understanding of the ADO realm, not start
> an argument about it all...
>
I'm sorry it appeared I was arguing. I'm trying to get you to clarify what
you are trying to accomplish. Some of the statements you made make no sense.

--
Microsoft MVP - ASP/ASP.NET - 2004-2007
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"

Neil Gould wrote:
>>
>> ?? File transfers don't need client-side activex, unless you're using
>> an activex client-side download manager
>>
> The various "pure ASP" upload processes I've worked with require it.
> They fail to pull filename information from
> <input type="file" ... > if it is unavailable.
>
Here is a simple repro to allow you to see that what you are thinking is
incorrect:

<%@ Language=VBScript %>
<%
biData = Request.BinaryRead(Request.TotalBytes)
Response.Write CWideString(biData)
Function CWideString(bsString)
Dim nIndex
CWideString =""
For nIndex = 1 to LenB(bsString)
CWideString = CWideString & Chr(AscB(MidB(bsString,nIndex,1)))
Next
End Function

%>
<HTML>
<HEAD>
</HEAD>
<BODY>

<FORM action="" method=POST id=form1 name=form1
ENCTYPE="multipart/form-data">
<INPUT type="file" id=text1 name=text1>
<INPUT type="submit" value="Submit" id=submit1 name=submit1>
</FORM>
</BODY>
</HTML>

When I run this after disabling activex in my browser, it correctly uploads
the selected file and displays the string that can be parsed to get the file
name. For example, here is the string that results from uploading a small
file:

-----------------------------7d9092205d0 Content-Disposition: form-data;
name="text1"; filename="F:\INSTALL.LOG" Content-Type:
application/octet-stream *** Installation Started 08/10/2009 22:43 ***
Title: Rhapsody Installation Source: f:\Temp\GLB2DB.tmp | 08-10-2009 |
22:43:04 | 71680 User Rights: Admin -----------------------------7d9092205d0
Content-Disposition: form-data; name="submit1"
Submit -----------------------------7d9092205d0--


Now if your "pure ASP" upload process includes an activex progress bar, then
yes, killing activex will kill that. To my mind, a solution that uses such a
control can hardly be called "pure" ASP.


--
Microsoft MVP - ASP/ASP.NET - 2004-2007
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"

Bob Barrows wrote:
> Neil Gould wrote:
>>>
>>> ?? File transfers don't need client-side activex, unless you're
>>> using an activex client-side download manager
>>>
>> The various "pure ASP" upload processes I've worked with require it.
>> They fail to pull filename information from
>> <input type="file" ... > if it is unavailable.
>>
> Here is a simple repro to allow you to see that what you are thinking
> is incorrect:
>
> <%@ Language=VBScript %>
> <%
> biData = Request.BinaryRead(Request.TotalBytes)
> Response.Write CWideString(biData)
> Function CWideString(bsString)
> Dim nIndex
> CWideString =""
> For nIndex = 1 to LenB(bsString)
> CWideString = CWideString & Chr(AscB(MidB(bsString,nIndex,1)))
> Next
> End Function
>
> %>
> <HTML>
> <HEAD>
> </HEAD>
> <BODY>
>
> <FORM action="" method=POST id=form1 name=form1
> ENCTYPE="multipart/form-data">
> <INPUT type="file" id=text1 name=text1>
> <INPUT type="submit" value="Submit" id=submit1 name=submit1>
> </FORM>
> </BODY>
> </HTML>
>
> When I run this after disabling activex in my browser, it correctly
> uploads the selected file and displays the string that can be parsed
> to get the file name. For example, here is the string that results
> from uploading a small file:
>
> -----------------------------7d9092205d0 Content-Disposition:
> form-data; name="text1"; filename="F:\INSTALL.LOG" Content-Type:
> application/octet-stream *** Installation Started 08/10/2009 22:43 ***
> Title: Rhapsody Installation Source: f:\Temp\GLB2DB.tmp | 08-10-2009 |
> 22:43:04 | 71680 User Rights: Admin
> -----------------------------7d9092205d0 Content-Disposition:
> form-data; name="submit1"
> Submit -----------------------------7d9092205d0--
>
>
> Now if your "pure ASP" upload process includes an activex progress
> bar, then yes, killing activex will kill that. To my mind, a solution
> that uses such a control can hardly be called "pure" ASP.
>
I'll look into this to understand the differences between your example and
what I currently have. FWIW, there are no progress bars or other such items
in the current code samples which are based on variants of the
"clsUpload.asp" code that can be found at:

http://www.freevbcode.com/ShowCode.asp?ID=4596

Thanks again for your help.

Neil