Can filepro do drill downs like acess?

[Bill Vermillion]

On Fri, Mar 26, 2004 at 12:28:22AM -0500, John Esak thus spoke:

> > On Thursday 25 March 2004 14:13, Tony Freehauf wrote:

> > > can filepro do things that look like acces drill downs? can
> > > we compete with this kind of programing? thanks old tony

> > You can do DrillDown with straight filePro. The trick is to
> > do a PUSHKEY "ENTR" just before the browse lookup then use
> > WAITKEY to trap the keystrokes after the browse lookup exits.
> > ...

.... (deletions)

> Jerry is absolutely right. You certainly can do "drilldowns"
> in filePro. However, his saying "The trick is..." is not
> quite right. There is no "trick"... at least no specific one
> that I know of, to do a drilldown. I have written hundreds
> of drilldown functions (and that is not an exaggeration) of
> every flavor, type, need. etc. There is no particular way of
> writing them. Mostly, any kind of drill down situation can be
> accomplished with browse lookups quite easily. Sometimes you
> want to remember (store) the keys from where you came so you
> can drill back up to where you were, other times you don't want
> that functionality. Jerry must be talking about some kind of
> special situation that he feels he needed WAITKEY to implement.
> I'm not sure exactly what, but it is nothing special to do with
> a drilldown situation that I know about.

> And as for accounting in general, as Bill Vermillion said, it
> just matters that you write your system in such a way that
> transactions can not be changed, but rather modified with other
> transactions. Drilldowns have zero to do with a well written
> application's functionality. So, to suggest as some others in
> this thread did, that accounting should only be done with a
> transactional committ/rollback database or whatever... well,
> sorry that is simply preposterous.

And that suggestion is certainly not the way I understand
transaction, commits, and roll-backs either.

My understanding is that all parts of a transaction must proceed
correctly and if any part fails they are not processed/committed.

This could be like something in an ATM environemnt to ensure that
all of the pieces of the transaction are processed correctly - so
that various part of the database that may reflect a deposit or
withdawal are all completed successfully before they are fully
commited.  This prevents overlapping functions which may conflict
with each other.

Rollbacks can let you move a database back to a point in time and
are usefull in an abnormal case where something may be corrupt and
you restore a known working backup and the process the transactions
against that to bring it to a valid, correct, and current working
state.

The snapshots used in some backup systems strike me as a similar
approach.  You 'snapshot' the state of the system and then perform
a backup while the system is operational, but disk writes are
updated outside of the snapshot and when the backup is finished,
the system is brought to it's normal state with items that may have
been frozen in time by the snapshot brought up to date.

Am I off base in my understanding of transaction and rollbacks.

I first saw them in life [ as opposed to reading abou them on large
environment ] on an NCR Unix system with a data base called C
<something>.  It was totally written C, was completely
transactional with rollback.

And while I drift this topic a bit further there has been talk on
this group at times of both record locking and file locking.  I do
not recall what database it was, but it had the concept of field
locking.  That mean two people could be working on the same record
and each could update different fields.  That surely seems to be a
handy concept if you have large numbers of users manipulating the
databases.

Bill
-- 
Bill Vermillion - bv @ wjv . com