Hokay, I'll try that - i hoped that deferrable primary keys would automatically be deferred upon beginning a transaction involving updates to them.. For a single user system, is there any difference beteen deferring and en/disabling?

Do you have any comment on what happens when I say:

UPDATE table SET id = 1 WHERE id = 2
UPDATE table SET id = 2 WHERE id = 1

Could this conceptually make the following problem:
id, data
1, whatever1
2, whatever2

id, data
1, whatever1
1, whatever2

id, data
2, whatever1
2, whatever2

PK Violated..



Nnnnhhhyeah, I got a bit of a problem with having to change the PKs because its part of still setting up the process. I'd love to show you the query that this will be used with. Suffice to say its a management report that has 85 sets of unrelated information on one page. Each item has an ID, a query (unioned with 84 other queries) produces values for that entry for all clients and generates a huge cross-tabbable data set that is then combined with a table holding factors that the summated values must be multiplied by, to work out costings of everything. Not all clients have specific values, so a set of defaults must be used.. THe hardest challenge to overcome so far, was to turna table that has a mixture of generic and client specific values, into a reference list with which to multiply my values by..

CHanging the IDs is necessary at this stage because the structure of the report is shifting and being re-grouped from 5 major groups to around 9 (each groups are totalled with an analytic) so the IDs need to be changed.. Nuisance.

I personally loathe that the database must run an 85-long union query, and each segment isnt light, so I'm trying to combine and prune as much as possible..