Showing posts with label databases. Show all posts
Showing posts with label databases. Show all posts

Thursday, March 29, 2012

Descriptions on databases

Is there any way to put a description on a database? We have a couple databases that use acronyms which I would like to spell out as metadata.

See SQL Server 2005 Books Online topic:
Using Extended Properties on Database Objects
http://msdn2.microsoft.com/en-us/library/ms190243.aspx

Wednesday, March 21, 2012

Deployment and Configuration

I have several clients using several SQL server databases that have all been
setup on one machine which they access remotely using terminal services. Each
client has their own software installation with their own set of databases.
So, there would be many client installations on the same machine. How would i
setup reporting services so that each client has their own set of reports?
How would i go about deploying the reports for each client given that the
clients' databases would have different names and hence the connection
strings will be different? Please help!
regardsSet up a datasource for each client - unless you have hundreds, in which case
I am not sure.sql

Sunday, March 11, 2012

deploying reports database to multiple servers

Hi,
i have some 35 customers, all of whom need a copy of the reports i have designed
how do i quickly and simply roll out my reports. the databases are generally , but not
always given the same name, and the user credentials will be different
but the reports need to be the same.

is this possible?

Regards,

Russ

You have two basic options:

1.) Script out creating the reports in the database and provide the scripts to your users.

2.) Detach your database, and give it to your users. They can then attach the database, and configure RS to use that database via the config tool. If they do this, they have to be sure to leave the name of the databases that same.

|||

Cheers John,

im wondering how easy it is to do option 1. is there an example available that you know of?

Regards,

Russ

|||

Try rdlscripter, it is very easy to do this.

http://www.sqldbatips.com/showarticle.asp?ID=62

deploying reports database to multiple servers

Hi,
i have some 35 customers, all of whom need a copy of the reports i have designed
how do i quickly and simply roll out my reports. the databases are generally , but not
always given the same name, and the user credentials will be different
but the reports need to be the same.

is this possible?

Regards,

Russ

You have two basic options:

1.) Script out creating the reports in the database and provide the scripts to your users.

2.) Detach your database, and give it to your users. They can then attach the database, and configure RS to use that database via the config tool. If they do this, they have to be sure to leave the name of the databases that same.

|||

Cheers John,

im wondering how easy it is to do option 1. is there an example available that you know of?

Regards,

Russ

|||

Try rdlscripter, it is very easy to do this.

http://www.sqldbatips.com/showarticle.asp?ID=62

Friday, March 9, 2012

Deploying DB Maintenance plan in SQL 2005 across many differentservers

