🚀 go-pugleaf

Greg

I changed from dBase DML to SQL about three months ago. If you plan to
update to version 7.0, I strongly suggest you start using it. To make a
long story short, we have four file servers on our LAN which is a part of
the base WAN. Each of these servers are running Windows NT server as an OS.
We do have MS SQL running on some of them, but I do not recommend it. It
requires a administration to constantly monitor it. NT requires a user
license for each user, but I don't think it cost much for each license. I
use what Borland refers to as Local SQL from my apps. This means there is
NO DBMS (MS SQL, Ect.). The tables are DBF format. Basically they look like
an extention of my local drive, but are shared by many. File I/O is handled
by the BDE and works as described in these threads. One app I have written
is a read only report generator. It uses a single table with about 600,000
records (and is growing at 10,000 records per month). Using SQL I can
generate a monthly report which consist of scanning these records and doing
some heavy calculations in about 1.5 min. Another app has an input form
with some 30 fields to add or update and takes only milliseconds to update.
The only problem I found was, SQL under 5.6 does not support MEMO fields.
Oh, one thing we are running Ethernet LAN. Even though 5.6 only supports a
subset of SQL 92, I would never return to DML. Once you get use to it
(there is little documentation), it is simple. Hope this will help.

Joe

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