HP3000-L Archives

February 1999, Week 1

HP3000-L@RAVEN.UTC.EDU

Options: Use Monospaced Font
Show Text Part by Default
Show All Mail Headers

Message: [<< First] [< Prev] [Next >] [Last >>]
Topic: [<< First] [< Prev] [Next >] [Last >>]
Author: [<< First] [< Prev] [Next >] [Last >>]

Print Reply
Subject:
From:
Reply To:
Date:
Tue, 2 Feb 1999 00:35:16 GMT
Content-Type:
text/plain
Parts/Attachments:
text/plain (39 lines)
Jerry Fochtman wrote:
>
> At 02:35 AM 1/30/99 +0000, Tom wrote:
>
>
> Its unfortunately Mr. Thacker did not contact us after the application
> vendor's tool caused problems, for apparently he had the appropriate
> tool to correct the database problem that was introduced.... :-)

I was not the primary contact person when this occurred.

The problem occurred a number of years ago. I was a vanilla programmer
then and was not aware that my boss did indeed place a call to tell
Growthpower (Note: this was before Powercrew existed) what had happened.
Their response was to say that multiple volume sets was not supported
for Growthpower. (This was version 7.06). I would guess that it was
probably 5 or 6 years ago. It was at that time that my boss acquired
Flexibas and used that from then on. That was his solution.

I have recently moved to a new company which also uses Growthpower, but
with DBGeneral instead of the built-in File Expand of Growthpower.
(Growthpower 2000). We plan on replacing Growthpower within three years
simply because our volume is about to outstrip Growthpower's capacity.
(SO Number, Invoice Number, Customer Number, and so on are limited to 6
digits. Also, it's written in old classical HP basic).

Moving from Flexibas to DBGeneral was easy interface-wise. I can't
directly compare results because of the vast differences between shops -
200 users versus 18, a 968 vs a 967, 50000 parts vs 2000, 2000000
transactions vs 120000, and so on.

One note on this subject - if you ever compare two of these engines, the
second product will tend to appear faster because (1) the DB has already
been organized by the first engine, (2) there are probably unflushed
disc sectors still in memory which will cause much faster fetch, and so
on. The best thing to do is (if you have disc space) make an identical
copy of the database in another group and run engine 1 on copy 1 and
engine 2 on copy 2.

ATOM RSS1 RSS2