> >I still have no idea how someone (expecially one of our
> customers ;)) would
> >be able to duplicate this scenario, even in a DB admin tool.
>
> Too, too easy. In any query interface:
>
> Alter table mbusercompany drop constraint integ_799 and commit.
>
> Mess around with data and commit it.
>
> Alter table mbusercompany add constraint primary
> key(usercompanykey) and
> commit.

All of our batch inserts are done without altering any of the metadata of
the database.

I don't see how you can re-create the PK on the table when there is data in
there that violates the PK. I tried the process you suggested and got the
message "attempt to store duplicate values (visible to active transactions)
in unique index "AA"". Now I have a table with multiple duplicate PK's but
with no PK constraint on them.

> In fact, depending on the tool they were playing about with,
> they could
> have done all of that through a GUI.
>
> >Are you able to reproduce this? If so, I would love to know how.
>
> I'm pleased to say that, with the constraint in place,
> neither isql nor
> IB_SQL allows me to add key values where the only variation
> is the number
> of blanks appended to the second group of digits. That's
> good, because it
> gives at least reasonable protection from ill-conceived key strings.
>
> However, your table on my hard disk now has five records with
> the primary
> key ''327 11030 '. As it happens, I used isql to drop the
> constraint, do the damage, and recreate the constraint, logged in as
> sysdba. I could not have done that if I had logged in as
> non-sysba or the
> non-owner of the table. Find out who at the customer site
> knows the sysdba
> (or owner) logins and you'll be closer to discovering who has
> been meddling.

Can you please email me this database? I would like to have a look at it.

> If it were my software, I would be very keen to fix up keys
> so that they
> are atomic and so that, if someone is going to poke around,
> the worst thing
> that could happen is that they create a NEW key that points
> to duplicate
> data. Of course, as long as the metadata is available to
> meddlers and
> dabblers, there's not a lot you can do to prevent them from dropping
> constraints....
>
> ./heLen
>

Cheers,

Ryan.

>
>
> ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
>
> Visit http://firebird.sourceforge.net and click the Resources item
> on the main (top) menu. Try Knowledgebase and FAQ links !
>
> Also search the knowledgebases at http://www.ibphoenix.com
>
> ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
>
> Yahoo! Groups Links
>
>
>
>
>
>
>