🚀 go-pugleaf

In article <92316.105420KSADEGH@auvm.american.edu> Kayvon Z. Sadeghi <KSADEGH@auvm.american.edu> writes:
>Hi out there
>
>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 would appreciate if someone could give me some pointers on this.
>------------------------------------------------------------------------
>Kayvon Sadeghi                    k.sadeghi@ieee.org
>Voice:202/244-0789

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.

Even C/S SQL databases don't always pass SQL.  If a stored procedure is
being invoked, then the message need only include the name of the
procedure.

	Scott Orshan
	TUXEDO Support
	UNIX System Laboratories
	908-522-5063
	sdo@usl.com

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

In article <paul.722141311@suite.sw.oz.au>, paul@suite.sw.oz.au (Paul Antoine)
says:
>
>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             s
>client/server
>>>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
>------------------------------------------------------------------------------


Perhapse I didn't clear myself, at least not good enough. What I meant was
why most of the client/server *data bases* use SQL. My appologies.
I know that some of the client/servers are not data bases, e.g. file servers
or printer servers have nothing to do with data base. So, I guess, I
should be more careful in future.


k1
---
------------------------------------------------------------------------
PUSH, if that doesn't work
PULL, if that doesn't work
we're probably CLOSED
------------------------------------------------------------------------
Kayvon Sadeghi                    k.sadeghi@ieee.org
Voice:202/244-0789