Does anyone do SQL Server to Jet4 Merge Replication?
From: Karim Virani (karim_at_XSPAM.compuguru.com)
Date: 01/26/05
- Next message: Pattyt: "Replicating a Secured & Split Database"
- Previous message: Graeme Richardson: "Re: MSDE replication experience"
- Next in thread: Karim Virani: "Re: Does anyone do SQL Server to Jet4 Merge Replication?"
- Reply: Karim Virani: "Re: Does anyone do SQL Server to Jet4 Merge Replication?"
- Messages sorted by: [ date ] [ thread ]
Date: Wed, 26 Jan 2005 14:59:47 -0600
We have a large legacy application built in MS Access (front-end client mdb
with back-end shared data mdb) and are looking for a good migration path
into SQL Server. The problem is we can't fund a large effort and are looking
for a more gradual migration path.
To me the ideal path would require that we be able to use SQL server merge
replication to create a Jet subscriber database that could be used as the
back end. That would buy us the time we need since we could invest enough
resources to upsize the JET database to SQL Server and then update the
client to fix the functionality broken by the structural adjustments
required for upsizing. Then new and replacement web-based functionality
(ASP.NET & DNN) could be programmed directly against the SQL Server
database, while the Access client continues to be used to enter the majority
of data during a 2 or 3 year migration period.
But SQL Server 2000 doesn't support this approach. There is something
missing from the structure of the subscriber Jet4 database and it will not
let the client MDBs link to it. I was wondering if this will be supported in
SQL Server 2005? I haven't been able to find anything about this on the MS
sites.
BTW, I tested the approach of relinking the client database directly to the
upsized sql server, but the poor performance rendered the application
unusable. Most of the forms are directly attached to tables or queries with
many subforms and large rowcounts. It works fine in a Jet front/back
configuration. Also there is so much custom code and Jet-specfic SQL in the
queries, and it's such a large system (in proportion to our resources) that
converting it whole hog to an Access Project just isn't doable.
There was also supposed supposed to be another approach in which you create
a Jet replica mdb and then merge in the other stuff (forms, reports,
queries) from the front-end client. The problem is that you would have to do
this once for each user, and then anytime you had to make changes at the
publisher you would have to repeat this process for each client. Plus it
looked like conflict resolution and jet corruption recovery could become
nightmarish in this situation. It just didn't look manageable, even if I
could figure out a way to automate the front-end merge process.
So it still looks like the ideal solution for us would be to link a regular
MDB front-end application to a single common Jet Replica back-end that SQL
Server monitors and manages for replication with the Publisher. I'd be happy
to know if SQL Server 2005 supports this, or if there are any other
migration paths I might try.
Thanks,
Karim
representing a non-profit painted into a corner
- Next message: Pattyt: "Replicating a Secured & Split Database"
- Previous message: Graeme Richardson: "Re: MSDE replication experience"
- Next in thread: Karim Virani: "Re: Does anyone do SQL Server to Jet4 Merge Replication?"
- Reply: Karim Virani: "Re: Does anyone do SQL Server to Jet4 Merge Replication?"
- Messages sorted by: [ date ] [ thread ]
Relevant Pages
|
