Showing posts with label removing. Show all posts
Showing posts with label removing. Show all posts

Monday, March 26, 2012

Moving the distribution database

Hi all,
Is it possible to move the distribution database to a new folder/drive
without removing replication? I am attempting to do it the same way you
would move tempdb:

ALTER DATABASE distribution MODIFY FILE
(name = distmodel, filename = 'C:\DISTMOVED\distribution.MDF')
ALTER DATABASE distribution MODIFY FILE
(name = distmodel_log, filename = 'C:\DISTMOVED\distribution.LDF')

But I get -
Server: Msg 5037, Level 16, State 1, Line 1
MODIFY FILE failed. Do not specify physical name.

Thanks,
Joshjoshsackett (joshsackett@.gmail.com) writes:
> Is it possible to move the distribution database to a new folder/drive
> without removing replication? I am attempting to do it the same way you
> would move tempdb:
> ALTER DATABASE distribution MODIFY FILE
> (name = distmodel, filename = 'C:\DISTMOVED\distribution.MDF')
> ALTER DATABASE distribution MODIFY FILE
> (name = distmodel_log, filename = 'C:\DISTMOVED\distribution.LDF')
> But I get -
> Server: Msg 5037, Level 16, State 1, Line 1
> MODIFY FILE failed. Do not specify physical name.

According to Books Online, FILENAME is permitted for tempdb only.

For a regular database, one can always detach it, copy it and attach
it from the new location. Yet an alternative is to add files, and
then use DBCC SHRINKFILE to empty the first and then remove that
file, a fairly cumbersome operation. But whether that is possible for
distribution, I have idea.

I would ask in microsoft.public.sqlserver.replication, if I were
you.

--
Erland Sommarskog, SQL Server MVP, esquel@.sommarskog.se

Books Online for SQL Server SP3 at
http://www.microsoft.com/sql/techin.../2000/books.asp|||Thank you Erland.
I have since learned that it is impossible to move the distribution db.
You have to completely remove replication and then start over.

Oh well.

Josh

Wednesday, March 21, 2012

Moving SQL Server/Report Server off public IP

