Bernhard Weisshuhn wrote:
Don Y wrote:
[snip]
For example, the title may match an existing entry -- but
the author may be different (e.g., misspelled, or some
"other" author listed on a book having multiple authors, etc.).
Ideally, I would like the database to suspend the INSERT,
ask for confirmation (and "why") and then, either commit
the INSERT or abort it (based on the user's response).
Nearest I can imagine, there's only one ways I can do this:
issue a query that looks for these types of problems and
based on the result, let the *application* prompt the
user for confirmation. Then, *if* confirmed, do the real
INSERT.
You could *insert* the data and then *rollback* the transaction. Then
you would *know* the data is *valid*.
Only if the user *confirms* the action, then you do it *again* and
actually *commit* the transaction.
Ah, OK. More elegant. But, it still moves responsibility for this
to the application layer, not the database, itself. I can't see
any way of avoiding this :-(
OTOH, an API with like insert_data(...., bool confirm) would
remind the application developers that the intended interface
is:
switch (insert_data(..., FALSE)) {
case INVALID:
/* something wonky in the data, abort */
break;
case QUESTIONABLE:
/* possible typographical error, require confirmation */
if (confirmed)
insert_data(..,TRUE);
break;
case LOOKS_GOOD:
insert_data(..., TRUE);
}
P.S. these* *stars* are *unnerving* ;-)
<frown> Sorry, i've been writing specifications for the past
few days and use the "emphasis" SGML tag quite a bit :-/
(the idea of posting in HTML is just anathema...)
--don
