| Home | Forums | Reviews | Guides | Newsgroups | Register | Search |
 |
| Thread Tools |
|
Guest
Posts: n/a
|
|
|
|
||
|
|
| |
|
Guest
Posts: n/a
|
Neil Gould wrote:
> 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, exactly ... which makes Mark's information irrelevant. He was talking about the effect of browser settings on the use of recordets in _cleint-side_ code. > but some operations > behave differently dependent upon activex settings. > And that's what has me baffled. There is no way that client-side settings could interfere with server operations, unless the client-side setting was interfering with the transfer of data from the client to the server.I've yet to see this behavior reproduced. > 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? YES!! _client-side_ script that uses ADO objects will certainly be affected by client browser settings. Specifically, this: <script type="text/javascript"> var rs; rs=new ActiveXObject("ADODB.Recordset") </script> will break if browser security settings don't allow activex objects to be created in client-side script. > If so, is that somehow different from > my initial observation and resultant line of questioning? Again, yes. Mark was answering a different question: he was talking about client-side operations being effected by browser security settings. You're talking about server-side code being effected by client security settings. This is not possible. > > 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, .... in client-side code, not in server-side code. Server-side code does not run in a browser! 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? Yes, finally. > > 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 would be relevant if it affected the server's ability to run the code. But such an update would not be affected by activex being allowed or not allowed in the browser. > > 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. It would certainly be consistent if you were using these ADODB objects in client-side code. > >> (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. No. ASP is not the code. ASP is the server-side "platform" in which server-side script is executed. Client-side script is code that runs in the browser. In IE, it can be either vbscript, jscript or javascript. In other browsers it is pretty exclusively javascript. If you can see the script when you view a page's source in the browser, you are looking at client-side script. > >>> 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. What are the exact settings that need to be made to cause the behavior to occur, please. As Mark said, there are many activex settings in the browser configuration. And which browsers are we talking about please? >> >> 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? Yes, some browsers don't even support activex - would file transfers work if activex was required? > Since that isn't what happens, and success or failure can > be determined by ActiveX settings on the browser, what am I missing? You're missing what the root symptom actually is: what is actually missing from the Request that is causing the server-side code to fail. >> 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.  So what is the answer? At what point in the process do you see the failure? > > The other question being, why does it succeed when ActiveX is > available in the client-side browser? > I can't tell that without seeing the behavior. -- HTH, Bob Barrows |
|
|
|
|
|||
|
|
| |
|
Guest
Posts: n/a
|
|
|
|
|
||
|
Guest
Posts: n/a
|
Bob Barrows wrote:
Neil Gould wrote: >> 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, > > ... in client-side code, not in server-side code. Server-side code > does not run in a browser! > > 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? > > Yes, finally. > As in... "Yes, we have no bananas"? > Client-side script is code that runs in the browser. In IE, it can be > either vbscript, jscript or javascript. In other browsers it is pretty > exclusively javascript. If you can see the script when you view a > page's source in the browser, you are looking at client-side script. > Just to be clear, I'm not talking about any code that can be seen when viewing the page's source. > What are the exact settings that need to be made to cause the behavior > to occur, please. As Mark said, there are many activex settings in the > browser configuration. And which browsers are we talking about please? > I'm talking about IE (it would be sufficient to limit users to IE for this purpose if the problem remains indeterminate and no other solution can be found). The upload operation reliably fails with IE >= 6 if ActiveX is globally disabled and fails with any browser that doesn't support ActiveX, e.g. FireFox (don't know about the various ActiveX emulators for FF). That's where I started with all this, and what drove me here. >> Since that isn't what happens, and success or failure can >> be determined by ActiveX settings on the browser, what am I missing? > > You're missing what the root symptom actually is: what is actually > missing from the Request that is causing the server-side code to fail. > It's quite likely that I'm missing what the root cause of the problem actually is, as this discussion would be unnecessary. If you think my focus should be on the Request object, please explain your thinking and I'll explore it further. >>> 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. > > So what is the answer? At what point in the process do you see the > failure? > As best I can determine, it is after Request.BinaryRead and before the file transfer takes place. There is no error given ("ON ERROR RESUME NEXT" ... is disabled), the process just aborts. Believe it or not, this discussion has been helpful, and again thanks. At least I have some things to look into. Neil |
|
|
|
|
|||
|
Guest
Posts: n/a
|
|
|
|
|
||
|
Guest
Posts: n/a
|
|
|
|
|
||
|
Guest
Posts: n/a
|
"Neil Gould" <> wrote in message news:... > 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)? The direct answer to your question is, you must clear the kill bit in the registry on the client system. I can never remember the exact key, so this is how I find it: Search the registry for "ADODB.Stream"; Copy its CLSID into the clipboard; Select the key after HKLM\Software\Classes in regedit; Search for the CLSID from there (paste from clipboard into search); This will take you to the key: HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Internet Explorer\ActiveX Compatibility\{00000566-0000-0010-8000-00AA006D2EA4} Under that is a DWORD item named Compatibility flags. The value 0x0400 is the imfamous kill bit; set it to 0, kill bit is clear, ADODB.Stream rides again. (You must close all open instances of IE before it takes affect.) But be advised that every single time a new kill bit is added to the list of patches, Windows Update will break ADODB.Stream again. Now as for the rest of the thread (that has been posted since I was last here)... wow, a storm of confusion! My comments pertained exclusively to use of ADO in client side script (assumed to be running in the context of an HTML document, rendered by IE.) If you create an ADO object in code in a SCRIPT tag (that does not set the runat=server attribute) then that object is created on the client. Whether or not ASP was used to emit that script is of no consequence. I think the lines get blurred when we fail to consider what's being rendered to the response (which may well include some script code) as opposed to what's running on the server. A conscious effort must be made to clearly understand which side everything is running on. (A debugger can be of great assistance, when trying to visualize this.) Bob, I assumed that he has some client-side ADO usage based on the way he described the problem, and how/when it manifested. If the problem was\is affected by changes to browser ActiveX settings, and the operative object is ADODB, then by definition he must be using client-side ADO (whether he realizes it or not.) Also, the scenario he described was familiar, I have had occasion to use client-side ADO, and I've even used the Stream [with a Recordset] to upload binary content to SQL image fields. (I realize storing files in the db is not considered a 'best practice', but assert that it can be the best solution in some scenarios.) With binary data Recordset.Field(x).SetChunk cannot be used in a script, because there is no reliable way to read the binary data from file to a variable. ADODB.Stream.LoadFromFile, otoh, does load binary data, and the return of the Read method can be assigned to a long-binary field's value property. The Recordset can then be persisted to XML and sent to the server; the persistance provider encodes the binary data as hex-text. (A server-side Stream could be used to write the binary data to file.) This combination of client-side and server-side ADO makes some sense when the data is going directly into a db, but as we've established, using a stream on the client is impractical for all but a very obscure niche (that can tolerate ongoing random breakage that requires user intervention to fix.) Otoh, it does not make sense when uploading to the server's file system, posting the file in a form, and calling BinaryRead to get it from the request is entirely more practical, and more efficient as well. The only trick is stripping the MIME header off of the data. A server-side ADODB.Stream comes in damn handy when performing this task, but as Bob has said [in an extreme number of different ways] that is not affected in any way by client browser settings (it merely adds yet another layer of semantics confusion.)  Hope this clears it up at least to some degree. (Apologies for not watching this thread a little more closely.) -Mark > -- > Neil > > > > > |
|
|
|
|
|||
|
Guest
Posts: n/a
|
Mark,
Mark McGinty wrote: > "Neil Gould" <> wrote in message > news:... >> 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)? > > The direct answer to your question is, you must clear the kill bit in > the registry on the client system. I can never remember the exact > key, so this is how I find it: > > Search the registry for "ADODB.Stream"; > Copy its CLSID into the clipboard; > Select the key after HKLM\Software\Classes in regedit; > Search for the CLSID from there (paste from clipboard into search); > > This will take you to the key: > > HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Internet Explorer\ActiveX > Compatibility\{00000566-0000-0010-8000-00AA006D2EA4} > > Under that is a DWORD item named Compatibility flags. The value > 0x0400 is the imfamous kill bit; set it to 0, kill bit is clear, > ADODB.Stream rides again. (You must close all open instances of IE > before it takes affect.) > > But be advised that every single time a new kill bit is added to the > list of patches, Windows Update will break ADODB.Stream again. > > > Now as for the rest of the thread (that has been posted since I was > last here)... wow, a storm of confusion! My comments pertained > exclusively to use of ADO in client side script (assumed to be > running in the context of an HTML document, rendered by IE.) If you > create an ADO object in code in a SCRIPT tag (that does not set the > runat=server attribute) then that object is created on the client. > Whether or not ASP was used to emit that script is of no consequence. > > I think the lines get blurred when we fail to consider what's being > rendered to the response (which may well include some script code) as > opposed to what's running on the server. A conscious effort must be > made to clearly understand which side everything is running on. (A > debugger can be of great assistance, when trying to visualize this.) > > Bob, I assumed that he has some client-side ADO usage based on the > way he described the problem, and how/when it manifested. If the > problem was\is affected by changes to browser ActiveX settings, and > the operative object is ADODB, then by definition he must be using > client-side ADO (whether he realizes it or not.) > > Also, the scenario he described was familiar, I have had occasion to > use client-side ADO, and I've even used the Stream [with a Recordset] > to upload binary content to SQL image fields. (I realize storing > files in the db is not considered a 'best practice', but assert that > it can be the best solution in some scenarios.) > > With binary data Recordset.Field(x).SetChunk cannot be used in a > script, because there is no reliable way to read the binary data from > file to a variable. ADODB.Stream.LoadFromFile, otoh, does load > binary data, and the return of the Read method can be assigned to a > long-binary field's value property. The Recordset can then be > persisted to XML and sent to the server; the persistance provider > encodes the binary data as hex-text. (A server-side Stream could be > used to write the binary data to file.) > > This combination of client-side and server-side ADO makes some sense > when the data is going directly into a db, but as we've established, > using a stream on the client is impractical for all but a very > obscure niche (that can tolerate ongoing random breakage that > requires user intervention to fix.) > > Otoh, it does not make sense when uploading to the server's file > system, posting the file in a form, and calling BinaryRead to get it > from the request is entirely more practical, and more efficient as > well. The only trick is stripping the MIME header off of the data. > A server-side ADODB.Stream comes in damn handy when performing this > task, but as Bob has said [in an extreme number of different ways] > that is not affected in any way by client browser settings (it merely > adds yet another layer of semantics confusion.) > > Hope this clears it up at least to some degree. (Apologies for not > watching this thread a little more closely.) > > > -Mark > Thanks, once again for a thorough explanation. This is the exact method employed by the upload script, so I believe you have a solid grip on what I've been experiencing. I obviously haven't been clear in my presentation, and that lead to much confusion about the server-side vs. client-side matters. I thought that all ASP was server-side only, and couldn't be affected by browser settings, but the odd instance of what I've observed with non-ActiveX enabled browsers threw me for a loop. I will look to see whether "runat=server" is explicitly set in the script, and keep my fingers crossed that this will clear up the problem, as it makes little sense to try to fix it on the client side, and it would be nice to get beyond IE in our environment anyway. -- Best, Neil |
|
|
|
|
|||
|
Guest
Posts: n/a
|
|
|
|
|
||
|
Guest
Posts: n/a
|
|
|
|
|
||
|
|
| |
|
| Thread Tools | |
|
|
Similar Threads
|
||||
| Thread | Thread Starter | Forum | Replies | Last Post |
| Adding quick-release to a non-quick-release tripod head | ste7esmith@hotmail.com | Digital Photography | 4 | 11-20-2006 03:19 PM |
| Quick Question Quick Answer | JKop | C++ | 11 | 05-24-2004 09:46 PM |
| Quick Restore for a Compaq not so quick! | Croos Bustamunky | Computer Support | 2 | 05-15-2004 04:17 AM |
| PanasonicBQ390 "quick" charger - How quick? | Ol' Bab | Digital Photography | 1 | 01-17-2004 06:54 AM |
| test test test test test test test | Computer Support | 2 | 07-02-2003 06:02 PM | |
