Do Transactions guard against corruption?

[David W. Fenton]

If you still have data in a separate file for a transaction, how
will you handle a transaction inside a transaction:

Begin transactionA
... do something
Begin transactionB
... do something
SELECT * FROM table1

as example?

I don't know. There is a limit to the number of transactions Jet can
nest, so it's not an infinite requirement even if a separate file
was used for each transaction.

But I don't see the need for a separate file. All that's needed is
*one* temp file for everything inside the outer transaction.

Will you have 3 files? one being the mdb, one being for
transactionA and one being for transactionB. Note too that
transactionB is NOT locked out of what transactionA did
modify/delete/append.

One can raise any number of hypothetical questions and speculate on
how MS implemented it. Given that MS has not documented the answer
to this question, I feel no need to speculate on an answer.

I don't see how it matters to the point you're trying to make,
anyway, but then, I'm not sure I've ever understood what your point
*is*.

So, how reading a record will be done: (REMEMBER, we are INSIDE
the transaction, NOT OUTSIDE it, so OUR transaction-locks do not
lock ... OUR transaction, neither our embedded transaction)

Reading by whom? The user running the transaction or other users?
Other users won't see anything at all that's inside the transaction,
because it isn't commited to the shared MDB until the transaction is
complete (including the nested transactions). For the user running
it, the local instance of Jet is in control of the temp file and
knows what its internal structure is, so has full access to all the
data within the transaction.

Look in the mdb, if a record is found, still look in
transactionA file
'tombstone'

I raised the issue of the MSysTombstones table when I thought you
were asking questions about Jet replication. It is relevant only to
replication, not to transactions.

[drivel about "tombstones" deleted, since it's complete nonsense and
has nothing to do with anything]

And that is for a simple:

SELECT * FROM table1

I still have not COMMIT anything. Imagine how simple the "and the
data is merge on commit" can REALLY be 'simple'.

Jet uses the temp file to get the data ready for commiting to the
real data file. I don't see anything problematic about any of this,
as the local instance of Jet in memory can know all it needs to know
about the temp data it has written.

Sure, we can simplify a little bit that hypothetic process of
yours, but it, that is still a process that seems to take at least
MANY times the amount of time than it would without transaction,
even for the most elemental READ: it will be not only much more
expensive to build, to debug and maintain, but also, it would be
totally inefficient.

Well, yes, of *course* it could be done more simply if there were a
transaction log. But that would require a server process to manage
the log and its interactions with the stored data. The whole point
of Jet is that it *isn't* a server database and does *not* have a
centralized process interacting with the data store. Thus, multiuser
access and complex functions like transactions have to be
implemented in ways that use the available tools. And that's not
necessarily simple.

And indexes, and data referential integrity, and ... well, that
has already been exposed and you didn't really supply any concrete
counter-argument than the very weak claim:

"there is not log because I never have read that".

There is no need for a log.

And there cannot *be* a log because of the lack of a centralized
process to manage it.

John L. Viescas said there is an internal (private, not exposed)
log when a transaction is implied. (Obviously, YOU never have read
John's writing).

John has provided no documentation to back up his claim.

Your claim leads to inefficiencies, while the presence of log
makes a lot of sense, in terms of performance and in terms of
development of the database engine.

You seem to have no understanding whatsoever of what Jet is, a
file-based multiuser database engine. You are trying to shoehorn it
into your conception of the server-based database engine (like SQL
Server), but that isn't waht it is.

Yes, indeed, in the absence of 'seeing the code' with their own
eyes, people are reduced to have an idea about how it PROBABLY
works. For me, it is a log, and the transaction data is written IN
THE mdb, where the log main functionality is to be able to UNDO on
ROLLBACK.

You have provided not one iota of documentation to support even one
of your imaginations about how Jet works internally. I've provided
quotations from the official Microsoft documentation of the Jet
database engine (it's sitting right here beside the computer).

Speculation vs. quotations from MS documentation.

Hmm.