<< So the question is... do I now merge both databases into one or keep them separate and use an ODBC connection between "A" and "B". Since "B" now needs data from "A", the original purpose of being separate is now gone.... I.E. If "A" goes down, so will "B". >>
I would merge the two databases. Maintaining them separately means that you'll have to maintain a whole set of code for connecting them and pumping the data. And you'll probably discover new opportunities for integrating the data as well. The only question I would have: once you merge the databases do you actually have to copy the data from table to table, or are you able to use it "in place". If you do keep them separate, I always prefer to interface two databases by having one write a text file to an agreed location and having the other one check for a new text file in that location on a periodic basis. I have always found that ODBC connections are terribly prone to breaking when user IDs change, or you have to replace a machine or server, or something like that. The text file solution relies only on a known folder for saving and reading the text files and is less prone to breakage. Finally, I believe RBTI has a database replication product that synchronizes current data between two databases. That might also do what you need to do. -- Larry
