default values

Hi All,
I'm trying to implement a merge replication of our database, every thing seems to be just fine to this moment except that at the subscriber fields with default values have lost those values probably during the snapshot intialization process. I want to k
now if it is possible to prevent this type of behaviour. Thanks for your help.
Defaults on tables on the publisher will be replicated to the Subscriber.
If you have different defaults on the Subscriber that you wish to be
preserved you have to, right click on your publication, select publication
properties, click on the articles, tab, click on the browse button (the
three ellipses to the left of your table), and select the snapshot tab. In
the name conflicts select the Keep existing table intact option.
Regenerate your snapshot and restart your merge agent to correct your
problem.
Hilary Cotter
Looking for a book on SQL Server replication?
http://www.nwsu.com/0974973602.html
"Oussama Albairat" <Oussama Albairat@.discussions.microsoft.com> wrote in
message news:174B6D16-9FC0-4D4A-80EE-3C5C85599359@.microsoft.com...
> Hi All,
> I'm trying to implement a merge replication of our database, every thing
seems to be just fine to this moment except that at the subscriber fields
with default values have lost those values probably during the snapshot
intialization process. I want to know if it is possible to prevent this type
of behaviour. Thanks for your help.
|||What do you mean by "lost those values"? The data no longer exists in the row(s)? Or the Default constraint is no longer applied?
If the latter, ensure that you include constraints in your article publication. If the former, you'll need to find WHY the data is not being propogated (perhaps a 'NOT FOR REPLICATION' explicit declaration in the table definition? etc.)
X
"Oussama Albairat" wrote:

> Hi All,
> I'm trying to implement a merge replication of our database, every thing seems to be just fine to this moment except that at the subscriber fields with default values have lost those values probably during the snapshot intialization process. I want to
know if it is possible to prevent this type of behaviour. Thanks for your help.
|||Thanks Guys for answering so promptly,
Like Hilary said Defaults are replicated to subscriber, that's what I noticed in my case too.
But, user defined defaults are ignored by the replication process.
So these defaults end up being removed from the final schema,
after running snapshot initialization for the subscriber. And I still don't know why.
Do I have to reset all fields defaults manually at the subscriber? (which is not the best deployment strategy)
if you have any better idea to recover the defaults as well, please share it.
Thanks again.
"Hilary Cotter" wrote:

> Defaults on tables on the publisher will be replicated to the Subscriber.
> If you have different defaults on the Subscriber that you wish to be
> preserved you have to, right click on your publication, select publication
> properties, click on the articles, tab, click on the browse button (the
> three ellipses to the left of your table), and select the snapshot tab. In
> the name conflicts select the Keep existing table intact option.
> Regenerate your snapshot and restart your merge agent to correct your
> problem.
> --
> Hilary Cotter
> Looking for a book on SQL Server replication?
> http://www.nwsu.com/0974973602.html
>
> "Oussama Albairat" <Oussama Albairat@.discussions.microsoft.com> wrote in
> message news:174B6D16-9FC0-4D4A-80EE-3C5C85599359@.microsoft.com...
> seems to be just fine to this moment except that at the subscriber fields
> with default values have lost those values probably during the snapshot
> intialization process. I want to know if it is possible to prevent this type
> of behaviour. Thanks for your help.
>
>
|||In merge replication AFAIK it isn't possible to not replicate the defaults
constraints so perhaps you are referring to default objects? If so, you
could redefine them as default constraints, or you could use a script to be
run after the snapshot ('postscript').
TIA,
Paul Ibison
|||Hi All,
What I noticed in merge replication is when using a user defined data type system converts it back to native SQL data type during replication. so fields at subscriber are no longer of the same type as in publisher. eg. if you define a data type Boolean
as bit and your field named "IsOk" is Boolean at Publisher. After replication IsOk becomes bit at subscriber. now if Boolean is bound to a default value "False" at publisher, after replication field IsOk will not be attached to default constraint at subs
criber because it's data type has changed to bit. And that's what made my default constraints to disappear.
Thanks.
|||Oussama,
on the article properties have a look at the snapshot tab. By default it is
set to convert user-defined datatypes to base types (check-box at the
bottom) which is why you lose your bound default. In your case if this is
unchecked there will be an initialization error produced from the merge
agent unless the user-defined datatype preexists on the subscriber. You
could create it and bind the default to it in a script to be run before the
snapshot is applied (snapshot tab of the publication properties), then it
should all work ok.
HTH,
Paul Ibison
|||Paul,
Thanks for your advise. I unchecked that check-box, and after
initialization defaults are recovered as well. Thanks so much.
"Paul Ibison" wrote:

> Oussama,
> on the article properties have a look at the snapshot tab. By default it is
> set to convert user-defined datatypes to base types (check-box at the
> bottom) which is why you lose your bound default. In your case if this is
> unchecked there will be an initialization error produced from the merge
> agent unless the user-defined datatype preexists on the subscriber. You
> could create it and bind the default to it in a script to be run before the
> snapshot is applied (snapshot tab of the publication properties), then it
> should all work ok.
> HTH,
> Paul Ibison
>
>