[AccessD] Access and SQL Server

True,  I missed the sneaky conflation of the terms "web based" and AJAX :-)

-- 
Stuart

 On 2 Mar 2011 at 11:18, Shamil Salakhetdinov wrote:

> Hi Stuart --
> 
> <<<
> That is a perfect description of a "synchronous" connection.  Send a
> request and wait for a reply before doing anything else. >>> But
> waiting "for the remote server to respond" in the case of AJAX doesn't
> mean stopping/blocking browser - such a waiting mean asynchronous
> "listening" for MS SQL to process (a set of) SQL requests, and when
> any one of the latter is ready asynchronously process its result
> (set).
> 
> Thank you.
> 
> --
> Shamil
> 
> -----Original Message-----
> From: accessd-bounces at databaseadvisors.com
> [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Stuart
> McLachlan Sent: 2 ????? 2011 ?. 2:55 To: Access Developers discussion
> and problem solving Subject: Re: [AccessD] Access and SQL Server
> 
> See inline.
> On 1 Mar 2011 at 15:26, Jim Lawrence wrote:
> 
> > I would suggest that most MS SQL applications are web based and
> > therefore are using asynchronous type connections... they connect,
> > call to a SP and wait for the remote server to respond. When the
> > data is ready for receipt your Ajax connections notes data and the
> > population of the recordsets begin, then connection is terminated.
> > 
> 
> That is a perfect description of a "synchronous" connection.  Send a
> request and wait for a reply before doing anything else.
> 
> > I would suspect that MS SQL runs similar to Oracle. Oracle just has
> > more of its internal features exposed so I doubt whether there is
> > any difference. When accessing data on an Oracle server the data
> > request is queued, when the system has time it checks the request
> > and then retrieves any data. It then calls the remote site
> > indicating that the data ready, when the remote site says 'yes', the
> > data is transferred.
> > 
> > That does not describe a synchronous connection to me.
> > 
> 
> No, that is asynchronous.  But that is only one of the ways Oracle
> works, it also works asynchronously:
> 
> 
> From my reading of this link, synchronous connections are the default
> in Oracle to. Note the use of the word forced in the last sentence.:
> 
> http://www.di.unipi.it/~ghelli/didattica/bdldoc/A97329_03/integrate.90
> 2/a952 65/wfapi11.htm
> 
> <quote>
> A workflow process can be either synchronous or asynchronous. A
> synchronous process is a process that can be executed without
> interruption from start to finish. The Workflow Engine executes a
> process synchronously when the process includes activities that can be
> completed immediately, such as function activities that are not
> deferred to the background engine. The Workflow Engine does not return
> control to the calling application that initiated the workflow until
> it completes the process. With a synchronous process, you can
> immediately check for process results that were written to item
> attributes or directly to the database. However, the user must wait
> for the process to complete. ... An asynchronous process is a process
> that the Workflow Engine cannot complete immediately because it
> contains activities that interrupt the flow. Examples of activities
> that force an asynchronous process include deferred activities,
> notifications with responses, blocking activities, and wait
> activities. </quote>
> 
> -- 
> Stuart
> 
> 
> > > Why is the default connection method to SQL Server synchronous?
> > > 
> > > 
> > > -- 
> > > Stuart
> > > 
> > > On 1 Mar 2011 at 8:41, Jim Lawrence wrote:
> > > 
> > > > Real SQL DBs are designed to be asynchronous. Just because you
> > > > can work around its philosophy of design does not mean you
> > > > should.
> > > > 
> > > 
> > > 
> > > -- 
> 
> -- 
> AccessD mailing list
> AccessD at databaseadvisors.com
> http://databaseadvisors.com/mailman/listinfo/accessd
> Website: http://www.databaseadvisors.com
>