For the record, as I got into it last night, ended up doing exactly what you suggest. Toyed (briefly) with the idea of duplicate employee tables, but my job is to make things easier, not more complicated. Finished it up last night, tested primary functions, and all is well now. Not nearly the huge task I expected (except for an hour lost to troubleshooting a COM object because the old db called the table 'employee' and the new one calls it 'employees' and I was looking for permissions or other errors instead of typos.) Thanks for the tips; helps validate that I'm not heading down the wrong path (yet.) Joel <tip type="database naming conventions"> Establish naming conventions for your databases, and ensure that all databases, fields, tables, stored procedures, etc. conform. It helps with the portability and reusability of code and data, and is a bit of a memory aid; when you know, for instance, that tables are always named in the plural, you don't have to struggle to remember if it was 'employee' or 'employees' and can focus on the task rather than the minutiae. </tip> -----Original Message----- From: thelist-admin at lists.evolt.org [mailto:thelist-admin at lists.evolt.org]On Behalf Of rudy Sent: Saturday, September 01, 2001 12:52 PM To: evolt thelist Subject: Re: [thelist] SQL - Foreign Key Constraint - in another database? > Later, built a 'grand scheme' core db for other ongoing > purposes, which also included employee info. hi joel sounds like a "system of record" concept great idea very au courant in data warehousing > PO app needs to reference the employee table in the > new db now, but foreign keys from two tables point to > the original employee table. you *could* maintain two employee tables, but i would recommend against it > I'm thinking my only solution is to remove said constraints, > move the tables to the new db, then create new constraints. may i suggest a variation 1. incorporate data from the original table into the "grand scheme" one 2. remove constraints 3. create new constraints 4. drop original table rudy --------------------------------------- For unsubscribe and other options, including the Tip Harvester and archive of TheList go to: http://lists.evolt.org Workers of the Web, evolt !