"Keith Dorken" <kadorken@nospamthinkage.ca> wrote in message
news:Otjj2gD4DHA.2168@TK2MSFTNGP12.phx.gbl...
> We have a test server where developers have test databases for
> experimentation. As a condition of experimentation, I configured all the
> database tables to be replicated to determine if replication would cause
any
> problems in our design decisions. So far (earlier post) we have discovered
> that replication has different naming conventions for field names, table
> names, tc. such that you have a reduced set of characters to use in table
> names (for example, don't use % in the table name).
>
> Now, one developer has discovered that 'his' database has had a table
> modified (apparently) which now contains a column he did not create called
> "msrepl_tran_version".
>
> This clearly has something to do with the (failed) replication attempt?
>
> The developer asks:
>
> Is this crap just transient stuff that should have been cleaned out after
a
> succesful replication, or do all SQL programmers in the world have to
> contend with <search condition>s like ('Some code', 'Some desc', '{some
> GUID}') = (select * from UofM) getting semantic errors because some
> administrative process has changed the cardinality (# of columns) of the
> right operand of the compare?
>
> Is there any documentation on this and other ways replication modifies the
> database?
>
> What happens if my program changes the contents of this field in a record?
>
>
>
>
>
>