Can filepro do drill downs like acess?

[John Esak]

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

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

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

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

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

John