RE: Asynchronous vs Synchronous

Christine,

That is basically all "old hat" issues related to inadequacies of client/server architecture on some network implementations. e.g., back in some of the early DOS and Windows versions of Oracle's client side SQL*Plus, pressing "cancel" in the middle of a long running query didn't do anything until the server finished its processing. Oracle then added functionality to SQL*Net (etc) that would cause an client-side, user invoked "cancel" passed to the server side to stop runaway queries.

BTW, there used to be a SQL*Net (v1?) protocol that Oracle called "asynch". Don't know anything about it (except that I think it is obsolete).

regards,
ep

On 19 Jul 2000, at 11:00, Christine Turner scribbled with alacrity and cogency:

Date sent:      	Wed, 19 Jul 2000 11:00:00 -0800
To:             	Multiple recipients of list ORACLE-L <ORACLE-L_at_fatcity.com>
Send reply to:  	ORACLE-L_at_fatcity.com
From:           	Christine Turner <Christine.Turner_at_IPS-Sendero.com>
Subject:        	RE: Asynchronous vs Synchronous
Organization:   	Fat City Network Services, San Diego, California

> This is the response I received from my developer that he received
> from Crystal. Anyone have any comments?????

> -----Original Message-----
> From: David Denison [SMTP:david.denison_at_ips-sendero.com]
> Sent: Tuesday, July 18, 2000 3:47 PM
> To: Christine Turner
> Subject: Fw: CTL:20000717-10296 Automated Response:
>
> Here is that Crystal response concerning synchronous vs. asynchronous
> database connections.
>
> ----- Original Message -----
> To: <david.denison_at_ips-sendero.com>
> Sent: Tuesday, July 18, 2000 1:32 PM
>
>
> > This EMail was sent: 7/18/00 1:32:20 PM (Pacific Standard Time)
...

> > --------------------------------------------------------------------------
...

> >
> > Unfortunately what you're trying to do will cause a gpf, and let me
> > explain why.
> >
> > If we submit a query to your database (in this case Oracle), we send off a
> > SQL statement (i.e select * from table). Oracle processes that statement
> > and generates a dataset and passes that back to Crystal Reports to format
> > and display.
> >
> > If we cancel the job or close that preview window before that data comes
> > back there's no way to tell Oracle that we've cancelled that job and it's
> > going to continue sending data to memory that Crystal Reports has already
> > released back to Windows and it will crash. This bi-directional
> > communication would require an asynchronous database driver on BOTH the
> > Crystal Reports side of the connection and the Oracle side of the
> > connection. Unfortunately, to my knowledge, Oracle doesn't support an
> > asynchronous connection, and Crystal Reports only supports asynchronous
> > connections with a limited number of our database drivers.
Received on Wed Jul 19 2000 - 15:12:12 CDT