We are planning on moving our SQL Server off of the same machine as our web
server and securing it behind a firewall, removing all accessibility by
public IP. However, our web app uses the report viewer control to render
reports, and it points to <default IP of the web server>/ReportServer, which
was set up by Reporting Services. The client does in fact make a connection
to that IP. If SQL Server (and consequently Reporting Services) moves to
where it cannot be accessed by a client, how can they view reports?So, does the lack of answer here mean that I must have SQL Server on a
public IP, or does it mean the answer's already somewhere else, waiting for
me to look?
"DJM" <msnews@.puddlestheshark.com> wrote in message
news:ePnImS54EHA.1192@.tk2msftngp13.phx.gbl...
> We are planning on moving our SQL Server off of the same machine as our
> web server and securing it behind a firewall, removing all accessibility
> by public IP. However, our web app uses the report viewer control to
> render reports, and it points to <default IP of the web
> server>/ReportServer, which was set up by Reporting Services. The client
> does in fact make a connection to that IP. If SQL Server (and
> consequently Reporting Services) moves to where it cannot be accessed by a
> client, how can they view reports?
>|||There are two ways to integrate with RS. URL integration and web services. I
have not used the report viewer control but my impression (and your
description of the issue you are having confirms it) is that it uses URL
integration. The advantage of URL integration is simplicity plus drill
through (jump to report) works as well. With web services you basically have
to implement your own jump to report (drill through). Web services takes
more work but you have more control. With web services you can create an
application where your web server integrates to reporting services behind
the firewall where the client PCs never directly access the server behind
the firewall. That is one option for you.
Another option for you is to have the SQL Server Database behind the
firewall and the Reporting Services application on the public IP. You have
to buy another license but it resolves your problem. Plus, given the cost to
rework your solution to use web services would most likely cost more than
purchasing another license. Also, keep in mind that your data you report
against (which most likely is what you want behind the firewall) does not
have to be on the same SQL Server that is used by RS. So you could still
have SQL Server on the public IP but use it only for RS and have all the
data used by the reports on a second SQL Server that is behind the firewall.
HTH,
--
Bruce Loehle-Conger
MVP SQL Server Reporting Services
"DJM" <msnews@.puddlestheshark.com> wrote in message
news:OC73ygQ6EHA.1120@.TK2MSFTNGP11.phx.gbl...
> So, does the lack of answer here mean that I must have SQL Server on a
> public IP, or does it mean the answer's already somewhere else, waiting
for
> me to look?
> "DJM" <msnews@.puddlestheshark.com> wrote in message
> news:ePnImS54EHA.1192@.tk2msftngp13.phx.gbl...
> > We are planning on moving our SQL Server off of the same machine as our
> > web server and securing it behind a firewall, removing all accessibility
> > by public IP. However, our web app uses the report viewer control to
> > render reports, and it points to <default IP of the web
> > server>/ReportServer, which was set up by Reporting Services. The
client
> > does in fact make a connection to that IP. If SQL Server (and
> > consequently Reporting Services) moves to where it cannot be accessed by
a
> > client, how can they view reports?
> >
>|||Thank you so much for the response. I was hoping to avoid having to get
another SQL Server license for the front end simply for Reporting Services
(not to mention it would mean pushing reports to the web server[s] instead
of keeping it on the SQL Server close to the data), but that looks like it
would be the easiest.
Thanks again for the info.
"Bruce L-C [MVP]" <bruce_lcNOSPAM@.hotmail.com> wrote in message
news:ewzXvrQ6EHA.1408@.TK2MSFTNGP10.phx.gbl...
> There are two ways to integrate with RS. URL integration and web services.
> I
> have not used the report viewer control but my impression (and your
> description of the issue you are having confirms it) is that it uses URL
> integration. The advantage of URL integration is simplicity plus drill
> through (jump to report) works as well. With web services you basically
> have
> to implement your own jump to report (drill through). Web services takes
> more work but you have more control. With web services you can create an
> application where your web server integrates to reporting services behind
> the firewall where the client PCs never directly access the server behind
> the firewall. That is one option for you.
> Another option for you is to have the SQL Server Database behind the
> firewall and the Reporting Services application on the public IP. You have
> to buy another license but it resolves your problem. Plus, given the cost
> to
> rework your solution to use web services would most likely cost more than
> purchasing another license. Also, keep in mind that your data you report
> against (which most likely is what you want behind the firewall) does not
> have to be on the same SQL Server that is used by RS. So you could still
> have SQL Server on the public IP but use it only for RS and have all the
> data used by the reports on a second SQL Server that is behind the
> firewall.
> HTH,
> --
> Bruce Loehle-Conger
> MVP SQL Server Reporting Services
> "DJM" <msnews@.puddlestheshark.com> wrote in message
> news:OC73ygQ6EHA.1120@.TK2MSFTNGP11.phx.gbl...
>> So, does the lack of answer here mean that I must have SQL Server on a
>> public IP, or does it mean the answer's already somewhere else, waiting
> for
>> me to look?
>> "DJM" <msnews@.puddlestheshark.com> wrote in message
>> news:ePnImS54EHA.1192@.tk2msftngp13.phx.gbl...
>> > We are planning on moving our SQL Server off of the same machine as our
>> > web server and securing it behind a firewall, removing all
>> > accessibility
>> > by public IP. However, our web app uses the report viewer control to
>> > render reports, and it points to <default IP of the web
>> > server>/ReportServer, which was set up by Reporting Services. The
> client
>> > does in fact make a connection to that IP. If SQL Server (and
>> > consequently Reporting Services) moves to where it cannot be accessed
>> > by
> a
>> > client, how can they view reports?
>> >
>>
>