RE: Access & Scaling

Dean,

You are comparing apples and oranges here. While you say that the VB program
was stripped of its SQL it was also stripped of its "data widgets." Data
widgets (aka bound controls) are really cool from a prototyping point of
view, but I've found them to be an absolute pig at a production level. More
direct data access may have saved your VB app. Also, why was the VB app
going to SQL server to then go to Oracle, seems like it was jumping through
hoops to get the data. 

-Walden

-----Original Message-----
From: DAsmussen@aol.com [mailto:DAsmussen@aol.com]
Sent: Friday, January 08, 1999 9:51 PM
To: MIDRANGE-L@midrange.com
Subject: Re: Access & Scaling


Bruce,

In a message dated 1/8/99 2:49:05 PM Eastern Standard Time,
crashshw@ix.netcom.com writes:

> I think most of us really understand the Access is a desktop solution not
a
>  fullon "enterprise" solution. Now, MS sells SQL as its "enterprise" tool;
>  so, what is your experience and opinion of SQL v6.5 or better yet v7.0
vs.
>  DB2/400. I think that's more of an apples to apples comparison than
Access
>  vs. DB2/400.( Not that I think it's a perfect matchup but I'm trying to
be
>  non-partisan here). While we're at this debate, how come nobody has
>  mentioned anything about Oracle/Unix or this a MS bashing rave?

During a project less than two years ago, the client hired an Access
consulting "guru" to build a consolidated material planning system to run
over
the LAN.  With 9K records (that needed to be consolidated, selected, and
ordered) and one user, the application absolutely died.  Shortly after
completion, the client hired a full time employee with Access experience who
quickly determined that the "guru" had used the older 1.x data access
methods
instead of those inherent with Access 2.x -- after changing out for 2.x
methods, the application (still with one user) might actually have been
mistaken for being alive by someone not paying close attention.

New employee also knew VB, so the Access application was rewritten in VB 4
using "data widgets" and an SQL server 6.x access to an Oracle database on
the
LAN.  With the same one user and data requirements, the application appeared
to be either near death or on an extremely large dose of NyQuil.  The VB
application was stripped of its SQL and its data accesses rewritten to use
ESS/400 pointing at the AS/400 (model 320, 4-way) with some data access
programs written in OPM RPG resident on the /400 to subset the data and the
planning system ABSOLUTELY SCREAMED!

To be fair, LAN applications at the time ran through a rather constrained
gateway instead of the IP addressing used now.  Still, and I don't pretend
to
know how LANs are architected beyond NOS and protocol, AS/400 connections
were
running through that same gateway.  Why should the application run so much
faster on the /400 from the same PC's that performed so poorly on the LAN?
I
don't pretend to know.  I _DO_ know that, despite recent OS/400 performance
enhancements, SQL still runs _MUCH_ slower on the /400 than it does on other
platforms according to those that should know.

I don't know that this is an "MS bashing" thread.  It's just that AS/400
professionals are more likely to have dealt with Micro$oft products than any
other.  IBM offers support for MS products, and some number of people (of
which Bill Gates does not seem to be aware) run some flavor of the MS
operating system on their PC's.  We tend to try to work with what we already
have, rather than paying a huge site license for some other product.

JMHO,

Dean Asmussen
Enterprise Systems Consulting, Inc.
Fuquay-Varina, NC  USA
E-Mail:  DAsmussen@aol.com

"A closed mouth gathers no feet." -- Anonymous
+---
| This is the Midrange System Mailing List!
| To submit a new message, send your mail to MIDRANGE-L@midrange.com.
| To subscribe to this list send email to MIDRANGE-L-SUB@midrange.com.
| To unsubscribe from this list send email to MIDRANGE-L-UNSUB@midrange.com.
| Questions should be directed to the list owner/operator:
david@midrange.com
+---
+---
| This is the Midrange System Mailing List!
| To submit a new message, send your mail to MIDRANGE-L@midrange.com.
| To subscribe to this list send email to MIDRANGE-L-SUB@midrange.com.
| To unsubscribe from this list send email to MIDRANGE-L-UNSUB@midrange.com.
| Questions should be directed to the list owner/operator: david@midrange.com
+---