Some options come to mind. The first involves putting pks on these tables
and using transactional replication. The second involves using views to
insulate the tables which now have pk's on them. The pk would consist on an
int identity column. The app would talk to the view and would not see the
identity column/pk. This only works on small tables. The third option is to
place triggers on these tables which will write to "audit" tables which will
contain a key column. Then you just replicate off these key columns. Another
option is to replicate from indexed views which are based on your tables.
--
Hilary Cotter
Looking for a SQL Server replication book?
http://www.nwsu.com/0974973602.html Looking for a FAQ on Indexing Services/SQL FTS
http://www.indexserverfaq.com [quoted text, click to view] "Ches Weldishofer" <ches.weldishofer@gmail.com> wrote in message
news:1134514773.122118.213640@g14g2000cwa.googlegroups.com...
> We're trying to pull approximately 50 tables out of a database of
> 16,000. Unfortunatley none of them have primary keys, they are all
> keyed by multiple fields (mostly effective dated).
>
> Ideally we'ld like to see only changed or inserted records be loaded
> into the subscriber. (Those would be processed for a DW).
>
> I can't find a neat solution.
>
> We can't use transactional replication because there are no primary
> keys,
>
> if we used Snapshot replication then (as far as I can tell) we'ld have
> to go through every line to see if it needed to be processed.
>
> Log shipping won't work because of the sheer size of the database and
> the smidgen of it that we actually want.
>
> We've toyed with adding a timestamp to every table to be pulled, but
> that gets into update issues and all sorts of potential problems down
> the road.
>
> Any suggestion would be very much appreciated, before I go totally
> grey!!!
>
> Ches Weldishofer
> Clear Channel Worldwide
>
