Add a .Workspace property to the DATABASE object. Also, add Properties to the WORKSPACE to reflect whether any TRANSACTTIONS are open.
There is currently no pointer from an open Database handle to point back to the Workspace it is a part of. There should be - we get away with this because Workspaces(0)(0) is the detault 99.999% of the time. However, what if it isn't? We can't tell form looking at the open database handle, and that's actually pa problem, especially if one needs to react, say in a bit of generic error handling code, to any pending/open/hanging TRANSACTIONS in the relevant WORKSPACE.
Which brings me to the second point - there is no available STATUS properties of the DBEngine, Workspace, or Database object to reflect if there are pending, open, or perhaps more to the point, "orhpaned" TRANSACTIONs happening in the CURRENT WORKSPACE. there have been long-standing (20+ years now) requests from Access Developers to remedy this glaring lack of needed error-handing data.
Mark Burns
shared this idea
8 comments
-
Mark Burns
commented
@Adrian,
lol...so did the developers who first requested this enhancement about 20 years back. :-) Only the ACE and Jet angles are new to the subject here.
-
Adrian Bell (MVP)
commented
PS. It's a shame that extra chatter doesn't encourage more developers to consider this idea for more votes. I think it's a good one.
-
Adrian Bell (MVP)
commented
Hi Mark.
If the code is written after the decision to add this, which surely it must be, then one could say that any such code should handle the possible scenarios adequately. I would expect to see an error thrown if a reference to non-existing property were attempted at runtime. This would be very similar to what happens now when cycling through controls on a form and trying to reference a property that didn't exist for that type of control (The .Value of a Label control for instance). Like you, I'd prefer an interface that could be inquired of rather than simply to rely on error handling, but either way you get what you need.
I don't see how this could affect any existing projects, but I hope I haven't missed something (Always possible).
-
Mark Burns
commented
@Adrian,
The real rub here is backwards-compatibility issues with actual JET DAO objects (as opposed to the newer ACE DAO objects). Since the Access team now has control over ACE, they could implement something like this rather feasibly, but - what to do when the implementation code is handed a JET DAO object of the DAO.Worspace type that would have no implementation support for the new interface/methods/properties? I'd suggest that throwing a trappable error would be acceptable, but then if that happens while processing in an error handler already... So, would the answer be to add a descriptor.property to the DBEngine/Workspace.Database object to reflect a JET or ACE source object type?, which brings the problem back to the backwards-compatibie interface issue yet again. So, it's not such a cut-and-dried issue, sadly.
-
Adrian Bell (MVP)
commented
Hi Mark.
I'm thinking, open to correction of course, that this would be straightforward to implement without upsetting any existing applecart. It's not like anything needs to be removed or changed from the original. Except in as much as is required to add the new features. Existing code/projects would be safe.
If what you say is what it takes then fine, but I don't imagine it should be necessary.
Obviously, this is a non-involved person speaking. We (MVPs) don't have that much of a view into what's going on at MSFT. This is simply my personal understanding at work here.
-
Mark Burns
commented
Adrian,
I wouldn't even care if they implemented this in a new interface, adding a Workspace2, Database2, DBEngine2 set of object identifiers which could polymorphically be accessed from the existing object handles (i.e. DIM oWkSp2 as DAO.Workspace2 : Set oWksp2 = <Existing .Worlspace object handle variable reference>) so that we could use the new/extended properties. ANYTHING would be better than NOTHING which is what we have now.
-
Adrian Bell (MVP)
commented
I believe this should be relatively easy to update (How many times have posters said that and been completely wrong?) and, though might not be used by a great number of developers, is a fundamentally necessary development towards making the interface fully usable.
-
Mark Burns
commented
Further, the TRANSACTION property data should reflect both whether a transaction is OPEN or not, but also the CURRENT NESTING DEPTH of all OPEN Transactions.