🚀 go-pugleaf

In <1992Nov17.160748.5948@cbnewsl.cb.att.com> sdo@cbnewsl.cb.att.com (scott.orshan) writes:

>In article <92316.105420KSADEGH@auvm.american.edu> Kayvon Z. Sadeghi <KSADEGH@auvm.american.edu> writes:
>>I was wondering why all the client/server systems use SQL as their manipulation
>>language. I don't recall seeing any client/server that works on OO or
>>hierarchy, for example. Is this because its easier to implement client/servers
>>in SQL or is there any especial reason.

>I'm not sure why you say that all client/server systems use SQL.
>Perhaps all client/server SQL database systems use SQL (a tautology),
>but some databases don't, and non-database client/server packages
>probably have no need to use SQL.

>For example, plain RPCs and TP Monitor C/S calls pass arbitrary information
>between clients and servers.  Most client/server access is probably
>just remote file access, and that has nothing to do with SQL.

And I'd even dispute that most C/S access is not remote file access (as in 
our C/S system that talks to 3270-based applications).  The TP monitor is
used to route the data, and is aware of the type and number of servers and
where they're running, but there's no restriction on the data (i.e. it
needn't be SQL!).

The confusion probably arises because most C/S systems are used to more
efficiently access corporate data - but this needn't be in the form of
direct database access.  A lot of it can also be done through existing
applications (as in our case).  It just goes to show that getting consensus
on the eternal question 'what is C/S?' is well nigh impossible,

Regards,
Paul (a Tuxedo fan)

------------------------------------------------------------------------------
Paul Antoine, Softway Pty Ltd			    Net: paul@suite.sw.oz.au
PO Box 305, Strawberry Hills, NSW 2012, Australia   Tel: +61 2 698 2322
79 Myrtle St, Chippendale, NSW 2008, Australia	    Fax: +61 2 699 9174
------------------------------------------------------------------------------