"Steve Dirickson" <[log in to unmask]> jumps the gun in message
news:a2io7f07v0@enews4.newsguy.com...

> > Often by bolting the jobstreams together from a 'kit of
> > parts', not even generating the jobs against each individual database,
but ensuring
> > manually that the eventual outcome would be, AFAICT, the
> > desired target structure.

> > (ii) In the meantime, I'd like a way to pre-validate an Adager
> > jobstream. As you can imagine, not all the ones above ran first time.
> > Although Adager was very good at stopping on errors before
> > any work had been done, I was still 'validating' my jobstreams in
implementation
> > time.

> So, on balance, how much time did this "timesaving shortcut" of
> stitching together disparate manually-edited Adager jobs really save?
> That's what I thought....;-)

Hey, wait for the answer!

A *lot*, believe me. Cut'n'paste beats 16 interactive conversations every
time.

And every glitch I got in any of my scripts, I got before Adager started
processing the database. And every script, when it eventually ran, got the
database *right*.

Any glitch in any of 16 dialog-built scripts, each of which was 'guaranteed
to work' because it had been done interactively, would have shown itself
only *after* the Adager transformation. And would have required anything
from a further pass to a restore/repeat to fix....

Now it might seem that any time I 'lost' fixing those scripts would be the
same no matter whether Adager gave me a pre-validation facility or not.
But I recognise two sorts of time - 'development time', normally during
normal working hours, and with the users still using their production
machines, and 'implementation time', normally out of hours (my hours), and
with any users for whom it is *their* hours, locked out of their machine.

Pre-validation would move the latter into the former, to everybody's
benefit.

> > But I had to blot out thoughts of how I could have used Flexibase for
> > this in each territory, giving it just the existing database there and
> > the target schema for the common structure, and letting *it* work out
> > the required changes, and making them.
>
> Which is why more than one of us continued to use FB for this kind of
> work long after it was obsolete.

Is it? What a shame. If you don't got jumbos and other whizzy-dizzy things,
it ought to be OK still.

Reckon Alfredo could put in a bid for the remains of Flexibase, and leverage
that 'Transmute to Schema' logic into Adager?

> > (i) I'd like it to be able to take a schema, deduce the changes, and
> > make them, a la Flexibase. This is, as Alfredo seems to
> > agree, Adager's biggest black hole.

> Wasn't there a schema-driven version of Adager at one time, at least
> in beta-test form?

There is limited schema-driven logic in our production Adager now. A start,
maybe, but way too limited to be useful to us.

> > It would also be useful to have a 'no update, no jobstream' mode. It's
> > frustrating to be unable to snoop round a database preparatory to
> > updating it, and to be denied access to Adager's Help while
> > planning how to update it, just because the database is in use, and
Adager
> > has no way to tell that you are 'just looking'.

> Absolutely; every database-maintenance tool should provide a "just
> testing" mode.

Yep.

--
Roy Brown

With the non-euro territories to synchronise on the new common db structure
'real soon now' :-(

* To join/leave the list, search archives, change list settings, *
* etc., please visit http://raven.utc.edu/archives/hp3000-l.html *