Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!ucbvax!mtxinu!sybase!binky!tim
From: tim@binky.sybase.com (Tim Wood)
Newsgroups: comp.databases
Subject: Re: Parsing Query Languages in the Client or Server
Message-ID: <6253@sybase.sybase.com>
Date: 24 Sep 89 21:16:53 GMT
References: <6155@sybase.sybase.com> <17450@pasteur.Berkeley.EDU> <632@daitc.daitc.mil>
Sender: news@sybase.sybase.com
Reply-To: tim@binky.UUCP (Tim Wood)
Organization: Sybase, Inc.
Lines: 29

In article <632@daitc.daitc.mil> jkrueger@daitc.daitc.mil (Jon Krueger) writes:
>
>>In article <6155@sybase.sybase.com> forrest@sybase.com writes:
>>("Parsing" here means just the context-free stuff; the semantic checking
>>pretty much has to be done in the server, which has the system catalogs.)
>
>One of the nice things about keeping the data dictionary in ordinary
>tables is that the application can use them to perform the same checks.
>This can help distribute the load by trapping bad queries before they're
>sent to the server.  But the server still has to check anyway for all
>the queries that are sent it.
>
>-- Jon

Yes, but in order for the application to test against the system tables,
it has to send more query language text to the server!  Granted, that
text will be predefined and parameterized, so presumably correct.
Still, a lot more work will be done (compared to the same functions
performed within the server) to avoid the cost of sending the bad query
than to just send it and let the server signal any error!  

Users expect friendly error handling from the server, regardless
of their applications; that's one of the inherent advantages and 
requirements of server designs.
-TW
Sybase, Inc. / 6475 Christie Ave. / Emeryville, CA / 94608	  415-596-3500
tim@sybase.com          {pacbell,pyramid,sun,{uunet,ucbvax}!mtxinu}!sybase!tim
Voluntary disclaimer: This message is solely my personal opinion.
		      It is not a representation of Sybase, Inc.  OK.