chris fearnley wrote: The procs are working now anyway. Excellent. I have actually thought of another possible solution. It may be possible to have a combined primary key on your tables, the extra field for the primary key would be the based on the serial number you mention above. If this is too much repetition of data (I'm guessing the serial numbers are quite long) you can set up a lookup table that contains all the relevant serial numbers and use its primary key in the main (original) table. For example:
+----+--------------+
| PK | SerialId |
| | SerialNumber |
+----+--------------+
|
|
/|\
+--------+----------------+
| PK, FK | SerialId |
| PK | OriginalId |
| | OriginalField1 |
| | OriginalField2 |
+--------+----------------+
With this schema your stored procedures would only need to add an extra item to the where clause to get the same effect has lots of tables with identical schema. chris fearnley wrote: If your SQL experience covers security issues, and you know what "21CFRpart11" is, I could do with your help on a paid basis Unfortunately my knowledge of Security is about average for a developer (in other words: quite limited), although I am due to go on some courses later this year. However, this doesn't help your current situation. Thanks for the offer anyway.
"You can have everything in life you want if you will just help enough other people get what they want." --Zig Ziglar "On two occasions, I have been asked [by members of Parliament], 'Pray, Mr. Babbage, if you put into the machine wrong figures, will the right answers come out?' I am not able to rightly apprehend the kind of confusion of ideas that could provoke such a question." --Charles Babbage (1791-1871)