Re: Do Transactions guard against corruption?

Tech-Archive recommends: Repair Windows Errors & Optimize Windows Performance

"Michel Walsh" <vanderghast@VirusAreFunnierThanSpam> wrote in
news:O3JwX9T$IHA.5048@xxxxxxxxxxxxxxxxxxxx:

Well, you choose to not understand what fits your need. When you
modified two somehow disconnected databases and need to merge them
into one (on commit), that is called replication. Or that is news
to you?

No, it's not news to me at all. But Jet replication does not use
logs either (and this is an area in which I have a great deal of
expertise, in fact).

How your 'mechanic' propagates the deleted records from a
transaction with the mechanic you describe?

In replication or a multi-user database? In Jet Replication, the
MSysTombstones table is used.

How it handles the autonumbers of a table on
commit (other users CAN append records to the same table, isn't
it, they are not locked out as soon as the transaction also append
a record to the table)?

In replicated databases, all Autonumbers are converted to random. In
over 10 years of creating replicated applications for my clients,
I've never once encountered a duplicate Autonumber between replicas.
If you have enough inserts and enough replicas where that's a
problem, there are a number of solutions to the problem to insure
uniquess of PKs in each replica.

But none of them involves a transaction log, which doens't exist in
Jet.

How it handles simple read (and indexes) when embedded
transactions occur, from *within* the embedded (not yet committed)
transactions?

I already explained that in another post -- it uses the LDB file to
keep track of who has what locked.

You see,
it is not important that you come with an answer as much as your
answer does not involve another extra mechanic for case one, and
another special dedicated mechanic for case two, etc. All those
mechanics would have to be coded while the log mechanic...

I don't have a clue what you're talking about. I've explained how
Jet works in all cases. You may not like the explanation, but it is,
in fact, the way the documentation for Jet says it works (in regard
to replication, I know it from experience as much from reading about
it).

implies no extra specific database mechanic
that the database itself already deliver: lock, set, append,
delete. The SELECT * FROM table does not need any special
consideration if your are within a transaction, or not, with a log
file, but needs very special ones with the mechanic you described,
when executed within a transaction.

No, it needs nothing more than a temp work file and locking on the
real data file that is honored by all the users operating on that
data file. This is, of course, accomplished via the LDB file.

Your basic claim is that since YOU never read anything about Jet
having log, so NECESSARY Jet has no log.

All the documentation I've ever read about Jet that compares it to a
server database makes a point of the lack of logging in Jet being
one of the crucial differences.

That is a very weak argument, and depend on our
predisposition to believe you read the appropriate stuff. Have you
even read anything about CHECK(), or BAND in the Jet db engine
programmer's handbook? No, so, there are just illusion whenever I
could eventually use them?

There is one reference to CHECK() in the Jet 3.5 programmer's guide
(MS never published a guide for Jet 4 or later), and it is on p. 75
and says:

Microsoft Jet SQL doesn't support ANSI SQL constructs that set
validation rules or default values (for example, field-level
CHECK or DEFAULT clauses).

It may be that Jet 4 changes that (as a lot of things were
introduced into Jet 4 that make it somewhat more consistent with
server database engines).

There is no reference for BAND in the index, so I would assume it's
not supported in Jet 3.5.

Now, you could argue that everything changed in Jet 4, but that's
ludicrous -- certain things were added to an already-robust database
engine that had been under development for nearly 10 years, but the
basic operation of the engine was not changed.

Since I have the book out, here are some relevant quotations:

USING TRANSACTIONS IN THE MULTIUSER ENVIRONMENT

You can use Microsoft Jet transactions to group updates in units
that can be committed or rolled back as a whole. Because
transactions save updates in a temporary file instead of in real
tables, they also have useful effects in multiuser environments.
(p. 258)

Have you ever read in the same book that the mechanic you
described is what happen with transaction? so, your logic is still
applicable: YOU have not read it, so SURELY it does not exist?

I don't have a clue what you're talking about when you impute to me
the invention of "a mechanic." I have explained how Jet works, and
it does not involve a transaction log.

I have not read it, me neither, in any official documentation, and
while any piece of knowledge has always a tag of 'degree of
certitude' associated to that piece of knowledge, it just happen
that John L. Viescas has a much better credibility tag than the
one of your claim has, and, as extra, (transaction) log makes much
more common sense, strategically and economically to develop, in
the business of writing a database engine, which Microsoft also
has a tag of expertise.

But they didn't do it. There is no transaction log at any level in
Jet. Period. If there *were* such a thing, the Jet documentation
would give a clue as to how to use it (what purpose would it serve
if it couldn't be used for the same purposes as it is used in server
databases?). But there isn't any such documentation, because IT
DOESN'T EXIST.

You are the one who has the obligation here to affirmatively
demonstrate that this phantom Jet transaction log exists. Find some
MS documentation that shows that it exists. Otherwise, you're just
blowing smoke.

I cannot prove it doesn't exist (it's logically impossible to prove
a negative), but you can logically prove that it *does*. Yet, you
won't be able to, because it does *not* exist in Jet.

It may seem to *you* like the only way Jet should have been
designed, but it is not the way Jet *was* designed (way back in the
early 90s).

--
David W. Fenton http://www.dfenton.com/
usenet at dfenton dot com http://www.dfenton.com/DFA/
.

Relevant Pages

  • Re: Distributed transactions, replication, views
    ... If you have significant processors on your server you can partition the ... The way replication works is that if a transaction is committed on the ... Looking for a SQL Server replication book? ... I have been tasked with restructuring a database. ...
    (microsoft.public.sqlserver.replication)
  • Re: transactional replication problem
    ... All transaction from killed process were rolled back... ... Did they get deleted from distribution database ... >Looking for a SQL Server replication book? ...
    (microsoft.public.sqlserver.replication)
  • Re: Cant drop column
    ... dbcc checkdb returned no error. ... Replicated Transaction Information: ... >It is unlikely your database is corrupt. ... >> replication database. ...
    (microsoft.public.sqlserver.replication)
  • Re: Transaction log way too large - no transactional replication involved!
    ... the corresponding database has about 200 Mb). ... snapshot and merge replication, definitely *no transactional replication*. ... The common way with DBCC Shrinkfile, DBCC Loginfo, backup log and the like ... My aim/wish is to get this pending transaction going so the log can shrink ...
    (microsoft.public.sqlserver.replication)
  • Re: MSRepl_Commands question
    ... make all database changes to the ... publisher and the subscriber and then reinitialize replication. ... We considered checking the status of the distribution agent but realized ... by checking their transaction number against this value. ...
    (microsoft.public.sqlserver.replication)