This is a SQL Server tool. Is it possible to use it with Jet data?

If the databases are stored in SQL Server, why would the original
poster ask the question in this newsgroup?

And the point of the question was having two *non*-replicated
databases, so even if the data *were* stored in SQL Server, you
couldn't magically turn on replication on the two databases and have
them reconcile with each other.

Assuming this is a one-time task, it's really not all that hard to
reconcile the databases, but it depends on your data structure.

If, for instance, you're using AutoNumbers as your surrogate PK, and
records storing different data in the two databases have been
assigned the same PK, then you'll need to figure out how, using the
other data fields, you can match up records that happen to be the
same from both.

Or, you could just import all the records from the one into the
other, then de-dupe from there.

If you know the data is has been assigned the same PKs in both, but
the records have different data, then it's quite easy. This could
very easily be the case if a copy database A was given to someone to
work on. You would then know that up to a certain point, the records
in database B are going to be duplicates of the records in database
A, and then you can easily run an update query on those records to
pull data changes into database A from B, then append the records
from B that were created after the data forked.

Now, of course, if you've got a hierarchical data structure, you'll
need to do all of this in an order that preserves referential
integrity, and you'll need some method of tracking the old PKs from
database B to connect the B child records to their new parents in
database A. The easiest way to do that is to add an OLD_PK field for
the table with the parent records in database A, and when you append
the B records you'll now be able to connect back to the original
records, and through a simple join, import the B child records and
assign them the new parent PK.

Sounds complicated, but it's really not all that bad.

But it all depends on how the data is structured and what kind of
fork there was between the two databases.

It's also helpful if the records have time/datestamps to show when
the data was changed and/or fields that record who created the
record (you can add this latter before the import/update). When
those aren't in the data, then you really do have to do brute-force
exact matching, and then hope you have no false exact matches (e.g.,
if there are two people with the same name in both, but they really
aren't the same person), and then there's often a lot of manual work
that needs to be done to resolve all the loose matches.

A few years ago I was tasked with importing 250K people into an
existing database that had over 100K of its own records. We knew
that the 250K-record dataset was less reliable than the 100K
dataset, so we had to be very cautious. It took weeks of work,
massaging data by various methods (using multiple Soundex variants,
processing address fields into standard formats, fixing phone
numbers, etc.).

On the other hand, if you want ongoing data synchronization between
two databases, it's really much, much easier to use Jet replication
than it is to write your own, especially when there will be updates
and additions in both databases. It's not too hard to do, though,
when one of the databases is a master and the other a slave. I've
done this several times for clients who have websites where
customers can make edits, but they want to process the data locally
in Access (with some kinds of data being updated only in the Access
database).

But the master/slave scenario is the easy case. For two-way data
updates with Access, Jet replication is by far the easiest way to
go.

I still don't see what relevance talk about SQL Server has here,
though.