I like with both Renee and Chayce's suggestions, but one caveat with Renee's is you'd need to figure out how to make the new key field (your imported values) be unique for future records (e.g. auto-increment). I typically try to avoid changing the default key.
The other option that comes to mind is make a foreign key like Renee suggested, but not change that to the primary key field. Then, you could create a relationship to the old table using that key to reference old values.
I'd suggest Chayce's approach though assuming you haven't burned IDs in the new table by deleting test records, etc. That also potentially allows you to remove the old table and it's one less thing to manage.
The underlying issue here is we are not able to change Quickbase's default primary key values and the next auto-incrementing value like you can with a SQL table.
Ooh, and regarding your error … there's a different between importing and creating new records vs. importing and updating existing records. Or an "upsert" which is combination of both. It sounds like in your import you are trying to use a "merge field" to update records that don't exist. I'd make a test a table to play around with the import process and options that you can throw away once you're finished. In the import process, you'll set of merge field of say "Record ID#" … but, then in the subsequent step where you map fields, select "Do Not Import" to this field and that should create the new records for you using the new tables auto-generated IDs. Then, I'd try what Chayce suggested!
------------------------------
Brian Seymour
------------------------------