Thanks for the input. The data is used "in place". I do not copy data
from A to B, B actually uses (reads and inserts data into a table in
A). RSync is not really applicable here as the data (table) in
question only resides in one DB.... Database A
I am leaning towards merging then into one.
Thanks again
Bob Thompson
LaPorte, IN
219-363-7441
Sent from my iPod
On Aug 9, 2010, at 9:12 AM, Lawrence Lustig <[email protected]>
wrote:
<<
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
