I am using standard, transactional replication. But I needed a way to automate publications and subscriptions, so I used Profiler to spy on qwhat SQL did during the GUI portion...

ok, I think new indexes were in order.

i ran the same query on both servers, and the new index on the replicated table is now much faster

select * from response_1000...

I had created a long reply, and after submitting it disapeared, so I won't go back into details...

k, I just dropped the existing Indexes, and created a clustered index on...

These would be entirely new tables....

It doesn't crash the SQL Server, it crashes the software that populates the sql server...

I can't post any of this data unfortunately...

The respondent table is a list of people who took part, and their completion code.

I just link to that to only import the...

Here's my table creation script... For some reason the replication didn't copy over the PK, but it does create the PK clustered index. Plus the query runs just as slow...

There's already a clustered index, and it's already using it.

A lot of my initial queries seem to need to use an Index Scan, not a seek. (SELECT DISTINCT(ANSWERTEXT) WHERE QUESTION...

My Nightmare is well on it's way already RyanRandall, here's how I got here. I posted another topic in Performance and Tuning too...

- We have a survey software that is...

Wonderful! Thanks....

Never mind that last post.. I've fixed that portion of it....

Even after adding the article and having the new table exist on the subscriber, the new article does not work....

It's odd, my log reader is giving me errors now so even a straightforward replication is not working...

Now I'm getting...

"The process could not execute 'sp_repldone/sp_replcounters' on 'MYSERVERNAME'"

I was able to figure out sp_addarticle, and it did modify the publication correctly, but never updated the subscriber.

So if the table on the subscriber exists, it will automatically start...