🚀 go-pugleaf

Greg

These authors must be fresh out of collage and do not know the history of
SQL or they could work for MS. Find a book with SQL history. I think the
book that came with VDB7 (from Borland 'Learn SQL in 21 days') has some
history. Read it. I will check my library at home and get back to you. But
at any rate what it stands for does not matter. It's what it will do for
you that does matter. Check your documentation for the development system
you are using as no one sticks to the standard. I have found ANSII 92 is
just a guide line not a standard.
-- 
Joe  < jyuzamas@wrdiss1.robins.af.mil or jyuzamas@sprynet.com >

Greg Hill <ghill@n2.net> wrote in article <34B57D9C.1A95@n2.net>...
> 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
>