Can filepro do drill downs like acess?

[Fairlight]

>From inside the gravity well of a singularity, Bill Vermillion shouted:
> On Fri, Mar 26, 2004 at 12:28:22AM -0500, John Esak thus spoke:
> > 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.

I'm not saying it can't be coded in fP, but it's certainly not inherently
present.  No offense was intended.  But one mistake by someone under the
wrong conditions with some code that wasn't quite robust enough, and it
could cost someone.

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

That's the way I read the specifications, yes.  Let's say you want to
update the GL, but you have a detail record off in a profit centre detail
record somewhere.  If something fails to update for some reason, the entire
transaction, everything that's been done to that point, is rolled back off
as if it didn't happen.

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

Basically.  Or inventory vs sales.  You get a sale in a web storefront,
and there's no inventory to handle it.  The transaction should be not be
committed so that, for instance, the part of the transaction that debits
their credit card is never actuated.

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

Yeah...that can come in handy if something goofy happens.  The
transactional logging takes oodles of disk space depending what you're
doing, but space is cheap nowadays, and it can save someone lots of money.

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

I was with you through the part about the system being brought back up.  I
didn't get what you meant after that.

The Network Appliance (the real ones) have an -excellent- snapshot facility
under Solaris.  It saved my ass -again- the other night when I wiped
something I inadvertantly had meant to save.  There are 10 hourly, 9
nightly, and one master backup snapshots.  There's a .snapshot directory
hidden in any directory, each containing hourly.[0-9], daily.[0-8], and
snapshot_for_backup.0 as well.  Any of those directories has a snapshot
from a point in time, so every few hours you get a new snapshot.  It
doesn't seem to affect performance at all, and its VERY handy being able to
have users get their own files without going to tape or bothering an admin.

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

Not so far as I've read.  You have it pegged accurately to the best of my
knowledge, and it falls into line with how I read the concept as applied in
most databases, and MySQL in specific.

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

Row+Column locking?  That could be handy.  I think column locking alone
would be useless, but if you combined row and column, that would be the
ultimate.  I wonder how much overhead that generates though... 

mark->
-- 
Bring the web-enabling power of OneGate to -your- filePro applications today!

Try the live filePro-based, OneGate-enabled demo at the following URL:
               http://www2.onnik.com/~fairlite/flfssindex.html