Wrong key. Like... wrong size?
Well, here's the overview. I've broken it down into very simple steps so you can be clear on what is happening when.
# 1 (never to be skipped when doing something like this): Make a good copy of your database. Backup to tape or CD or another hard drive or do an outright copy or do SOMETHING so that you have two files that are just alike. You will keep that copy for the occasional "whoops" that all of us have sometimes. It is your safety net. Treat it like gold.
#2 - In the same DB, create a new table that looks JUST LIKE the main table - with one more field that is an autonumber but not the PK.
#3 - Create a new table that looks like the related table but with one more field that is a long integer. No relationships - yet.
#4 - Now write an append query to load up records from the original main table to the new table. Copy field for field. But remember you added one more field, an autonumber. Let it do its thing, number-wise. When you have appended all of the records, the autonumber will be ripe for use. But... leave the original key as still a key.
#5 - Now build a temporary relationship between the new main table and the old related table BUT still using the old keys.
#6 - Write a JOIN query that updates the new field in the related table from the new field in the main table. You are still joining on the old key but building a secondary set of pointers from the related table to the appropriate record in the main table.
#7 - You're nearly there... Now delete that relationship between the new main table and the old related table. (Told you it was temporary!)
#8 - Now remove all keys from the main table and any key involving the old key field from the related table. (Dont' remove the fields - just make them no logner act as keys.) If you had relational integrity turned on, you must turn it off now.
#9 - Now select the NEW field (that is autonumbered) on the main table as your new prime key.
#10 - Define a relationship between the new (autonumber) PK and the new related table's new long integer field.
#11 - Last step: Spot-check that everything works.
#12 - If so: Delete the (now obsolete) former PK/FK fields from the new tables. And delete the old tables entirely.
#13 - If no: that's why you made a backup copy. Start over again.