Can filepro do drill downs like acess?

[Jay R. Ashworth]

On Fri, Mar 26, 2004 at 07:14:31AM -0500, John Esak wrote:
> > >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 commit/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.
> 
> That is a little meaningless in this or any context. Of course code that
> isn't robust enough is going to be problematic and cost someone money and
> problems... period... any situation... any program. Commit/rollback will
> _not_ fix or _address_ this in any way... so I don't get your reason for
> saying it.
> 
> I did not take offense Mark. As for anything being inherently "in" any
> database when it comes to coding an application like accounting. The
> commit/rollback of most full RDBMS's is not useful on any kind of
> record-b-record basis. It is a functionality that has to be implemented by a
> sysadmin based on date/time stamp or something, and I don't think (well I'm
> pretty damn sure) it can be done on just some problem record.

That's mostly correct, yes.

>                                                              It is a tool
> used to keep an entire dataset synchronous and "correct". As regards helping
> in an application, specifically, I don't see how. We are not talking about
> "commit" for a single record or transaction here.

I can't figure out what you mean, though, by those three sentences,
taken together.

Transactions' job is to make certain that if you withdraw $20 from an
ATM *right at the same moment* that the bank is processing your checks
for the day, and both transactions (hey, what a cool word! ;-) try to
adjust your account balance, that you won't end up with $20 too much... 
or too little.  Even if the hardware or power fails.

Keeping all the various tables involved in a transaciton synchronized
so that the database remains coherent *is* precisely the issue.

And without DBMS implemented transactions, it can be proven
mathematically (though *I* am not competent to do so :-) that it's
impossible to maintain that coherence through any possible combination
of failures.

>  > > 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 is functionality that is coded into an application, it is not part of
> what commit/rollback is. The commit/rollback is simply the function used if
> the conditions you state are met. But this would never be an automatic
> thing.

A bit confusing. The code has to say when to *start* the transaction,
and when to commit or rollback, certainly. But the DBMS *has* to do the
work.

> > 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.
> 
> Sorry, I just don't understand this. Don't know what you mean. There is no
> way to tell a database this. Not unless you mean a simple type of processing
> which says the transaction has to balance or don't post it to some other
> part of the database. Trivial for filePro as well. Nothing inherent to
> commit/rollback here. I think you're mixing up the terms of commit and
> rollback. They are not part and parcel of each other.

Ok, John.  Time to stop talking and go do your research.

Bill is correct.  There's no way to tell *filePro* to do this.  There
most certainly is a wall to tell *any* SQL standard DBMS to do it, and
it works very nicely; has for 20 years.

> True, you have drifted this to an area I don't care about. I'll leave
> discussions not pertaining to filePro for others.

This *entire thread* hasn't pertained to filePro.

Cheers,
-- jra
-- 
Jay R. Ashworth                                                jra at baylink.com
Member of the Technical Staff     Baylink                             RFC 2100
The Suncoast Freenet         The Things I Think
Tampa Bay, Florida        http://baylink.pitas.com             +1 727 647 1274

        "They had engineers in my day, too."  -- Perry Vance Nelson