XPost: microsoft.public.sqlserver.programming   
   From: jmostert@xs4all.nl   
      
   On 2012-08-01 00:02, Gene Wirchenko wrote:   
   > On Tue, 31 Jul 2012 14:25:12 -0400, "Bob Barrows"   
   >   wrote:   
   >   
   >> Gene Wirchenko wrote:   
   >>   
   >>>    4) I would like to avoid using ActiveX to communicate between the   
   >>> Web page and SQL Server and preferably without having to add more   
   >>> software to the server.  Otherwise, my app is going to be limited to   
   >>> IE.   
   >> The only time scripting language will restrict you to IE is if you use   
   >> vbscript in client-side code.   
   >>   
   >> There are no such restrictions in server-side code: the language being used   
   >> in the server-side code to generate html to be sent to the browser is   
   >> completely browser-independent. The html that is generated is what can limit   
   >> the browser being used. Browser-restricted html can be created by any   
   >> scripting language.   
   >>   
   >> So, depending on what you mean by "ActiveX"  (are you talking about ADO, or   
   >> perhaps ADO.Net? ), its use or avoidance will not have an effect on what   
   >> browsers can be used. Even if you are planning to directly access the   
   >> database from the client-side code (which can really only work in a WAN   
   >> environment) it is certainly possible to use ADO in javascript, which is   
   >> browser-independent.   
   >   
   JavaScript is neither browser independent (subtle but important differences   
   exist), nor does support for instantiating ActiveX-objects exist outside of   
   JScript and Internet Explorer. Thank heavens for small favors.   
      
   JScript does exist as its own engine in the Windows Scripting Host, but then   
   that's not a browser.   
      
   >       My understanding is that in order to access the data with the   
   > browser, I have to create an ADODB.Connection object and an   
   > ADODB.Recordset object using ActiveXObject() which Firefox (for   
   > example) does not have.   
      
   Like Bob said, you create these objects on the server side, using   
   Server.CreateObject(). The browser never sees these objects. In fact, the   
   browser doesn't know a database is involved at all -- the server is the one   
   contacting the database and formatting the data as HTML. The communication   
   between the browser and the site is limited to HTTP.   
      
   Although it is in fact possible to use these components client-side (in an   
   IE intranet only), that's like enjoying hot cocoa by snorting it up your   
   nose: weird, uncomfortable and altogether missing the point. Basically, it's   
   a terrifically inconvenient way of writing an application you could write   
   much better using almost any other client-side technology, like .NET.   
      
   There is no browser-independent way of accessing a database from the client   
   side, unless you consider HTML5's forays in that area (web SQL databases,   
   since abandoned). Even then it's about local databases, not database servers.   
      
   --   
   J.   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)