We have a sharepoint <\\ces\cesgypdav> that is a WebDAV connection, not an actual fileshare. A SSRS Subscription fails on file write ... "Failure writing file <name here > : The network path was not found" ... to this path.
Can SQL Reporting write to a WebDAV sharepoint?
WebDAV issue is known, need to 'work around'.This helps: http://sqljunkies.com/WebLog/tpagel/archive/2005/12/23/17682.aspx
Hello,
I was curious if you can have merge and/or snapshot replication setup on a MS sharepoint database? Thanks.
John
I don't think that those will work for the following reason.
At a recent MS course, we asked our instructor if it was possible to change the content database in SP central Admin to a secondary database server during a crisis. They advised that this might be a problem because the SP configuration database creates hard-coded entries referencing the database server name that it resides on. They suspsected that these entries would cause problems in the long run, if not right away.
We decided to test this out by creating a virtual environment that mimicked our production system. We then copied the database to a seperate physical machine. To try and avoid the configuration database problems, we created a new virtual site on the VM that mirrored our existing front end and pointed it to the new database to recreate the configuration database.
Everything worked okay for about 3 hours then we began to see timeouts due to maxpoolsize being reached. When we checked the event log we also found that the server was STILL trying to connect to the original database even though everything was on the new server. Eventually, it became impossible to access any of the sites in the virtual environment.
I imagine that these entries in the configuration database would cause the same problem if we were to replicate from one server to another. We're now thinking of using log shipping or clustering to try and provide the redundancy we're looking for.
|||Jaydog,
Thanks for your reply.
John
|||Hey John,Looks like I was premature with my first response. We tried the same thing one more time, except that we shut down the old SQL Server before clearing the old configuration database and allowing SharePoint to rebuild it. So far, it looks like everything is up and running.
We're giving it a few days to see if there are any adverse effects and then we will be trying to get merge replication up and running. I'll post again once there is more to report.|||
Jaydog,
I look forward to what you find out.
John
|||Jaydog,
I was curious if you had an update on this?
John
|||Jaydog,
I would also be interested in finding out how that went.
JBW
Hello,
I was curious if you can have merge and/or snapshot replication setup on a MS sharepoint database? Thanks.
John
I don't think that those will work for the following reason.
At a recent MS course, we asked our instructor if it was possible to change the content database in SP central Admin to a secondary database server during a crisis. They advised that this might be a problem because the SP configuration database creates hard-coded entries referencing the database server name that it resides on. They suspsected that these entries would cause problems in the long run, if not right away.
We decided to test this out by creating a virtual environment that mimicked our production system. We then copied the database to a seperate physical machine. To try and avoid the configuration database problems, we created a new virtual site on the VM that mirrored our existing front end and pointed it to the new database to recreate the configuration database.
Everything worked okay for about 3 hours then we began to see timeouts due to maxpoolsize being reached. When we checked the event log we also found that the server was STILL trying to connect to the original database even though everything was on the new server. Eventually, it became impossible to access any of the sites in the virtual environment.
I imagine that these entries in the configuration database would cause the same problem if we were to replicate from one server to another. We're now thinking of using log shipping or clustering to try and provide the redundancy we're looking for.
|||Jaydog,
Thanks for your reply.
John
|||Hey John,Looks like I was premature with my first response. We tried the same thing one more time, except that we shut down the old SQL Server before clearing the old configuration database and allowing SharePoint to rebuild it. So far, it looks like everything is up and running.
We're giving it a few days to see if there are any adverse effects and then we will be trying to get merge replication up and running. I'll post again once there is more to report.
|||
Jaydog,
I look forward to what you find out.
John
|||Jaydog,
I was curious if you had an update on this?
John
|||Jaydog,
I would also be interested in finding out how that went.
JBW
Hello,
I was curious if you can have merge and/or snapshot replication setup on a MS sharepoint database? Thanks.
John
I don't think that those will work for the following reason.
At a recent MS course, we asked our instructor if it was possible to change the content database in SP central Admin to a secondary database server during a crisis. They advised that this might be a problem because the SP configuration database creates hard-coded entries referencing the database server name that it resides on. They suspsected that these entries would cause problems in the long run, if not right away.
We decided to test this out by creating a virtual environment that mimicked our production system. We then copied the database to a seperate physical machine. To try and avoid the configuration database problems, we created a new virtual site on the VM that mirrored our existing front end and pointed it to the new database to recreate the configuration database.
Everything worked okay for about 3 hours then we began to see timeouts due to maxpoolsize being reached. When we checked the event log we also found that the server was STILL trying to connect to the original database even though everything was on the new server. Eventually, it became impossible to access any of the sites in the virtual environment.
I imagine that these entries in the configuration database would cause the same problem if we were to replicate from one server to another. We're now thinking of using log shipping or clustering to try and provide the redundancy we're looking for.
|||Jaydog,
Thanks for your reply.
John
|||Hey John,Looks like I was premature with my first response. We tried the same thing one more time, except that we shut down the old SQL Server before clearing the old configuration database and allowing SharePoint to rebuild it. So far, it looks like everything is up and running.
We're giving it a few days to see if there are any adverse effects and then we will be trying to get merge replication up and running. I'll post again once there is more to report.|||
Jaydog,
I look forward to what you find out.
John
|||Jaydog,
I was curious if you had an update on this?
John
|||Jaydog,
I would also be interested in finding out how that went.
JBW
