[AccessD] Access and SQL Server

Shamil Salakhetdinov shamil at smsconsulting.spb.ru
Wed Mar 2 02:18:01 CST 2011


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.902/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.
> > > 
> > 
> > 
> > -- 




More information about the AccessD mailing list