I am in the process of depolying a database maintenance plan tasks for
several servers. I have designed one using the Databases maintenance
plan wizard but I want to be able to replicate the same maintenance
plan for all the SQL instances in our environment. I want to avoid to
manually create them for each and every instance? If possible I want
to also avoid importing this from other servers, I am looking to see
if there is a way to script it all.
Is there a way to deploy the same database maintenance plan for all
the SQL instances in a automated fashion? What will be the most
efficient way to accomplish this?
Any help in this regard will be greatly appreciated.
Thanks
Take a look at SQL Farms and see if it can help out.
Kevin G. Boles
Indicium Resources, Inc.
SQL Server MVP
kgboles a earthlink dt net
"shub" <shubtech@.gmail.com> wrote in message
news:da1295e1-0f53-4b03-8a70-d3ca9903c812@.d21g2000prf.googlegroups.com...
>I am in the process of depolying a database maintenance plan tasks for
> several servers. I have designed one using the Databases maintenance
> plan wizard but I want to be able to replicate the same maintenance
> plan for all the SQL instances in our environment. I want to avoid to
> manually create them for each and every instance? If possible I want
> to also avoid importing this from other servers, I am looking to see
> if there is a way to script it all.
> Is there a way to deploy the same database maintenance plan for all
> the SQL instances in a automated fashion? What will be the most
> efficient way to accomplish this?
> Any help in this regard will be greatly appreciated.
> Thanks
|||On Mar 24, 10:47Xam, "TheSQLGuru" <kgbo...@.earthlink.net> wrote:
> Take a look at SQL Farms and see if it can help out.
> --
> Kevin G. Boles
> Indicium Resources, Inc.
> SQL Server MVP
> kgboles a earthlink dt net
> "shub" <shubt...@.gmail.com> wrote in message
> news:da1295e1-0f53-4b03-8a70-d3ca9903c812@.d21g2000prf.googlegroups.com...
>
>
>
> - Show quoted text -
Thank you so much for your response. Besides this product is there any
other option to deploy database maintenance plan across different
server in SQL 2005?
|||That is one of the down falls of using the maintenance plans. I would create
your own scheduled jobs and custom maintenance sps so that you can script
these and do what you want with them.
Andrew J. Kelly SQL MVP
Solid Quality Mentors
"shub" <shubtech@.gmail.com> wrote in message
news:da1295e1-0f53-4b03-8a70-d3ca9903c812@.d21g2000prf.googlegroups.com...
>I am in the process of depolying a database maintenance plan tasks for
> several servers. I have designed one using the Databases maintenance
> plan wizard but I want to be able to replicate the same maintenance
> plan for all the SQL instances in our environment. I want to avoid to
> manually create them for each and every instance? If possible I want
> to also avoid importing this from other servers, I am looking to see
> if there is a way to script it all.
> Is there a way to deploy the same database maintenance plan for all
> the SQL instances in a automated fashion? What will be the most
> efficient way to accomplish this?
> Any help in this regard will be greatly appreciated.
> Thanks
|||You may be able to generate a script for the plan (not sure about this
though) and then execute that script against each server. Seems that most
objects in SSMS can be scripted out.
I do agree with Andrew that you should consider not using maintenance plans
at all and do/control everything with your own scripts.
Kevin G. Boles
Indicium Resources, Inc.
SQL Server MVP
kgboles a earthlink dt net
"shub" <shubtech@.gmail.com> wrote in message
news:20611010-8c52-4718-982c-4f4400a0b6bc@.s12g2000prg.googlegroups.com...
On Mar 24, 10:47 am, "TheSQLGuru" <kgbo...@.earthlink.net> wrote:
> Take a look at SQL Farms and see if it can help out.
> --
> Kevin G. Boles
> Indicium Resources, Inc.
> SQL Server MVP
> kgboles a earthlink dt net
> "shub" <shubt...@.gmail.com> wrote in message
> news:da1295e1-0f53-4b03-8a70-d3ca9903c812@.d21g2000prf.googlegroups.com...
>
>
>
> - Show quoted text -
Thank you so much for your response. Besides this product is there any
other option to deploy database maintenance plan across different
server in SQL 2005?
|||On Mar 25, 12:54Xpm, "Tibor Karaszi"
<tibor_please.no.email_kara...@.hotmail.nomail.com> wrote:
> I guess one could investigate to export the maint plan to a .dtsx file (a maint plan is an SSIS
> package after all). And use that dtsx file as base for multi-server deployment. Of course, one need
> to investigate how much customization of the dtsx file is needed. For instance, you don't want to
> deploy such file to another server if the old server name is in there somewhere.
> --
> Tibor Karaszi, SQL Server MVPhttp://www.karaszi.com/sqlserver/default.asphttp://sqlblog.com/blogs/tibor_karaszi
>
> "TheSQLGuru" <kgbo...@.earthlink.net> wrote in messagenews:13uievj7t0rja8e@.corp.supernews.com...
>
>
>
>
>
>
> - Show quoted text -
FWIW - this does work and the only thing that needs to be changed is
the connection. The steps are:
1) Export to dtsx file
2) Open in BIDS
3) Modify the connection to the destination server
4) Import into the destination server
However, this does not import the schedules and can cause problems if
you import over an existing maintenance plan. Once the maintenance
plan has been imported, you still have to open the plan on the
destination server and modify the plan to schedule each sub-plan.
Personally, I have found that it really does not take any longer to
create a new maintenance plan manually than it does to export/modify/
import/update on each destination server.
Jeff
|||And everytime you do something manually you run the risk of making an error
or having some setting different on different servers inadvertently. A well
tested script can be configured to set everything right each time for each
server/DB it needs to act against.
Also, you can easily script job schedules too as well as check for existence
of existing job/maintenance plan prior to stomping on it. :-)
Kevin G. Boles
Indicium Resources, Inc.
SQL Server MVP
kgboles a earthlink dt net
"Jeffrey Williams" <jeff.williams@.sharp.com> wrote in message
news:9b46cf7e-7d44-4473-acdc-458d33c7cb15@.e10g2000prf.googlegroups.com...
On Mar 25, 12:54 pm, "Tibor Karaszi"
<tibor_please.no.email_kara...@.hotmail.nomail.com> wrote:
> I guess one could investigate to export the maint plan to a .dtsx file (a
> maint plan is an SSIS
> package after all). And use that dtsx file as base for multi-server
> deployment. Of course, one need
> to investigate how much customization of the dtsx file is needed. For
> instance, you don't want to
> deploy such file to another server if the old server name is in there
> somewhere.
> --
> Tibor Karaszi, SQL Server
> MVPhttp://www.karaszi.com/sqlserver/default.asphttp://sqlblog.com/blogs/tibor_karaszi
>
> "TheSQLGuru" <kgbo...@.earthlink.net> wrote in
> messagenews:13uievj7t0rja8e@.corp.supernews.com...
>
>
>
>
>
>
> - Show quoted text -
FWIW - this does work and the only thing that needs to be changed is
the connection. The steps are:
1) Export to dtsx file
2) Open in BIDS
3) Modify the connection to the destination server
4) Import into the destination server
However, this does not import the schedules and can cause problems if
you import over an existing maintenance plan. Once the maintenance
plan has been imported, you still have to open the plan on the
destination server and modify the plan to schedule each sub-plan.
Personally, I have found that it really does not take any longer to
create a new maintenance plan manually than it does to export/modify/
import/update on each destination server.
Jeff
|||In addition you may not have the same DB's on each server so unless you
chose it to do all dbs it will fail as well.
Andrew J. Kelly SQL MVP
Solid Quality Mentors
"TheSQLGuru" <kgboles@.earthlink.net> wrote in message
news:13uis61kv2i4n92@.corp.supernews.com...
> And everytime you do something manually you run the risk of making an
> error or having some setting different on different servers inadvertently.
> A well tested script can be configured to set everything right each time
> for each server/DB it needs to act against.
> Also, you can easily script job schedules too as well as check for
> existence of existing job/maintenance plan prior to stomping on it. :-)
>
> --
> Kevin G. Boles
> Indicium Resources, Inc.
> SQL Server MVP
> kgboles a earthlink dt net
>
> "Jeffrey Williams" <jeff.williams@.sharp.com> wrote in message
> news:9b46cf7e-7d44-4473-acdc-458d33c7cb15@.e10g2000prf.googlegroups.com...
> On Mar 25, 12:54 pm, "Tibor Karaszi"
> <tibor_please.no.email_kara...@.hotmail.nomail.com> wrote:
> FWIW - this does work and the only thing that needs to be changed is
> the connection. The steps are:
> 1) Export to dtsx file
> 2) Open in BIDS
> 3) Modify the connection to the destination server
> 4) Import into the destination server
> However, this does not import the schedules and can cause problems if
> you import over an existing maintenance plan. Once the maintenance
> plan has been imported, you still have to open the plan on the
> destination server and modify the plan to schedule each sub-plan.
> Personally, I have found that it really does not take any longer to
> create a new maintenance plan manually than it does to export/modify/
> import/update on each destination server.
> Jeff
>

