Hi All,
We have an application requirement for a database supporting field service engineers, which calls for a central SQL Server databse, and laptops with the same database replicated onto SQL Express. I'm resposible for designing the database for this, physical and logical. I've designed and built many a database, but never had to use replication before.
I've read through BOL, and understand how the merge replication process works, and I have no problem designing the database assuming it were to run on a single server.
What I am trying to find are whitepapers, or equivalent, on "best design and implementation practice", and especialy common mistakes to avoid.
I know that the windows programmers responsible for the UI will not completely abstract the database from the code (no matter how desirable that is or how often I tell them!), and I really don't want to find I have to change the physical tables or replication logic after they've coded most of the UI .
Many thanks in advance
Richard R
I would say depending on the features you plan to use, Books Online s your best friend.
Let us know if that doesnt help you much and also let us know what specific feature areas you are looking at.
|||Hi,
BOL is pretty good at describing the process, but doesn't list any caveats. It may of course be that there aren't any - but that would be unusual!
The main question I supppose is, can I just get on and design the system as if it were stand-alone, then build the replication parts afterwards?
I expect I will need some custom logic for reconcilliation, as there has to be a log for tracking part movements, and it is likely that users will synchronise their laptops in a different order to them physically moving the parts, thus generating gaps in the log that need to be filled, as well as there local copy of the data not reflecting the physical reality when they come to move parts.
Is there a best practice for doing this sort of thing without bothering the users?
Thanks for your help,
Richard
No comments:
Post a Comment