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} **