re: SC issues/questions ...
I've had too many problems with SC in the past so I stick with command line solutions (eg, RDB/monSysSQLText, RS/trace/dsi). Net result ... I've got no idea why SC is showing you what it does.
------------
re: WHERE clause contents ...
Unless there's a flag/setting to disable the new automatic PK detection capabilities you're left with a) losing your @@rowcount checks or b) making some (potentially) major modifications to your database.
The manuals list a set of conditions under which the new automatic PK detection capability is enabled. The only conditions I see that you could mess with would be the creation of a table-level repdef or removal of all unique indexes from the PDB table.
The first idea would be to create a repdef that lists all columns as the PK; this would force the creation of a WHERE clause with all columns. Obviously you'll need to remember to update the repdef if/when you add/drop columns on the table.
If your application insures con_id is always unique then the loss of the uniqueness on the pk_contacten index may not be a big issue (while a trigger could be used to help enforce uniqueness there's no guarantee that it would work 100% of the time).
If con_id is defined as a 'primary key' constraint then things start to get messy real quick. You could drop the 'primary key' constraint but then you'd need to add trigger code on contacten as well as every child/referencing table; said code would need to perform the necessary RI checks for inserts, updates and deletes.
Obviously the level of messiness grows if you have other tables (besides contacten) that you want to monitor for out-of-sync data.
Another option would be to continue using the new automatic PK detection capability (ie, minimal columns in the WHERE clause) and periodically run rs_subcmp (or DA if you want to buy the licen$e) to check for out-of-sync data. Obviously this has its disadvantages: a) could add an unwanted performance hit if running often and/or against large volumes of data and b) it only provides an after-the-fact image of the change => would most likely be harder to track down the source of the out-of-sync data.
NOTE: Obviously (?) listing all columns in the WHERE clause (especially for tables like contacten with dozens of columns) adds a performance hit for each UPDATE/DELETE that has to be built by the RS/DSI and then parsed (and possibly compiled) by the RDB.
Message was edited by: Mark A. Parsons