Dick:
Is it at all possible that, at the time these order detail rows are
printed, they're actually stored within a temporary order detail table;
and that by virtue of a (seemingly) random "glitch", they're not getting
written to a permanent order detail table at the appropriate moment?
Dick
Have you re-loaded/packed the database recently. I would suggest pack keys
for the table in question. It could be the index is corrupt and the row is not
really deleted.
If the row is actually deleted I would suggest putting an On Before DELETE
trigger on the table. This way you
Do they have access to the data at the table level? If not, then you can use
the table setting to not allow deletes.
You can do table level permissions as well.
I do not give users table level access. They only have the compiled app so I
can control/log what we need.
Dan Goldberg
Dick,
Does this issue surface later in the work day or the following day? Has the
program worked perfectly daily up to some recent point when the issue surfaced?
If so, what might have changed recently? Server, users, program? Perhaps
this might help lead you towards a solution. If this
If you are using SQL Grant/Revoke, you can deny delete on any table for all but
the owner.
If not, you can certainly add it to your system. Razzak’s ate web site has a
comprehensive article on the use of Grant/Revoke to prevent troubles with your
data.
Albert
> On Feb 8, 2018, at 10:15 AM,
Help...
We are having a problem with occasional rows just disappearing from a
table. We know they were there in the beginning,
because we print an order when entered.
Sometimes coming back to the order later, 1 or more detail rows are
missing. I have no idea how that can happen.
The
6 matches
Mail list logo
