Has anyone seen something like this before.

I have a distributed EXE out there. Call it Version 1. I needed to issue a "Service Release" to fix some bugs and so wrote some code that launches the first time and only the first they RUN the new EXE (call it Version 2). So far, so good.

In the upgrade installation, I redistribute the DBC because I've made minor table changes. I also needed to add an index tag to one of the user's tables -- one that might already have data in it -- and so rather than write maintenance code to move the data from the old table to the new one, the one that has the new index, I build the index on the fly when the one-time maintenance code runs.

I gain exclusive use of the table then issue INDEX ON somenew_id TAG somenew_id ADDITIVE. Seems innocent enough.

Then, weirdness sets in.

What's supposed to happen when a user tries to create student data is that it looks to see if the Student's ID already exists. If it does, it's supposed to issue a duplicate record message of some sort and prevent duplicatres from being added. But what happens is that the system acts like there isn't a duplicate and permits creation of the duplicate record. Thereafter, the system always reference the duplicate ID that got added erroneously and acts like the first one never existed. Oddly, the id I'm looking up isn't even the one that got created on the fly. For all intents and purposes, the system acts as though the existing records never existed and duplicates all of them ... once.

Is there something wrong with creating indexes on the fly like this? I've checked and rechecked the values in the records, traced it through as best I can but can not come up with a logical explanation for it. Ive tried VALIDATE DATABASE and Pack and Reindexing this table but no luck.

Any clues?