Queued Updating Subscribers Question

When I looked into setting this up I received a message that an identity column would be added to all my tables for this type of replication.
Wouldn't this result in my having to change all code that touches these tables to take the new column into account?
Queued Updating is new to me, I am trying to learn the best replication option for our reporting database, but am a little confused.
Any/All help is appreciated!
Thanx!
JLS,
if the identity column is already there on the publisher, it is transferred
to the subscriber but no new identity columns will be created. On each
indetity column the column is designated as Identity Yes (Not for
Replication). This ensures that the replication process can insert values
into the column, and for an insert on the subscriber itself SQL Server can
have values allocated as per normal. To avoid clashes, identity ranges are
allocated to publisher and each subscriber, each node having different
seeds; these ranges and the allocating of new ranges is configurable at the
publication level.
HTH,
Paul Ibison
|||I'm sorry Paul, I don't follow. I have been setting up and tearing down
replication every which way from Sunday, so everything is sort of running
together.
I changed all my identity columns on the Subscriber to Yes(Not for
Replication), I don't really have any issue here. It is my understanding
that what happens here is the value from the Publisher is popped into this
field on the Subscriber, and that's the way I would want it to work as I
don't intend to have any updates occurring on the Subscriber.
When I selected Queued Updating as an option, in the Identity warning screen
I saw a new warning that stated a new column would be added, and every table
I am replicating was listed, and the new column is a replication column.
The warning also stated that this may cause INSERT to fail & cause the table
to become larger.
Can you explain this in "For Dummies who haven't had enough coffee yet this
morning" terms?
"Paul Ibison" <Paul.Ibison@.Pygmalion.Com> wrote in message
news:%23dXpbRuTEHA.1548@.TK2MSFTNGP11.phx.gbl...
> JLS,
> if the identity column is already there on the publisher, it is
transferred
> to the subscriber but no new identity columns will be created. On each
> indetity column the column is designated as Identity Yes (Not for
> Replication). This ensures that the replication process can insert values
> into the column, and for an insert on the subscriber itself SQL Server can
> have values allocated as per normal. To avoid clashes, identity ranges are
> allocated to publisher and each subscriber, each node having different
> seeds; these ranges and the allocating of new ranges is configurable at
the
> publication level.
> HTH,
> Paul Ibison
>
|||JLS,
the column you are referring to is not an identity column -
it is a GUID. This is added and may cause tsql to fail
when it doesn't have an explicit column list eg
insert into table1
select * from replicatetable
If you are using Queued Updating Subscribers and are
letting replication do the initialization for you, you
don't need to alter identity columns on the subscriber -
they'll be set correctly for you.
HTH,
Paul Ibison
ps if you don't intend having subscribers update the data,
then why not use standard transactional replication?
|||Ah, ok I get it now. Thanx!!!!
"Paul Ibison" <Paul.Ibison@.Pygmalion.Com> wrote in message
news:1ae5301c44eee$b71dc120$a001280a@.phx.gbl...
> JLS,
> the column you are referring to is not an identity column -
> it is a GUID. This is added and may cause tsql to fail
> when it doesn't have an explicit column list eg
> insert into table1
> select * from replicatetable
> If you are using Queued Updating Subscribers and are
> letting replication do the initialization for you, you
> don't need to alter identity columns on the subscriber -
> they'll be set correctly for you.
> HTH,
> Paul Ibison
> ps if you don't intend having subscribers update the data,
> then why not use standard transactional replication?
>