Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!mailrus!wuarchive!gem.mps.ohio-state.edu!ginosko!uunet!dgis!daitc!jkrueger
From: jkrueger@daitc.daitc.mil (Jon Krueger)
Newsgroups: comp.databases
Subject: Re: Parsing Query Languages in the Client or Server
Message-ID: <638@daitc.daitc.mil>
Date: 25 Sep 89 20:25:59 GMT
References: <6155@sybase.sybase.com> <6167@sybase.sybase.com> <1989Sep24.215650.15732@odi.com>
Organization: DTIC Special Projects Office (DTIC-SPO), Alexandria VA
Lines: 42

dlw@odi.com (Dan Weinreb) writes:

>There's one aspect of this standardization that I've never understood.
>The ANSI SQL definition provides a standard for queries to relational
>databases.  However, there doesn't seem to be anything that provides a
>standard describing the format of the data returned by the server to
>the client.  For example, what delimits one value from the next, or
>one tuple from the next?  Are floating point numbers sent in an ASCII
>representation, or binary using IEEE format, or what?

Excellent point.  And it gets worse.  How does the client find out how
to parse and generate vendor X's date and money data types?  His
abstract data types of the future?  How does the server flag nulls?
How does the server return errors and exceptions, e.g. permission
denied, integrity violation, domain violation, deadlock, end of table,
end of transaction (committed), disk full, disk read error, network
disconnect?

How does the client tell the server it's ready for the next row (or
group of them)?  How does the client tell the server to break out of a
retrieve loop?  How does the client tell the server to terminate
whatever it's doing ("guess I didn't want to know that bad")?  How does
the client start and end sessions (connect and disconnect)?

And that's not even implementing merely desirable features like the
server telling the client how many rows were affected, or what a
specific integrity violation was, or the client telling the server
limits for query processing ("expensive query trap").  And it's
assuming that providing clean, secure lines will be done by something
else, and in a transparent manner.

Nasty, eh?  Still think that Intergalactic Dataspeak will solve all
your problems :-) ?  Yes, it's a start.  It's kind of like getting
everyone to agree on how to build cars and roads so that any car can
drive on any road, but lacking a standard for maps:  somewhat fewer
cars will arrive at their destination than set off on the trip.

-- Jon
-- 
Jonathan Krueger    jkrueger@daitc.daitc.mil   uunet!dgis!jkrueger
Isn't it interesting that the first thing you do with your
color bitmapped window system on a network is emulate an ASR33?