I found on http://technet.microsoft.com/en-us/library/ms151749.aspx the
following statement:

If your application does not require column-level tracking, it is
recommended that you use row-level tracking (the default) because it
typically results in better synchronization performance. If row tracking
is used, the base table can include a maximum of 1,024 columns, but
columns must be filtered from the article so that a maximum of 246
columns is published. If column tracking is used, the base table can
include a maximum of 246 columns.

WHY? I am not doing column tracking (I think, how can i tell), but i
have one table that has 288 columns in it (90% of them are bit data
type). Why is the number of columns allowed so small? I thought it might
have to do w/ the database compatibility version, but i have a database
created on SQL 2005 that has compatibility set to SQL Server 2005 (90)
and i still get the same message - that my table has more than 246
columns.

I did see that transactional replication allows 1024 columns - why
wouldn't merge allow the same number?? This makes no sense and really
messes up our database.

Darin

I saw on http://msdn.microsoft.com/en-us/library/ms143432.aspx that the
maximum number of articles is 256, but i would swear we are replicating
about 342 articles - is that impossible?

Darin