Replication questions, using VB

Hi all,
I?ve just got a vb (6) application with source-code from a customer and
was asked to 'fine-tune' and enhance the thing. Oh well, you got to
make a living, don't you...
Anyway. The application uses SQL Server to store data. One SQL Server
(msde) is installed on their server (let's call this one master) and a
user has a desktop and a laptop on his desk.
On the server, a publication has been created. Merge replication,
continuously. The publication is set to expire after 60 days.
The desktop connects to the master. He doesn't have SQL installed.
The laptop also has Sql Sever installed (msde again). The VB app pulled
a subscription to a local database. The user does the daily work in
that local database and all changes are merged automatically. When the
user goes away from the office, he can make changes and the other
office users can make changes and all is merged happily when he returns
and plugs into the network again.
No rocket science here :-)
I do have a few questions about some things that aren't very clear to
me... I've already started to read some BOL, some VB samples, MSDN and
some other stuff about VB and SQL and replication but maybe someone has
a few tips and tricks or watch-outs on the following questions:
- When the laptop user synchronises on a day to day basis (like in the
above scenario), does the subscription ever reach the 'expired' state?
From what I've read, I assume it doesn't (since it is synchronised
almost every day).
- Is the subscription also updated to start counting again from the
last synch?
- Is there a way to find out (using VB6) when the last synchronisation
occurred? The application currently sets a date/time value in an INI
file when the user selects "pull subscription" in the application and
then warns the user that he needs to synchronise. The
warning-calculation is based on the initial subscription date and not
taking any synchronisations in account; explaining the question.
- When the subscription expires, I presume you can delete the local
database and pull a new one, but what when a user messes his local DB
beyond the limit. Can you make your local DB 'invalid'? I mean, I want
to connect to the network to pull a new subscription but as soon as I
connect it will start to merge this messed up data; how can I prevent
that?
Any comments appreciated,
Ferry
Your eyes are weary from staring at the CRT. You feel sleepy. Notice
how restful it is to watch the cursor blink. Close your eyes. The
opinions stated above are yours. When I snap my fingers, you cannot
imagine why you ever felt otherwise. <snap>
1) I won't expire unless the subscriber is offline for more than 60 days or
whatever your history retention period is (by default 2 days). So it
probably will expire if offline more than 2 days.
2) The subscription is generated every time the subscriber expires if you
have a named subscription or every time the snapshot agent runs if you have
an anonymous subscription.
3) if you are using the ActiveX control have a look at the status event. You
will have to trap this event for the sync complete message (IIRC), and then
set the time and date in the ini file.
4) When a merge agent runs, the merge agents merely syncs the changes that
occurred on the publisher and subscriber since the last merge agent ran. If
the user hoses his database you will probably want to do a full sync or a
reinitialization. If the user corrupts his database you would probably want
to drop the database and then recreate it and do a new sync.
The best way to check for corruption is by running a checkalloc. This will
detail system table corruption. The you would probably have to count objects
and do comparisons to determine what has been changed.
Tot zeins
Hilary Cotter
Looking for a SQL Server replication book?
http://www.nwsu.com/0974973602.html
"Ferry" <ferryswi A@.T ferryswi D.O.T tmfweb D.O.T nl> wrote in message
news:mn.bd4c7d4cd875149f.23024@.TferryswiD.O.Ttmfwe bD.O.Tnl...
> Hi all,
> I?ve just got a vb (6) application with source-code from a customer and
> was asked to 'fine-tune' and enhance the thing. Oh well, you got to make a
> living, don't you...
> Anyway. The application uses SQL Server to store data. One SQL Server
> (msde) is installed on their server (let's call this one master) and a
> user has a desktop and a laptop on his desk.
> On the server, a publication has been created. Merge replication,
> continuously. The publication is set to expire after 60 days.
> The desktop connects to the master. He doesn't have SQL installed.
> The laptop also has Sql Sever installed (msde again). The VB app pulled a
> subscription to a local database. The user does the daily work in that
> local database and all changes are merged automatically. When the user
> goes away from the office, he can make changes and the other office users
> can make changes and all is merged happily when he returns and plugs into
> the network again.
> No rocket science here :-)
> I do have a few questions about some things that aren't very clear to
> me... I've already started to read some BOL, some VB samples, MSDN and
> some other stuff about VB and SQL and replication but maybe someone has a
> few tips and tricks or watch-outs on the following questions:
> - When the laptop user synchronises on a day to day basis (like in the
> above scenario), does the subscription ever reach the 'expired' state?
> From what I've read, I assume it doesn't (since it is synchronised almost
> every day).
> - Is the subscription also updated to start counting again from the last
> synch?
> - Is there a way to find out (using VB6) when the last synchronisation
> occurred? The application currently sets a date/time value in an INI file
> when the user selects "pull subscription" in the application and then
> warns the user that he needs to synchronise. The warning-calculation is
> based on the initial subscription date and not taking any synchronisations
> in account; explaining the question.
> - When the subscription expires, I presume you can delete the local
> database and pull a new one, but what when a user messes his local DB
> beyond the limit. Can you make your local DB 'invalid'? I mean, I want to
> connect to the network to pull a new subscription but as soon as I connect
> it will start to merge this messed up data; how can I prevent that?
>
> Any comments appreciated,
> Ferry
> --
> Your eyes are weary from staring at the CRT. You feel sleepy. Notice how
> restful it is to watch the cursor blink. Close your eyes. The opinions
> stated above are yours. When I snap my fingers, you cannot imagine why you
> ever felt otherwise. <snap>
>
|||Na rijp beraad schreef Hilary Cotter :
> 1) I won't expire unless the subscriber is offline for more than 60 days or
> whatever your history retention period is (by default 2 days). So it
> probably will expire if offline more than 2 days.
> 2) The subscription is generated every time the subscriber expires if you
> have a named subscription or every time the snapshot agent runs if you have
> an anonymous subscription.
> 3) if you are using the ActiveX control have a look at the status event. You
> will have to trap this event for the sync complete message (IIRC), and then
> set the time and date in the ini file.
> 4) When a merge agent runs, the merge agents merely syncs the changes that
> occurred on the publisher and subscriber since the last merge agent ran. If
> the user hoses his database you will probably want to do a full sync or a
> reinitialization. If the user corrupts his database you would probably want
> to drop the database and then recreate it and do a new sync.
> The best way to check for corruption is by running a checkalloc. This will
> detail system table corruption. The you would probably have to count objects
> and do comparisons to determine what has been changed.
> Tot zeins
>
> --
> Hilary Cotter
> Looking for a SQL Server replication book?
> http://www.nwsu.com/0974973602.html
> "Ferry" <ferryswi A@.T ferryswi D.O.T tmfweb D.O.T nl> wrote in message
> news:mn.bd4c7d4cd875149f.23024@.TferryswiD.O.Ttmfwe bD.O.Tnl...
<snap>
Thanks Hilary for the comments. I'll start looking into the details.
Have a nice Christmas,
Ferry
Your eyes are weary from staring at the CRT. You feel sleepy. Notice
how restful it is to watch the cursor blink. Close your eyes. The
opinions stated above are yours. When I snap my fingers, you cannot
imagine why you ever felt otherwise. <snap>
sql