I'm trying to replicate a table that now has more than 256 columns. SQL2000
chokes when creating replication with error 20068, stating that the maximum
number of columns allowed for an article is 256.
The workarounds I am aware of involve creating two tables and using views to
abstract this change from the front end application. There is no way my
client will pay for a change as drastic as this with the only benifit is that
replication will now be allowed to work.
I have two questions:
a. Is there a better workaround?
b. Does SQL2005 solve this issue (I might be better able to sell my client
on an upgrade)?
partitioning the table as you describe is the standard workaround in SQL
Serever 2000.
In SQL Server 2005, for merge the max no of columns is 246. For
transactional and snapshot it is 1000 (995 with Oracle).
Cheers,
Paul Ibison SQL Server MVP, www.replicationanswers.com
(recommended sql server 2000 replication book:
http://www.nwsu.com/0974973602p.html)
|||If the application using this table uses a stored procedure to make the
updates you may be able to replicate the execution of the stored procedure -
however there is the same procedure limit. Another option is to use a
trigger to write to two "audit" tables and replicate these audit tables to
the subscriber where they in turn assemble the final row.
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
"dtaylo75" <dtaylo75@.discussions.microsoft.com> wrote in message
news:EE67681F-C2FE-489B-88B1-1A69F719DE6D@.microsoft.com...
> I'm trying to replicate a table that now has more than 256 columns.
> SQL2000
> chokes when creating replication with error 20068, stating that the
> maximum
> number of columns allowed for an article is 256.
> The workarounds I am aware of involve creating two tables and using views
> to
> abstract this change from the front end application. There is no way my
> client will pay for a change as drastic as this with the only benifit is
> that
> replication will now be allowed to work.
> I have two questions:
> a. Is there a better workaround?
> b. Does SQL2005 solve this issue (I might be better able to sell my client
> on an upgrade)?
No comments:
Post a Comment