Date field and replication

Is it true that using date fields in tables being
replicated is not recommended? If true, why?
Thanks
Emma
Emma,
I've never heard this before, and many of my articles have datetime columns.
I do have a few thoughts though...
In snapshot replication I can't see how logically there can be any issues.
In transactional, if there is a default of GetDate() which is often used for
the DateAdded field, as in common with other detfaults, it will not be
transferred to the subscriber so no issue there. Queued updating subscribers
and datetime primary keys could conceivably cause problems, but this is a
relatively obscure situation as the recommendation is not to use datetime
columns for PKs anyway.
The only real issues I can think of are to do with merge replication - if
you are using column-level conflict resolution and you have a "date-changed"
column, you'll get conflicts that you didn't necessarily anticipate. The
other issue you might find is if you are using filters based on date, and
the locale is different on the subscriber and publisher, unexpected records
may be filtered out, and a recent poster was using customided conflict
resolution to solve a similar issue.
If anyone else can add to this list I'd also be interested.
HTH,
Paul Ibison
|||are you sure you are not thinking of the timestamp column. SQL Server 7.0
had problems replicating this data type.
Timestamp columns cannot be published by Publishers running SQL Server 7.0
or to Subscribers running SQL Server 7.0.
"Paul Ibison" <Paul.Ibison@.Pygmalion.Com> wrote in message
news:#f66WgLFEHA.576@.TK2MSFTNGP11.phx.gbl...
> Emma,
> I've never heard this before, and many of my articles have datetime
columns.
> I do have a few thoughts though...
> In snapshot replication I can't see how logically there can be any issues.
> In transactional, if there is a default of GetDate() which is often used
for
> the DateAdded field, as in common with other detfaults, it will not be
> transferred to the subscriber so no issue there. Queued updating
subscribers
> and datetime primary keys could conceivably cause problems, but this is a
> relatively obscure situation as the recommendation is not to use datetime
> columns for PKs anyway.
> The only real issues I can think of are to do with merge replication - if
> you are using column-level conflict resolution and you have a
"date-changed"
> column, you'll get conflicts that you didn't necessarily anticipate. The
> other issue you might find is if you are using filters based on date, and
> the locale is different on the subscriber and publisher, unexpected
records
> may be filtered out, and a recent poster was using customided conflict
> resolution to solve a similar issue.
> If anyone else can add to this list I'd also be interested.
> HTH,
> Paul Ibison
>
|||Thanks all for the response. I am thinking of the date
field. There are some fields in the database set as
VARCHAR and the vendor is refusing to change them to date
claiming that they will not work with replication.
Emma

>--Original Message--
>are you sure you are not thinking of the timestamp
column. SQL Server 7.0
>had problems replicating this data type.
>Timestamp columns cannot be published by Publishers
running SQL Server 7.0
>or to Subscribers running SQL Server 7.0.
>"Paul Ibison" <Paul.Ibison@.Pygmalion.Com> wrote in
message
>news:#f66WgLFEHA.576@.TK2MSFTNGP11.phx.gbl...
have datetime
>columns.
there can be any issues.
which is often used
>for
detfaults, it will not be
Queued updating
>subscribers
problems, but this is a
not to use datetime
merge replication - if
have a
>"date-changed"
necessarily anticipate. The
based on date, and
publisher, unexpected
>records
customided conflict
interested.
>
>.
>
|||the vendor's lying or confused.
"Emma" <eeemore@.hotmail.com> wrote in message
news:1592901c41659$c8659f20$a501280a@.phx.gbl...
> Thanks all for the response. I am thinking of the date
> field. There are some fields in the database set as
> VARCHAR and the vendor is refusing to change them to date
> claiming that they will not work with replication.
> Emma
>
> column. SQL Server 7.0
> running SQL Server 7.0
> message
> have datetime
> there can be any issues.
> which is often used
> detfaults, it will not be
> Queued updating
> problems, but this is a
> not to use datetime
> merge replication - if
> have a
> necessarily anticipate. The
> based on date, and
> publisher, unexpected
> customided conflict
> interested.