Deploying DB Maintenance plan in SQL 2005 across many different

I am in the process of depolying a database maintenance plan tasks for
several servers. I have designed one using the Databases maintenance
plan wizard but I want to be able to replicate the same maintenance
plan for all the SQL instances in our environment. I want to avoid to
manually create them for each and every instance? If possible I want
to also avoid importing this from other servers, I am looking to see
if there is a way to script it all.
Is there a way to deploy the same database maintenance plan for all
the SQL instances in a automated fashion? What will be the most
efficient way to accomplish this?
Any help in this regard will be greatly appreciated.
ThanksTake a look at SQL Farms and see if it can help out.
--
Kevin G. Boles
Indicium Resources, Inc.
SQL Server MVP
kgboles a earthlink dt net
"shub" <shubtech@.gmail.com> wrote in message
news:da1295e1-0f53-4b03-8a70-d3ca9903c812@.d21g2000prf.googlegroups.com...
>I am in the process of depolying a database maintenance plan tasks for
> several servers. I have designed one using the Databases maintenance
> plan wizard but I want to be able to replicate the same maintenance
> plan for all the SQL instances in our environment. I want to avoid to
> manually create them for each and every instance? If possible I want
> to also avoid importing this from other servers, I am looking to see
> if there is a way to script it all.
> Is there a way to deploy the same database maintenance plan for all
> the SQL instances in a automated fashion? What will be the most
> efficient way to accomplish this?
> Any help in this regard will be greatly appreciated.
> Thanks|||On Mar 24, 10:47=A0am, "TheSQLGuru" <kgbo...@.earthlink.net> wrote:
> Take a look at SQL Farms and see if it can help out.
> --
> Kevin G. Boles
> Indicium Resources, Inc.
> SQL Server MVP
> kgboles a earthlink dt net
> "shub" <shubt...@.gmail.com> wrote in message
> news:da1295e1-0f53-4b03-8a70-d3ca9903c812@.d21g2000prf.googlegroups.com...
>
> >I am in the process of depolying a database maintenance plan tasks for
> > several servers. I have designed one using the Databases maintenance
> > plan wizard but I want to be able to replicate the same maintenance
> > plan for all the SQL instances in our environment. =A0I want to avoid to=
> > manually create them for each and every instance? If possible I want
> > to also avoid importing this from other servers, I am looking to see
> > if there is a way to script it all.
> > Is there a way to deploy the same database maintenance plan for all
> > the SQL instances in a automated fashion? =A0What will be the most
> > efficient way to accomplish this?
> > Any help in this regard will be greatly appreciated.
> > Thanks- Hide quoted text -
> - Show quoted text -
Thank you so much for your response. Besides this product is there any
other option to deploy database maintenance plan across different
server in SQL 2005?|||That is one of the down falls of using the maintenance plans. I would create
your own scheduled jobs and custom maintenance sps so that you can script
these and do what you want with them.
--
Andrew J. Kelly SQL MVP
Solid Quality Mentors
"shub" <shubtech@.gmail.com> wrote in message
news:da1295e1-0f53-4b03-8a70-d3ca9903c812@.d21g2000prf.googlegroups.com...
>I am in the process of depolying a database maintenance plan tasks for
> several servers. I have designed one using the Databases maintenance
> plan wizard but I want to be able to replicate the same maintenance
> plan for all the SQL instances in our environment. I want to avoid to
> manually create them for each and every instance? If possible I want
> to also avoid importing this from other servers, I am looking to see
> if there is a way to script it all.
> Is there a way to deploy the same database maintenance plan for all
> the SQL instances in a automated fashion? What will be the most
> efficient way to accomplish this?
> Any help in this regard will be greatly appreciated.
> Thanks|||You may be able to generate a script for the plan (not sure about this
though) and then execute that script against each server. Seems that most
objects in SSMS can be scripted out.
I do agree with Andrew that you should consider not using maintenance plans
at all and do/control everything with your own scripts.
--
Kevin G. Boles
Indicium Resources, Inc.
SQL Server MVP
kgboles a earthlink dt net
"shub" <shubtech@.gmail.com> wrote in message
news:20611010-8c52-4718-982c-4f4400a0b6bc@.s12g2000prg.googlegroups.com...
On Mar 24, 10:47 am, "TheSQLGuru" <kgbo...@.earthlink.net> wrote:
> Take a look at SQL Farms and see if it can help out.
> --
> Kevin G. Boles
> Indicium Resources, Inc.
> SQL Server MVP
> kgboles a earthlink dt net
> "shub" <shubt...@.gmail.com> wrote in message
> news:da1295e1-0f53-4b03-8a70-d3ca9903c812@.d21g2000prf.googlegroups.com...
>
> >I am in the process of depolying a database maintenance plan tasks for
> > several servers. I have designed one using the Databases maintenance
> > plan wizard but I want to be able to replicate the same maintenance
> > plan for all the SQL instances in our environment. I want to avoid to
> > manually create them for each and every instance? If possible I want
> > to also avoid importing this from other servers, I am looking to see
> > if there is a way to script it all.
> > Is there a way to deploy the same database maintenance plan for all
> > the SQL instances in a automated fashion? What will be the most
> > efficient way to accomplish this?
> > Any help in this regard will be greatly appreciated.
> > Thanks- Hide quoted text -
> - Show quoted text -
Thank you so much for your response. Besides this product is there any
other option to deploy database maintenance plan across different
server in SQL 2005?|||I guess one could investigate to export the maint plan to a .dtsx file (a maint plan is an SSIS
package after all). And use that dtsx file as base for multi-server deployment. Of course, one need
to investigate how much customization of the dtsx file is needed. For instance, you don't want to
deploy such file to another server if the old server name is in there somewhere.
--
Tibor Karaszi, SQL Server MVP
http://www.karaszi.com/sqlserver/default.asp
http://sqlblog.com/blogs/tibor_karaszi
"TheSQLGuru" <kgboles@.earthlink.net> wrote in message news:13uievj7t0rja8e@.corp.supernews.com...
> You may be able to generate a script for the plan (not sure about this though) and then execute
> that script against each server. Seems that most objects in SSMS can be scripted out.
> I do agree with Andrew that you should consider not using maintenance plans at all and do/control
> everything with your own scripts.
> --
> Kevin G. Boles
> Indicium Resources, Inc.
> SQL Server MVP
> kgboles a earthlink dt net
>
> "shub" <shubtech@.gmail.com> wrote in message
> news:20611010-8c52-4718-982c-4f4400a0b6bc@.s12g2000prg.googlegroups.com...
> On Mar 24, 10:47 am, "TheSQLGuru" <kgbo...@.earthlink.net> wrote:
>> Take a look at SQL Farms and see if it can help out.
>> --
>> Kevin G. Boles
>> Indicium Resources, Inc.
>> SQL Server MVP
>> kgboles a earthlink dt net
>> "shub" <shubt...@.gmail.com> wrote in message
>> news:da1295e1-0f53-4b03-8a70-d3ca9903c812@.d21g2000prf.googlegroups.com...
>>
>> >I am in the process of depolying a database maintenance plan tasks for
>> > several servers. I have designed one using the Databases maintenance
>> > plan wizard but I want to be able to replicate the same maintenance
>> > plan for all the SQL instances in our environment. I want to avoid to
>> > manually create them for each and every instance? If possible I want
>> > to also avoid importing this from other servers, I am looking to see
>> > if there is a way to script it all.
>> > Is there a way to deploy the same database maintenance plan for all
>> > the SQL instances in a automated fashion? What will be the most
>> > efficient way to accomplish this?
>> > Any help in this regard will be greatly appreciated.
>> > Thanks- Hide quoted text -
>> - Show quoted text -
> Thank you so much for your response. Besides this product is there any
> other option to deploy database maintenance plan across different
> server in SQL 2005?
>|||On Mar 25, 12:54=A0pm, "Tibor Karaszi"
<tibor_please.no.email_kara...@.hotmail.nomail.com> wrote:
> I guess one could investigate to export the maint plan to a .dtsx file (a =maint plan is an SSIS
> package after all). And use that dtsx file as base for multi-server deploy=ment. Of course, one need
> to investigate how much customization of the dtsx file is needed. For inst=ance, you don't want to
> deploy such file to another server if the old server name is in there some=where.
> --
> Tibor Karaszi, SQL Server MVPhttp://www.karaszi.com/sqlserver/default.asph=
ttp://sqlblog.com/blogs/tibor_karaszi
>
> "TheSQLGuru" <kgbo...@.earthlink.net> wrote in messagenews:13uievj7t0rja8e@.=corp.supernews.com...
> > You may be able to generate a script for the plan (not sure about this t=hough) and then execute
> > that script against each server. =A0Seems that most objects in SSMS can =be scripted out.
> > I do agree with Andrew that you should consider not using maintenance pl=ans at all and do/control
> > everything with your own scripts.
> > --
> > Kevin G. Boles
> > Indicium Resources, Inc.
> > SQL Server MVP
> > kgboles a earthlink dt net
> > "shub" <shubt...@.gmail.com> wrote in message
> >news:20611010-8c52-4718-982c-4f4400a0b6bc@.s12g2000prg.googlegroups.com...=
> > On Mar 24, 10:47 am, "TheSQLGuru" <kgbo...@.earthlink.net> wrote:
> >> Take a look at SQL Farms and see if it can help out.
> >> --
> >> Kevin G. Boles
> >> Indicium Resources, Inc.
> >> SQL Server MVP
> >> kgboles a earthlink dt net
> >> "shub" <shubt...@.gmail.com> wrote in message
> >>news:da1295e1-0f53-4b03-8a70-d3ca9903c812@.d21g2000prf.googlegroups.com..=.
> >> >I am in the process of depolying a database maintenance plan tasks for=
> >> > several servers. I have designed one using the Databases maintenance
> >> > plan wizard but I want to be able to replicate the same maintenance
> >> > plan for all the SQL instances in our environment. I want to avoid to=
> >> > manually create them for each and every instance? If possible I want
> >> > to also avoid importing this from other servers, I am looking to see
> >> > if there is a way to script it all.
> >> > Is there a way to deploy the same database maintenance plan for all
> >> > the SQL instances in a automated fashion? What will be the most
> >> > efficient way to accomplish this?
> >> > Any help in this regard will be greatly appreciated.
> >> > Thanks- Hide quoted text -
> >> - Show quoted text -
> > Thank you so much for your response. Besides this product is there any
> > other option to deploy database maintenance plan across different
> > server in SQL 2005... Hide quoted text -
> - Show quoted text -
FWIW - this does work and the only thing that needs to be changed is
the connection. The steps are:
1) Export to dtsx file
2) Open in BIDS
3) Modify the connection to the destination server
4) Import into the destination server
However, this does not import the schedules and can cause problems if
you import over an existing maintenance plan. Once the maintenance
plan has been imported, you still have to open the plan on the
destination server and modify the plan to schedule each sub-plan.
Personally, I have found that it really does not take any longer to
create a new maintenance plan manually than it does to export/modify/
import/update on each destination server.
Jeff|||And everytime you do something manually you run the risk of making an error
or having some setting different on different servers inadvertently. A well
tested script can be configured to set everything right each time for each
server/DB it needs to act against.
Also, you can easily script job schedules too as well as check for existence
of existing job/maintenance plan prior to stomping on it. :-)
Kevin G. Boles
Indicium Resources, Inc.
SQL Server MVP
kgboles a earthlink dt net
"Jeffrey Williams" <jeff.williams@.sharp.com> wrote in message
news:9b46cf7e-7d44-4473-acdc-458d33c7cb15@.e10g2000prf.googlegroups.com...
On Mar 25, 12:54 pm, "Tibor Karaszi"
<tibor_please.no.email_kara...@.hotmail.nomail.com> wrote:
> I guess one could investigate to export the maint plan to a .dtsx file (a
> maint plan is an SSIS
> package after all). And use that dtsx file as base for multi-server
> deployment. Of course, one need
> to investigate how much customization of the dtsx file is needed. For
> instance, you don't want to
> deploy such file to another server if the old server name is in there
> somewhere.
> --
> Tibor Karaszi, SQL Server
> MVPhttp://www.karaszi.com/sqlserver/default.asphttp://sqlblog.com/blogs/tibor_karaszi
>
> "TheSQLGuru" <kgbo...@.earthlink.net> wrote in
> messagenews:13uievj7t0rja8e@.corp.supernews.com...
> > You may be able to generate a script for the plan (not sure about this
> > though) and then execute
> > that script against each server. Seems that most objects in SSMS can be
> > scripted out.
> > I do agree with Andrew that you should consider not using maintenance
> > plans at all and do/control
> > everything with your own scripts.
> > --
> > Kevin G. Boles
> > Indicium Resources, Inc.
> > SQL Server MVP
> > kgboles a earthlink dt net
> > "shub" <shubt...@.gmail.com> wrote in message
> >news:20611010-8c52-4718-982c-4f4400a0b6bc@.s12g2000prg.googlegroups.com...
> > On Mar 24, 10:47 am, "TheSQLGuru" <kgbo...@.earthlink.net> wrote:
> >> Take a look at SQL Farms and see if it can help out.
> >> --
> >> Kevin G. Boles
> >> Indicium Resources, Inc.
> >> SQL Server MVP
> >> kgboles a earthlink dt net
> >> "shub" <shubt...@.gmail.com> wrote in message
> >>news:da1295e1-0f53-4b03-8a70-d3ca9903c812@.d21g2000prf.googlegroups.com...
> >> >I am in the process of depolying a database maintenance plan tasks for
> >> > several servers. I have designed one using the Databases maintenance
> >> > plan wizard but I want to be able to replicate the same maintenance
> >> > plan for all the SQL instances in our environment. I want to avoid to
> >> > manually create them for each and every instance? If possible I want
> >> > to also avoid importing this from other servers, I am looking to see
> >> > if there is a way to script it all.
> >> > Is there a way to deploy the same database maintenance plan for all
> >> > the SQL instances in a automated fashion? What will be the most
> >> > efficient way to accomplish this?
> >> > Any help in this regard will be greatly appreciated.
> >> > Thanks- Hide quoted text -
> >> - Show quoted text -
> > Thank you so much for your response. Besides this product is there any
> > other option to deploy database maintenance plan across different
> > server in SQL 2005... Hide quoted text -
> - Show quoted text -
FWIW - this does work and the only thing that needs to be changed is
the connection. The steps are:
1) Export to dtsx file
2) Open in BIDS
3) Modify the connection to the destination server
4) Import into the destination server
However, this does not import the schedules and can cause problems if
you import over an existing maintenance plan. Once the maintenance
plan has been imported, you still have to open the plan on the
destination server and modify the plan to schedule each sub-plan.
Personally, I have found that it really does not take any longer to
create a new maintenance plan manually than it does to export/modify/
import/update on each destination server.
Jeff|||In addition you may not have the same DB's on each server so unless you
chose it to do all dbs it will fail as well.
--
Andrew J. Kelly SQL MVP
Solid Quality Mentors
"TheSQLGuru" <kgboles@.earthlink.net> wrote in message
news:13uis61kv2i4n92@.corp.supernews.com...
> And everytime you do something manually you run the risk of making an
> error or having some setting different on different servers inadvertently.
> A well tested script can be configured to set everything right each time
> for each server/DB it needs to act against.
> Also, you can easily script job schedules too as well as check for
> existence of existing job/maintenance plan prior to stomping on it. :-)
>
> --
> Kevin G. Boles
> Indicium Resources, Inc.
> SQL Server MVP
> kgboles a earthlink dt net
>
> "Jeffrey Williams" <jeff.williams@.sharp.com> wrote in message
> news:9b46cf7e-7d44-4473-acdc-458d33c7cb15@.e10g2000prf.googlegroups.com...
> On Mar 25, 12:54 pm, "Tibor Karaszi"
> <tibor_please.no.email_kara...@.hotmail.nomail.com> wrote:
>> I guess one could investigate to export the maint plan to a .dtsx file (a
>> maint plan is an SSIS
>> package after all). And use that dtsx file as base for multi-server
>> deployment. Of course, one need
>> to investigate how much customization of the dtsx file is needed. For
>> instance, you don't want to
>> deploy such file to another server if the old server name is in there
>> somewhere.
>> --
>> Tibor Karaszi, SQL Server
>> MVPhttp://www.karaszi.com/sqlserver/default.asphttp://sqlblog.com/blogs/tibor_karaszi
>>
>> "TheSQLGuru" <kgbo...@.earthlink.net> wrote in
>> messagenews:13uievj7t0rja8e@.corp.supernews.com...
>> > You may be able to generate a script for the plan (not sure about this
>> > though) and then execute
>> > that script against each server. Seems that most objects in SSMS can be
>> > scripted out.
>> > I do agree with Andrew that you should consider not using maintenance
>> > plans at all and do/control
>> > everything with your own scripts.
>> > --
>> > Kevin G. Boles
>> > Indicium Resources, Inc.
>> > SQL Server MVP
>> > kgboles a earthlink dt net
>> > "shub" <shubt...@.gmail.com> wrote in message
>> >news:20611010-8c52-4718-982c-4f4400a0b6bc@.s12g2000prg.googlegroups.com...
>> > On Mar 24, 10:47 am, "TheSQLGuru" <kgbo...@.earthlink.net> wrote:
>> >> Take a look at SQL Farms and see if it can help out.
>> >> --
>> >> Kevin G. Boles
>> >> Indicium Resources, Inc.
>> >> SQL Server MVP
>> >> kgboles a earthlink dt net
>> >> "shub" <shubt...@.gmail.com> wrote in message
>> >>news:da1295e1-0f53-4b03-8a70-d3ca9903c812@.d21g2000prf.googlegroups.com...
>> >> >I am in the process of depolying a database maintenance plan tasks
>> >> >for
>> >> > several servers. I have designed one using the Databases maintenance
>> >> > plan wizard but I want to be able to replicate the same maintenance
>> >> > plan for all the SQL instances in our environment. I want to avoid
>> >> > to
>> >> > manually create them for each and every instance? If possible I want
>> >> > to also avoid importing this from other servers, I am looking to see
>> >> > if there is a way to script it all.
>> >> > Is there a way to deploy the same database maintenance plan for all
>> >> > the SQL instances in a automated fashion? What will be the most
>> >> > efficient way to accomplish this?
>> >> > Any help in this regard will be greatly appreciated.
>> >> > Thanks- Hide quoted text -
>> >> - Show quoted text -
>> > Thank you so much for your response. Besides this product is there any
>> > other option to deploy database maintenance plan across different
>> > server in SQL 2005... Hide quoted text -
>> - Show quoted text -
> FWIW - this does work and the only thing that needs to be changed is
> the connection. The steps are:
> 1) Export to dtsx file
> 2) Open in BIDS
> 3) Modify the connection to the destination server
> 4) Import into the destination server
> However, this does not import the schedules and can cause problems if
> you import over an existing maintenance plan. Once the maintenance
> plan has been imported, you still have to open the plan on the
> destination server and modify the plan to schedule each sub-plan.
> Personally, I have found that it really does not take any longer to
> create a new maintenance plan manually than it does to export/modify/
> import/update on each destination server.
> Jeff
>

