Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!cs.utexas.edu!rutgers!uwvax!umn-d-ub!nic.MR.NET!hal!ncoast!telotech!bsa
From: bsa@telotech.UUCP (Brandon S. Allbery)
Newsgroups: comp.databases
Subject: Re: Parsing Query Languages in the Client or Server
Message-ID: <1989Sep29.172452.2619@telotech.uucp>
Date: 29 Sep 89 17:24:52 GMT
References: <6155@sybase.sybase.com> <6167@sybase.sybase.com> <1989Sep24.215650.15732@odi.com> <9463@blia.BLI.COM> <3715@rtech.rtech.com>
Sender: bsa@telotech.uucp (Brandon S. Allbery)
Reply-To: bsa@telotech.UUCP (Brandon S. Allbery)
Organization: _
	      telotech, inc. - Beachwood, OH
Lines: 22
In-reply-to: news@rtech.rtech.com (USENET News System)

In article <3715@rtech.rtech.com>, news@rtech (USENET News System) writes:
+---------------
| In article <9463@blia.BLI.COM> miket@blia.BLI.COM (Mike Tossy) writes:
| >Final note: parsing on the client does NOT mean you can use a dumb terminal
| >connected directly to a server.  You still need "smarts" on the client end.
| 
| Uh, nothing precludes having 'smart' front-ends which can trap lexical
| errors, if not some semantic errors, and dumb terminals which cant.
+---------------

I think the issue is more along the lines of how information OTHER than the
SQL statement itself is communicated between the front-end and the back-end.
The back end is going to require input and output bind specifications to be
sent to it, and will return output binding structures -- not to mention a
(binary!) SQLDA structure -- as a result of the SQL statement's execution.

++Brandon
-- 
-=> Brandon S. Allbery @ telotech, inc.   (I do not speak for telotech.) <=-
Any comp.sources.misc postings sent to this address will be DISCARDED -- use
allbery@uunet.UU.NET instead. My boss doesn't pay me to moderate newsgroups.
** allbery@NCoast.ORG ** uunet!hal.cwru.edu!ncoast!{allbery,telotech!bsa} **