Quick test for ActiveX?

Discussion in 'ASP General' started by Neil Gould, Aug 31, 2009.

  1. Neil Gould

    Neil Gould Guest

    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, Aug 31, 2009
    #1
    1. Advertising

  2. Neil Gould

    Bob Barrows Guest

    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, Aug 31, 2009
    #2
    1. Advertising

  3. Neil Gould

    Neil Gould Guest

    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, Aug 31, 2009
    #3
  4. Neil Gould

    Bob Barrows Guest

    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, Aug 31, 2009
    #4
  5. Neil Gould

    Neil Gould Guest

    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, Aug 31, 2009
    #5
  6. Neil Gould

    Bob Barrows Guest

    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, Aug 31, 2009
    #6
  7. Neil Gould

    Neil Gould Guest

    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, Aug 31, 2009
    #7
  8. Neil Gould

    Bob Barrows Guest

    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"
    Bob Barrows, Aug 31, 2009
    #8
  9. Neil Gould

    Bob Barrows Guest

    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, Sep 1, 2009
    #9
  10. Neil Gould

    Neil Gould Guest

    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
    Neil Gould, Sep 1, 2009
    #10
  11. Neil Gould

    Neil Gould Guest

    Bob Barrows wrote:
    > 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.
    >

    I think this has gotten a bit twisted, since if I understand your statement,
    we are in agreement about this; the login procedures and data updates that
    use information pulled from the HTML form work whether or not the user's
    browser supports activex.

    What I'm trying to get a grip on is why other procedures (e.g. the upload)
    fail if activex is not enabled or supported.

    Neil
    Neil Gould, Sep 1, 2009
    #11
  12. Neil Gould

    Bob Barrows Guest

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

    <snip>
    >>

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

    I've taken a quick browse through that and admittedly I might have
    missed something, but there seems to be nothing in there that depends on
    a client machine's activex functionality, given that it is all
    server-side code. The only problem that might occur is if the client
    browser fails to populate the form fields, but again, it's a pure html
    form so it should not depend on activex functionality. I've again tried
    a repro using this class (I won't bother posting it) and disabling
    activex in my browser fails to raise any errors.

    I really think you're barking up the wrong tree but I'm willing to be
    proven wrong. Show me how to reproduce the errors you are seeing.

    --
    HTH,
    Bob Barrows
    Bob Barrows, Sep 1, 2009
    #12
  13. Neil Gould

    Neil Gould Guest

    Bob Barrows wrote:
    > Neil Gould wrote:
    >> 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:

    > <snip>
    >>>

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

    > I've taken a quick browse through that and admittedly I might have
    > missed something, but there seems to be nothing in there that depends
    > on a client machine's activex functionality, given that it is all
    > server-side code. The only problem that might occur is if the client
    > browser fails to populate the form fields, but again, it's a pure html
    > form so it should not depend on activex functionality. I've again
    > tried a repro using this class (I won't bother posting it) and
    > disabling activex in my browser fails to raise any errors.
    >
    > I really think you're barking up the wrong tree but I'm willing to be
    > proven wrong. Show me how to reproduce the errors you are seeing.
    >

    I'd have posted a URL if it was practical to do so, but alas, it is not. I
    can only tell you that disabling activex causes the process to abort on the
    site, and the error appears to be the retrieval of the upload file's info
    from the HTML form. But, it wouldn't be the first wrong tree I've barked at
    in my 60+ years. ;-) Then again, that's why I'm here now...

    Your other post may give insights into a solution that avoids the problem
    altogether, and that will suffice.

    Thanks again,

    Neil
    Neil Gould, Sep 1, 2009
    #13
  14. Neil Gould

    Mark McGinty Guest

    "Neil Gould" <> wrote in message
    news:...
    > 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


    There are several ActiveX-related settings, many of which only affect a
    subset of ActiveX objects. There is a single setting to disable them all,
    but the more selective settings still apply even when ActiveX in general is
    enabled.

    ADODB.Recordset is "marked safe for scripting" but is not included in IE8's
    stock "PreApproved" list. The bad news is it may seem awfully hit-and-miss;
    the good news is that usually you're only one or two settings changes away
    from working. Tell the user how to fix it; if he wants to use your site
    badly enough, problem solved. You could also provide a program to do it,
    but getting the user to run it then becomes the challenge.

    ADODB.Stream, otoh, is not only "not marked as safe for scripting," there is
    also a kill bit for it, published via Windows Update (and re-published every
    time a new kill bit is added, so you can count on it getting broken again
    every time you fix it.) Client-side use of Stream is totally impractical.

    Luckilly you can use DOMDocument to do most of what was done with Stream --
    handling of binary data being the notable exception. But since you can POST
    binary file data to the server without even needing any client-side script
    at all, if you absolutely need a Stream, post the data to the server and
    create a Stream there.

    You mentioned file upload as a problem... if you're loading-up a varbinary
    field in a recordset and sending the recordset to the server, to do this you
    should know that encoding doubles the size of the data in XML, and if the
    XML is Unicode, it doubles it again. Post it in a form and read it from the
    request instead, it's significantly more efficient and not that hard to
    do... imho, of course.

    Bottom line is that no simplistic assumptions about user settings can be
    made when a client-side recordset fails, the issue is considerably more
    involved than that.


    -Mark

    btw, you should test creation of the recordset object and opening it
    separately. If it can be created then ActiveX permisions are adequate. If,
    having successfully created, it fails to open, the relevant setting is
    probably "access data across domains".
    Mark McGinty, Sep 1, 2009
    #14
  15. Neil Gould

    Neil Gould Guest

    Mark!

    Mark McGinty wrote:
    > "Neil Gould" <> wrote in message
    > news:...
    >> 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

    >
    > There are several ActiveX-related settings, many of which only affect
    > a subset of ActiveX objects. There is a single setting to disable
    > them all, but the more selective settings still apply even when
    > ActiveX in general is enabled.
    >
    > ADODB.Recordset is "marked safe for scripting" but is not included in
    > IE8's stock "PreApproved" list. The bad news is it may seem awfully
    > hit-and-miss; the good news is that usually you're only one or two
    > settings changes away from working. Tell the user how to fix it; if
    > he wants to use your site badly enough, problem solved. You could
    > also provide a program to do it, but getting the user to run it then
    > becomes the challenge.
    >
    > ADODB.Stream, otoh, is not only "not marked as safe for scripting,"
    > there is also a kill bit for it, published via Windows Update (and
    > re-published every time a new kill bit is added, so you can count on
    > it getting broken again every time you fix it.) Client-side use of
    > Stream is totally impractical.
    >
    > Luckilly you can use DOMDocument to do most of what was done with
    > Stream -- handling of binary data being the notable exception. But
    > since you can POST binary file data to the server without even
    > needing any client-side script at all, if you absolutely need a
    > Stream, post the data to the server and create a Stream there.
    >
    > You mentioned file upload as a problem... if you're loading-up a
    > varbinary field in a recordset and sending the recordset to the
    > server, to do this you should know that encoding doubles the size of
    > the data in XML, and if the XML is Unicode, it doubles it again.
    > Post it in a form and read it from the request instead, it's
    > significantly more efficient and not that hard to do... imho, of
    > course.
    >
    > Bottom line is that no simplistic assumptions about user settings can
    > be made when a client-side recordset fails, the issue is considerably
    > more involved than that.
    >
    >
    > -Mark
    >
    > btw, you should test creation of the recordset object and opening it
    > separately. If it can be created then ActiveX permisions are
    > adequate. If, having successfully created, it fails to open, the
    > relevant setting is probably "access data across domains".
    >

    Thanks very much for this response! It hits the issue I'm wrestling with
    squarely on the head. Now, I'll try to absorb your comments to see if there
    is a way to address this matter. Could you tell me more about fixing issues
    with IE8 and ADODB.Stream (These users do need to transfer binary files to
    the site via ASP)?

    --
    Neil
    Neil Gould, Sep 1, 2009
    #15
  16. Neil Gould

    Bob Barrows Guest

    Mark McGinty wrote:
    >
    > Luckilly you can use DOMDocument to do most of what was done with
    > Stream -- handling of binary data being the notable exception. But
    > since you can POST binary file data to the server without even
    > needing any client-side script at all, if you absolutely need a
    > Stream, post the data to the server and create a Stream there.
    >
    > You mentioned file upload as a problem... if you're loading-up a
    > varbinary field in a recordset and sending the recordset to the
    > server, to do this you should know that encoding doubles the size of
    > the data in XML, and if the XML is Unicode, it doubles it again.
    > Post it in a form and read it from the request instead, it's
    > significantly more efficient and not that hard to do... imho, of
    > course.
    >

    Hi Mark,
    Good to see you back here - it's been a while.

    Good information which I've filed for future reference. Unfortunately,
    you've gone to a lot of trouble to answer a question that it turns out
    the OP wasn't really asking, since we've finally established that ADO
    (and in particular, client-side ADO) was a red herring and the issue he
    really is having is where disabling activex prevents the selected file
    in the <input type="file"> box from being submitted to the server. I
    have failed to reproduce this behavior, but perhaps you could add some
    substance.

    --
    HTH,
    Bob Barrows
    Bob Barrows, Sep 1, 2009
    #16
  17. Neil Gould

    Bob Barrows Guest

    Neil Gould wrote:
    > Mark!
    >
    > Thanks very much for this response! It hits the issue I'm wrestling
    > with squarely on the head. Now, I'll try to absorb your comments to
    > see if there is a way to address this matter. Could you tell me more
    > about fixing issues with IE8 and ADODB.Stream (These users do need to
    > transfer binary files to the site via ASP)?
    >

    Really? I thought we had established that you were not using ADO in
    client-side code? The issues Mark wrote about pertain solely to the use
    of ADO objects in client-side code ("Client-side use of Stream is
    totally impractical"), and should have no bearing at all on the problem
    you described to me.

    I really believe we will not get to the bottom of this until we can see
    a small repro to allow us to see the behavior you are talking about.
    Your earlier suggestion about providing a url would be useless to us
    since we would not be able to see the server-side code. My suggestion is
    that you create a repro page (or two) that contains only the code and
    elements needed for us to see the behavior and post the code here so we
    can try to recreate the behavior ourselves.

    --
    HTH,
    Bob Barrows
    Bob Barrows, Sep 1, 2009
    #17
  18. Neil Gould

    Neil Gould Guest

    Bob,

    Bob Barrows wrote:
    > Neil Gould wrote:
    >> Mark!
    >>
    >> Thanks very much for this response! It hits the issue I'm wrestling
    >> with squarely on the head. Now, I'll try to absorb your comments to
    >> see if there is a way to address this matter. Could you tell me more
    >> about fixing issues with IE8 and ADODB.Stream (These users do need to
    >> transfer binary files to the site via ASP)?
    >>

    > Really? I thought we had established that you were not using ADO in
    > client-side code? The issues Mark wrote about pertain solely to the
    > use of ADO objects in client-side code ("Client-side use of Stream is
    > totally impractical"), and should have no bearing at all on the
    > problem you described to me.
    >

    The problem that I am trying to solve is directly addressed by Mark's
    information; the IE8 behavior is exactly as he describes, e.g. Recordset
    operations work properly without activex and some other operations fail.
    Since all of these operations are implemented server-side, hence my original
    confusion about which ADOs require activex to be available client-side, as
    that is the single repeatable aspect of the problem behavior.

    It seems that a solution will most likely come from a couple of directions;
    tell IE8 users how to set their browsers to enable activex (again, Mark's
    comment about specific bit settings was enlightening), but that is not an
    ASP matter; or find an ASP file transfer method that doesn't require
    client-side activex, ergo my pursuit of such information here. Given our
    dialogue, I'm sure that my questioning has been awkward, and for that I
    apologize.

    > I really believe we will not get to the bottom of this until we can
    > see a small repro to allow us to see the behavior you are talking
    > about. Your earlier suggestion about providing a url would be useless
    > to us since we would not be able to see the server-side code.
    >

    My comment was that giving a url isn't _practical_ at this point. The reason
    is that the particular ASP code is in an administrative portion of the site
    that is not generally accessible, and providing access to it via usenet is,
    well, "unwise" comes to mind. Even then, you could observe the behavior with
    no more insights into the code, as you've pointed out above.

    > My
    > suggestion is that you create a repro page (or two) that contains
    > only the code and elements needed for us to see the behavior and post
    > the code here so we can try to recreate the behavior ourselves.
    >

    The "ASP upload" code amounts to about 1,000 lines, which is why I tried to
    describe the problem behavior and pointed to examples of clsUpload.

    I did look into your code example in a previous reply. I'm looking into the
    differences between your example and the clsUpload code, as both initially
    utilize Request.BinaryRead, so the actual problem may lie somewhere beyond
    pulling the file info from the HTML form. But, it all comes back to the
    clsUpload code failing if activex is not available client-side.

    Thanks for your continued efforts, Bob!

    Neil
    Neil Gould, Sep 2, 2009
    #18
  19. Neil Gould

    Bob Barrows Guest

    Neil Gould wrote:
    > Bob,
    >
    > Bob Barrows wrote:
    >> Neil Gould wrote:
    >>> Mark!
    >>>
    >>> Thanks very much for this response! It hits the issue I'm wrestling
    >>> with squarely on the head. Now, I'll try to absorb your comments to
    >>> see if there is a way to address this matter. Could you tell me more
    >>> about fixing issues with IE8 and ADODB.Stream (These users do need
    >>> to transfer binary files to the site via ASP)?
    >>>

    >> Really? I thought we had established that you were not using ADO in
    >> client-side code? The issues Mark wrote about pertain solely to the
    >> use of ADO objects in client-side code ("Client-side use of Stream is
    >> totally impractical"), and should have no bearing at all on the
    >> problem you described to me.
    >>

    > The problem that I am trying to solve is directly addressed by Mark's
    > information; the IE8 behavior is exactly as he describes, e.g.
    > Recordset operations work properly without activex and some other


    No, no ... you're totally missing the point. He was saying that
    _client-side_ recordset operations can fail (he was still confused by your
    original question - as I initially was - and had come to the conclusion that
    you were using ADO in client-side code). The standard html file selecter
    does not use ADO on the client side to transfer files. If it did, users that
    did not have MDAC installed would not be able to upload files, now would
    they?

    > operations fail. Since all of these operations are implemented
    > server-side, hence my original confusion about which ADOs require
    > activex to be available client-side, as that is the single repeatable
    > aspect of the problem behavior.


    Nowhere did he say that server-side ADO operations could be affected by
    browser settings. Please, read it again.
    >
    > It seems that a solution will most likely come from a couple of
    > directions; tell IE8 users how to set their browsers to enable
    > activex (again, Mark's comment about specific bit settings was
    > enlightening),


    That's fine, if they want to go through that, but since it might not be
    addressing the actual problem, you might find it coming back to haunt you in
    the future. Also, some users may not be as inclined to lower their security
    shields as you may be hoping.

    >
    > I did look into your code example in a previous reply. I'm looking
    > into the differences between your example and the clsUpload code, as
    > both initially utilize Request.BinaryRead, so the actual problem may
    > lie somewhere beyond pulling the file info from the HTML form. But,
    > it all comes back to the clsUpload code failing if activex is not
    > available client-side.
    >


    But I haven't seen that behavior, yet. The code to retrieve the file name
    works fine regardless of my browser settings.
    Let's attack the symptom again: I think we've established that the file name
    is certainly present in the Request. What is actually failing in the
    clsUpload code? An attempt to use ADO to write the file to a database? An
    attempt to store it in the server's file system?


    --
    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, Sep 2, 2009
    #19
  20. Neil Gould

    Neil Gould Guest

    Bob,

    Bob Barrows wrote:
    > Neil Gould wrote:
    >> Bob,
    >>
    >> Bob Barrows wrote:
    >>> Neil Gould wrote:
    >>>> Mark!
    >>>>
    >>>> Thanks very much for this response! It hits the issue I'm wrestling
    >>>> with squarely on the head. Now, I'll try to absorb your comments to
    >>>> see if there is a way to address this matter. Could you tell me
    >>>> more about fixing issues with IE8 and ADODB.Stream (These users do
    >>>> need to transfer binary files to the site via ASP)?
    >>>>
    >>> Really? I thought we had established that you were not using ADO in
    >>> client-side code? The issues Mark wrote about pertain solely to the
    >>> use of ADO objects in client-side code ("Client-side use of Stream
    >>> is totally impractical"), and should have no bearing at all on the
    >>> problem you described to me.
    >>>

    >> The problem that I am trying to solve is directly addressed by Mark's
    >> information; the IE8 behavior is exactly as he describes, e.g.
    >> Recordset operations work properly without activex and some other

    >
    > No, no ... you're totally missing the point. He was saying that
    > _client-side_ recordset operations can fail
    >

    Please help me to understand your perspective. As I understand it, the ASP
    code in question is _all_ server-side, but some operations behave
    differently dependent upon activex settings.

    Mark wrote:
    "There are several ActiveX-related settings, many of which only affect a
    subset of ActiveX objects. There is a single setting to disable them all,
    but the more selective settings still apply even when ActiveX in general is
    enabled."

    Does this not imply that some ADO functions will be affected by activex
    settings, others not? If so, is that somehow different from my initial
    observation and resultant line of questioning?

    Again:
    "ADODB.Recordset is "marked safe for scripting" but is not included in IE8's
    stock "PreApproved" list. The bad news is it may seem awfully hit-and-miss;
    the good news is that usually you're only one or two settings changes away
    from working. "

    As I read it, this says that settings in IE8 can cause adodb.recordset
    operations to fail, but it is possible that some (if not all will succeed)
    because the default setting for IE8 will not interrupt the process. Is this
    an incorrect interpretation of Mark's message?

    And, finally:
    "ADODB.Stream, otoh, is not only "not marked as safe for scripting," there
    is also a kill bit for it, published via Windows Update (and re-published
    every time a new kill bit is added, so you can count on it getting broken
    again every time you fix it.)"

    This seems consistent with the above, in that ADODB.stream operations are
    likely to fail by default due to ActiveX settings, and is consistent with my
    observations of the problem.

    > (he was still confused by
    > your original question - as I initially was - and had come to the
    > conclusion that you were using ADO in client-side code).
    >

    Sorry for the confusion, but no, I'm not talking about any client-side code,
    if by that you mean some custom ASP code installed on a user's machine to
    interact with the site.

    >> operations fail. Since all of these operations are implemented
    >> server-side, hence my original confusion about which ADOs require
    >> activex to be available client-side, as that is the single repeatable
    >> aspect of the problem behavior.

    >
    > Nowhere did he say that server-side ADO operations could be affected
    > by browser settings. Please, read it again.
    >

    If I follow you, your interpretation of Mark's quotes above suggests that
    all of these ASP operations should succeed regardless of ActiveX settings on
    the user's machine because they are server-side operations? Since that isn't
    what happens, and success or failure can be determined by ActiveX settings
    on the browser, what am I missing?

    >> It seems that a solution will most likely come from a couple of
    >> directions; tell IE8 users how to set their browsers to enable
    >> activex (again, Mark's comment about specific bit settings was
    >> enlightening),

    >
    > That's fine, if they want to go through that, but since it might not
    > be addressing the actual problem, you might find it coming back to
    > haunt you in the future. Also, some users may not be as inclined to
    > lower their security shields as you may be hoping.
    >

    Exactly my concern. This is why I'm searching out details about the nature
    of ADO.

    >> I did look into your code example in a previous reply. I'm looking
    >> into the differences between your example and the clsUpload code, as
    >> both initially utilize Request.BinaryRead, so the actual problem may
    >> lie somewhere beyond pulling the file info from the HTML form. But,
    >> it all comes back to the clsUpload code failing if activex is not
    >> available client-side.
    >>

    >
    > But I haven't seen that behavior, yet. The code to retrieve the file
    > name works fine regardless of my browser settings.
    >

    Well, actually, your code appears to copy the file into the SafeArray and
    writes a subset of that information to the browser. Although the filename is
    included in that information, so far I haven't been able to extract the
    filename alone, though this may be due to the limited time I've had to
    explore the possibilities. It may be that the additional code in clsUpload
    requires client-side activex, but I can't see where that might be yet.

    > Let's attack the symptom again: I think we've established that the
    > file name is certainly present in the Request.
    >

    Yes.

    > What is actually
    > failing in the clsUpload code? An attempt to use ADO to write the
    > file to a database? An attempt to store it in the server's file
    > system?
    >

    Well, those certainly are the questions. ;-)

    The other question being, why does it succeed when ActiveX is available in
    the client-side browser?

    Thanks again,

    Neil
    Neil Gould, Sep 2, 2009
    #20
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Replies:
    0
    Views:
    872
  2. vaggelis
    Replies:
    0
    Views:
    3,502
    vaggelis
    Jul 13, 2003
  3. JKop
    Replies:
    11
    Views:
    879
  4. vml
    Replies:
    0
    Views:
    1,033
  5. Skybuck Flying

    Call oddities: &Test() vs &Test vs Test

    Skybuck Flying, Oct 4, 2009, in forum: C Programming
    Replies:
    1
    Views:
    694
    Skybuck Flying
    Oct 4, 2009
Loading...

Share This Page