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.