Wednesday, March 7, 2012

Deploying cube changes to multiple sites

Hi,

How does one deploy cube changes (say adding a new field into a dimension) into multiple customer databases without overwriting their Kpis?

We have a SSAS application which will snap into our existing application and allow customers to define Environmental, Health & Safety Kpis. Each customer will have different Kpis, so how do we deploy incremental updates, without overwriting those Kpis?

I know we can download a customers SSAS database into a new VS project, and copy the Kpis into an XMLA deployment script, but that is a lot of work for each customer.

What I am hoping to find is something like a SQL Script that makes the schema changes, but does not touch the data (Kpis etc.). Of course, my SQL knowledge has only got me into trouble in SSAS, so who knows.

Thanks,

--Phil

Probably the best approach would be to write a script which uses DISCOVER_XML_METADATA to retrieve the cube's metadata, and then changes the XML my injecting your KPIs and then sending this XMLA script inside <Alter> command.

Friday, February 17, 2012

dependencies among views and a table in different databases

Hi everybody.

I need to find all the views that depend on a table in a different database, in order to refresh them once the table is altered.

In the BOL I found the following script that is very useful, but I can't use it if the view and the table are in different database.

Where can I find the dependencies in this case?

Thank you very much.

ms-help://MS.SQLCC.v9/MS.SQLSVR.v9.en/tsqlref9/html/9ce1d07c-ee66-4a83-8c73-cd2cc104dd08.htm

