Re: General sync issues between different systems?

Hi Tony! I'm not sure if this is going to answer your question directly, however, try posting your question on the comp.databases.ms-access newsgroup. Michael Kaplan is the creator of the TSI Synchronizer and may be able to help you with some of your issues. Or, try going to the Microsoft newsgroup for replication. Hope this can point you in a useful direction. Good luck!

Regards, G.
D. Karma <d_karma_at_my-dejanews.com> wrote in message news:395981b2.46161134_at_netnews.netreach.net...
> Hello,
>
> I have some work coming up that's going to consist of keeping two
> different database systems in sync. One system is on an MSSQL7
> server, while the other is a mainframe system. The MSSQL database
> actually comes from an existing Contact Management software system.
> The type of data, initially, will be Contact information, but will
> expand to include calendar and historical event data. The Contact
> Management software already has its own type of synchronization log,
> because they do a disconnected laptop setup.
>
> Users will be able to modify data on both sides. Each system has its
> own type of unique identifier for contacts. Updates are going to be
> done by creating ASCII text files; on the SQL side they'll be coming
> and going via DTS. Updates are expected to be daily, but I don't
> think that's guaranteed. There's a few more quirky things on the SQL
> Server side due to the design of the contact management software. The
> table structures on either side are roughly equivalent -- but
> certainly not equal.
>
> Anyway, we've been hashing this out a bit, and once or twice some
> previously unseen issues have cropped up.
>
> I'm wondering if there might be any general references that I might
> find that deal with this sort of thing? Conceptually, it looks to be
> the most like the Merge Replication that MSSQL7 uses. But the
> replication tools don't seem viable, well, because we're not using SQL
> Server on one of the ends. Also, on the SQL Server side... we don't
> have the freedom to change the table structure of existing tables [a
> windows app uses them heavily; we don't have the authority to touch
> them] but we can add parallel tables if needed.
>
> Mostly, I'm worried that there might be some key issue that will get
> overlooked until well after the design process. The SQL Server
> documentation is less than ideal for this, since it assumes the
> existence of its own Agents, and therefore doesn't bother with some
> underlying concepts of what the agents do.
>
> Any suggestions? Good reading material? Commonly overlooked issues?
>
> Thanks for your time,
>
> Tony G.
Received on Sun Jul 09 2000 - 00:00:00 CEST