Ed - Thank you very much for the feedback!

I totally hear what you're saying and don't want to travel down the road that results in issues.

Always On and a Separate Connection String for writes sounds like the way to go.

Unfortunately, that involves going through hundreds of stored procedures and developing a strategy to deal with the ones with writes. Our c# app is only one default.aspx page that calls one main stored procedure. The one .aspx page and one main stored procedure services an application with over 500 forms, mostly maintenance forms, 500 tables, and another 1000 stored procedures driven by actions submitted from page links. In other words a user clicks on a link to view a customer's bill. The link includes an action and the parameters needed. The main procedure based on the action calls a chain of other procedures that produces the content to view the customer's bill. In this example several writes occur indicating mostly who viewed the bill, why, and when in addition to security and MIS related logging. It's actually one of the more robust and maintenance free applications I've worked on and the assumption was publisher with updateable subscriber was there when needed.

The only thing that comes to mind is every action needs to be replicated in .net with a call for the views and a second call for the writes. It's easy to strip logging out of the stored procedures but it's months of work and testing to deal with everything else. It involves tearing the stored procedures apart, creating new ones for the writes and adding the calls to .net.

The other option that comes to mind is adding a linked server to each subscriber back to the main node but I'm not sure about the performance hit. Changing the stored procedures to accommodate the linked server would be less work and represent a lower rate of coding errors but I don't know.

If you have a moment and want to share any thoughts please let me know. Thanks again for the feedback.