🚀 go-pugleaf

Joe Yuzamas wrote:
> 
> Greg
> 
> Some where along the line, people have lost track of what SQL is. 'SQL' is
> being used for anything connected with a database. SQL stands for "STANDARD
> QUERY LANGUAGE". It has nothing to do with servers, databases or
> development languages such as VDB. It is simply an interface to get data
> from a data source to an application. It does not require a file server, a
> network or even a DBMS (MS SQL SERVER, ORACLE). Many development languages
> now allow imbedded SQL commands. SQL commands can be used to access local
> DBF files or DBF files located on a file server via the net, but in either
> case NO DBMS SYSTEM IS REQUIRED as long as the server supports DBF formated
> files. No mid ware, no other support software is required. If the server
> does not support DBF files now a DBMS is required. If there are requirments
> that require DBMS funtions such as pre-triggers, ect, you will need a DBMS.
> I hope this may stop the misuse of the letters SQL.
> 
> --
> Joe  < jyuzamas@wrdiss1.robins.af.mil or jyuzamas@sprynet.com >
> 
> Greg Hill <ghill@n2.net> wrote in article
> <01bcd473$2448a740$828471cf@greg>...
> > I'm getting ready to set up a wan connection between two offices, I'm not
> > sure how much band width I'm going to buy yet but I'm guessing around
> > 64mbs.  I just did some testing using Visual dBASE 5.5 across a dial up
> > connection using Windows 95 on both sides and connecting using 28.8
> modems
> > on both sides.  I ran the DBASEWIN.EXE and the program files locally but
> > opened the tables on the host computer and it took about 5 minutes just
> to
> > open up 10 tables and set up the relationships no filters. Once the
> tables
> > were opened I brought the form up and it took about 5 minutes, once the
> > form was up navigation from one record to the next took about the count
> of
> > 8 to 10 seconds (no filters were active).  I executed an onclick event
> that
> > does a couple seeks and replaces, and that took about 5 minutes.
> >
> > I keep hearing this SQL stuff.  Things like it brings down the amount of
> > traffic across the wire, it is network aware you make a request and the
> > work is done at the Server using the servers memory/cpu and when it is
> done
> > it sends back only the requested  information.  I'm not sure how true all
> > of this is and also how it applies to my particular applications.  I'm
> > running an application that shows appointments for the day and there are
> 4
> > users changing the status of each record that is scrolled to plus there
> > will be about 5 other users that will be looking at data pulling up
> records
> > for odd reasons, reports will be pulled all day long.  This database will
> > contain about 25000 records total.  There is about 125 appointments per
> day
> > and all 125 records require some kind of updating by at least 4
> > Users/Dispatchers throughout the day.
> > Should I be considering SQL and if I do how could it help if my app
> demands
> > constant refreshes.
> > If I face the reality of my situation, I think I'm up for a rewrite on
> this
> > app I think I would have to write something that would download the data
> to
> > the local PC and keep synchronizing it at certain breaking points during
> > the day.  Which means the end-users and the Boss who wants dynamic
> reports
> > will be a little disappointed.
> >     I think one of the reasons they wanted to put this WAN up is so that
> > they did not have to pull separate reports and dial up other locations to
> > get reports, they wanted  reports that reflected all offices.  Later they
> > will be adding another location so the demand is there for a WAN.
> >
> > I know this is rather long but it is the only way I could summarize all
> of
> > it.
> > Any suggestions appreciated.
> > Thanks, Greg
> >
> >
> >

How is this message still haunting me?  It must be 2 or 3 months old.  I 
learned from you and others in this news group what Client/Server is and 
what SQL is and the basics of they work together or apart.

I've also learned that there is not a true definition to SQL and that it 
is not an acronym or an abbreviation<g>.  See my reply to Keith C.
Thanks, Greg