Creating a script that updates all views that have dependencies on a changed object.

USE AdventureWorks; GO SELECT DISTINCT 'EXEC sp_refreshview ''' + name + '''' FROM sys.objects so INNER JOIN sys.sql_dependencies sd ON so.object_id = sd.object_id WHERE type = 'V' AND sd.referenced_major_id = object_id('Person.Contact')

Interesting question.
I have had a similar problem just a few weeks ago, but I have found no way to resolve it...
So it would be interesting to know if it's possible to do that, and how.

Thanks to all

dependencies among views and a table in different databases

Hi everybody.

I need to find all the views that depend on a table in a different database, in order to refresh them once the table is altered.

In the BOL I found the following script that is very useful, but I can't use it if the view and the table are in different database.

Where can I find the dependencies in this case?

Thank you very much.

ms-help://MS.SQLCC.v9/MS.SQLSVR.v9.en/tsqlref9/html/9ce1d07c-ee66-4a83-8c73-cd2cc104dd08.htm

Creating a script that updates all views that have dependencies on a changed object.

USE AdventureWorks; GO SELECT DISTINCT 'EXEC sp_refreshview ''' + name + '''' FROM sys.objects so INNER JOIN sys.sql_dependencies sd ON so.object_id = sd.object_id WHERE type = 'V' AND sd.referenced_major_id = object_id('Person.Contact')

Interesting question.
I have had a similar problem just a few weeks ago, but I have found no way to resolve it...
So it would be interesting to know if it's possible to do that, and how.

Thanks to all

Tuesday, February 14, 2012

Deny Create Database in SQL Server 2000

Hello again, everyone!
I know it's possible to deny users to create databases in SQL Server 2005 by
looking at the server permssions and selecting "Deny" next ot "Create
databases".
I was wondering, is there any way to deny public the ability to create
databases in SQL Server 2000? I can see where you can revoke soem options on
the database level, but not at the instance level.
Thanks in advance!> I know it's possible to deny users to create databases in SQL Server 2005
> by
> looking at the server permssions and selecting "Deny" next ot "Create
> databases".
Users do not have CREATE DATABASE permission unless you GRANT that
permission, either explicitly or by role membership. In SQL 2005, CREATE
DATABASE is implied by CREATE ANY DATABASE and ALTER ANY DATABASE.
Be mindful that DENY and REVOKE are different things. DENY prevents a
previously granted permission from being inherited. When both GRANT and
DENY permissions are present, DENY takes precedence. REVOKE removes all
previous GRANTs and DENYs on the principal so the result is no permissions.
It's usually best to use only GRANTs unless you have a specific reason to do
otherwise.
Hope this helps.
Dan Guzman
SQL Server MVP
"Adam St. Pierre" <AdamStPierre@.discussions.microsoft.com> wrote in message
news:DF656F09-EC02-4C4E-9785-C255CC075706@.microsoft.com...
> Hello again, everyone!
> I know it's possible to deny users to create databases in SQL Server 2005
> by
> looking at the server permssions and selecting "Deny" next ot "Create
> databases".
> I was wondering, is there any way to deny public the ability to create
> databases in SQL Server 2000? I can see where you can revoke soem options
> on
> the database level, but not at the instance level.
> Thanks in advance!|||Thank you, Dan.
As I didn't set up this 2000 instance, some else must have granted
permission. And correct me if I'm wrong, but didn't the default install of
2000 grant permission to everyone, and it's 2005 that you have to grant that
permission explicitly?
And my apologies for my poor choice of wording. I didn't mean "Revoke" as in
the permission setting - I meant the verb, as in to take away. "Deny" would
have been a more descriptive word choice. :D
- Adam
"Dan Guzman" wrote:

> Users do not have CREATE DATABASE permission unless you GRANT that
> permission, either explicitly or by role membership. In SQL 2005, CREATE
> DATABASE is implied by CREATE ANY DATABASE and ALTER ANY DATABASE.
> Be mindful that DENY and REVOKE are different things. DENY prevents a
> previously granted permission from being inherited. When both GRANT and
> DENY permissions are present, DENY takes precedence. REVOKE removes all
> previous GRANTs and DENYs on the principal so the result is no permissions
.
> It's usually best to use only GRANTs unless you have a specific reason to
do
> otherwise.
>
> --
> Hope this helps.
> Dan Guzman
> SQL Server MVP|||> And correct me if I'm wrong, but didn't the default install of
> 2000 grant permission to everyone, and it's 2005 that you have to grant
> that
> permission explicitly?
In SQL 2000, only sysadmin and dbcreator role members have CREATE DATABASE
permission by default.

> And my apologies for my poor choice of wording. I didn't mean "Revoke" as
> in
> the permission setting - I meant the verb, as in to take away. "Deny"
> would
> have been a more descriptive word choice.
Gotcha.
Hope this helps.
Dan Guzman
SQL Server MVP
"Adam St. Pierre" <AdamStPierre@.discussions.microsoft.com> wrote in message
news:8634A52A-D30A-4310-BBD8-6FC2CA316E06@.microsoft.com...[vbcol=seagreen]
> Thank you, Dan.
> As I didn't set up this 2000 instance, some else must have granted
> permission. And correct me if I'm wrong, but didn't the default install of
> 2000 grant permission to everyone, and it's 2005 that you have to grant
> that
> permission explicitly?
> And my apologies for my poor choice of wording. I didn't mean "Revoke" as
> in
> the permission setting - I meant the verb, as in to take away. "Deny"
> would
> have been a more descriptive word choice. :D
> - Adam
>
> "Dan Guzman" wrote:
>