🚀 go-pugleaf

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