XPost: microsoft.public.sqlserver.programming   
   From: reb01501@NOSPAMyahoo.com   
      
   Gene Wirchenko wrote:   
   > On Wed, 01 Aug 2012 00:26:43 +0200, Jeroen Mostert   
   >  wrote:   
   >   
   >> On 2012-08-01 00:02, Gene Wirchenko wrote:   
   >   
   > [snip]   
   >   
   >>>       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.   
   >   
   >     I know that I create objects on the server side.  I also have to   
   > create objects on the browser side.  At this point in time, I do not   
   > have an alternative.  I have been looking for one.   
   >   
   >     I need data validation at the browser level.   
   Several option to avoid the need to directly query the database from the   
   browser:   
   1. Leverage some data caching in arrays on the client-side (provided the   
   data sets are not too large to overload the browser) to perform some of the   
   validations.   
   2. Use technology like JSON or AJAX to send requests to and receive   
   responses from a server page without needing to submit and reload the client   
   page.   
   3. There is also web service technology that can be leveraged   
      
   Seriously, there are people who are much more knowledgeable about this stuff   
   in relevant forums than I am (it's been several years since I created a web   
   application so I have failed to keep up in the technology, and I've never   
   created an internet application) - you really need to start asking these   
   questions in such a forum.   
      
   >   
   >> 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.   
      
   Except for the inconvenience of having to deploy all these fat clients to   
   all the user desktops. My company made the decision years ago to only   
   support IE. Yes, there have been some unhappy users, but we do have a   
   captive audience who need to use these applications to do their jobs, and we   
   do not have an army of testers and programmers to rewrite our applications   
   to ensure all browsers can be supported.   
      
   >>   
   >> 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.   
   >   
   >     I do not care so much about browser-independent as much as I   
   > would like to be able to use more than just IE.   
   >   
   Well, I thnk you have the only answer we can give you.   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)