Replication

[KH]

Is there a way you can replicate a table which has a timestamp field? I understand that the timestamp field is a system generated field; however, it appears in the publication setup, that you can choose certain columns to be replicated(vertical partitioning). I chose the timestamp field not to be replicated, but received an error about not sending the correct number of values. I have replication setup not to sync tables, and I made sure before that the subscriber and the publisher database tables are exactly the same and contained the same data. But by unselecting the timestamp field to be published, I found that the script which contains the table definition if the tables were to be sync'd, did not contain the timestamp field. This makes me think that the subscriber must contain the exact number of columns that are being replicated, so that by turning off replication of a field, means that the subscriber cannot have this field? I would have thought that the default value of the field on the subscriber would fill in the unreplicated columns?

[Steve Harris]

The way that I got around it was by changing the timestamp column on the subscribing table to a 'binary' field. Timestamp data can then be replicated. This shouldn't pose to much of a problem data wise because the subscribing table should be read only anyway.

On 11/17/98 7:23:55 AM, KH wrote:
> Is there a way you can replicate a table which has a timestamp field? I
> understand that the timestamp field is a system generated field; however,
> it appears in the publication setup, that you can choose certain columns to
> be replicated(vertical partitioning). I chose the timestamp field not to
> be replicated, but received an error about not sending the correct number
> of values. I have replication setup not to sync tables, and I made sure
> before that the subscriber and the publisher database tables are exactly
> the same and contained the same data. But by unselecting the timestamp
> field to be published, I found that the script which contains the table
> definition if the tables were to be sync'd, did not contain the
> timestamp field. This makes me think that the subscriber must contain the
> exact number of columns that are being replicated, so that by turning off
> replication of a field, means that the subscriber cannot have this field?
> I would have thought that the default value of the field on the subscriber
> would fill in the unreplicated columns?

[valerie]

I had the same experience.

I got around this by not selecting the timestamp column and also selecting the
box that says "Use Column Names in SQL Statements". This will ensure that
a default timestamp value is placed on the subscriber....