Current set up is across 2 sites within the same practice
PC1 / INR.MDB(1)
PC2 / INR.MDB(2)

Our problem was that sometimes patients from site 1, come to site 2 and vice versa and their data is not available.

The aim was to create multiple PCs across both sites and integrate both MDBs but I've read other posts here on the support forum that integration of the MDBs is not possible.

It be easy enough to create two shared network directories with MDBs in them (as you cannot rename the MDBs) and swap over as necessary so even if a patient from site 1 turns up at site 2, then all you have to do is swab databases? Or would it be possible to create two desktop shortcuts each pointing to a different MDB, or would that require two installations on each PC?

Dear Sharif,
The ideal option is to manually enter data from one INR.MDb across to the other.
Then just have the one INR.MDB database accessible across the network on a shared folder.

The other best option is the second you describe, though I have not come across it before. You will see that the RAT installation is in the folder:
'C:\Program files\Rat version 3'
Rather than do a second installation, you could make a copy of the Rat version 3 folder in the 'Program files' folder and call it e.g. 'Rat 2'
Then make 2 shortcuts on your desktop, one for each RAT folder, obviously calling them different names and have each one pointing to a different INR.MDB file.
The latest update of RAT has the path across the top title bar of the main screen. So you would see at a glance which database you are accessing.

It is a bit messy but will work OK. You will not be able to have both RAT instances running at the same time on a PC.

Regards
Colm Rafferty

The second option is messy, but will save the legwork of transcribing data across. The other problem with the legwork is taking both systems offline whilst performing the data entry.

I am not familiar with the MDB file structure, but will ask one of the other partners who is more averse how to minimise time taken to take up your former option, which, in programming terms, would be much simpler.

Obviously, the longer we leave merging the databases, the longer it will take if and when we do.

Many thanks,
Sharif