Deployment Question - problem with datasources...

Hi,
We have written a number of reports we would like to move to our Integration/Test Servers.
These reports, which access a Linked Informix database through a System ODBC DSN, work fine on
my development XP machine with a local MS SQL Server 2000.
Our Integration/Test system consists of:
- a MS SQL Server 2000 Server running on NT. On this box we created an ODBC DSN just like that on development.
- an IIS ASP.NET machine with .NET 1.1 Framework.
[Note: We did not install Report Manager and plan to access our Reports by URL.]
Problem: After modifying the ReportingServices Datasource to use our integration/test server, building,
then deploying to the target server we are getting the following error:
ERROR [IM002] [Microsoft][ODBC Driver Manager] Data source name not found and no default driver specified

Has anyone encountered this problem? And if so, what did you do to fix it? Many Thanks for any ideas!
So how did you install Reporting Services on your integration/testing server? This error happens when viewing the report using a URL? Can you access it through the RS web services?

Deployment on load balanced servers.

Hi, I'm trying to solve the problem with deploying sql code on load-balanced application server.
Normally when we put new feature\fix live we take one server out of the loop, than we put new app code, we test it and then we bring it back to the loop. But we've started to have a problem when we had to change stored procedures at the same time to run the new app code, becouse either 'test' server won't work either production application won't work. I wonder is there any good solution for this problem.

Regards
Piotr.
P.S. Sorry for the forum topic but I didn't know where to put it.

what I understand is that your stored procedure signature is still the same but its implementation is changed in such a way that only the new application code can work with it. Your configuration is mulitple application servers talking to 1 SQL Server. In that case, let us say you have 10 application servers. I will take 5 (let us call them group-A) of those out of the loop, install new app code. Note, your app is still up and running though at 1/2 the capacity. you can test your group-A with another SQL Server (say the test SQL Server that has new stored procs). Once it is done, you can take other group of app servers offline (this will cause short term unavailability of your application), change the stored proc on the production SQL Server, and then bring group-A online. Now you can do the same with other set of application servers.

|||That was very helpful, but I'm more after stored procedure versioning solution. Sometimes we need old and new code running (part of requests are hitting old and other new code). Thanks in advance.|||http://weblogs.asp.net/fmarguerie/archive/2003/02/24/2880.aspx fyi.sql

Deployment Error

After creating a my project which has several dts packages.

I want to deploy and place them in different sql servers to run automatically.

I do the following:

After building my project.I select project ->properties ->deployment utility->i set create deployment to true.

Then within deployment folder i double click .projectdeploymentmanifest file

where package installation i select sql server instead of file system.

and i get the following error.

TITLE: Package Installation Wizard

Could not save the package "C:\Program Files\Microsoft SQL Server\SSIS\bin\Deployment\Procedure.dtsx" to SQL Server "SQL-DEV".

ADDITIONAL INFORMATION:

The SaveToSQLServer method has encountered OLE DB error code 0x80004005 (Client unable to establish connection). The SQL statement that was issued has failed.

The SaveToSQLServer method has encountered OLE DB error code 0x80004005 (Client unable to establish connection). The SQL statement that was issued has failed.

BUTTONS:

OK

It would be great if some one guides me with this.Is this anything to deal with security.please let me know

Open up Management Studio and try to connect to "Integration Services" on SQL-DEV.|||

It says Access Denied.

Do i need to be under sysadmin role to do this?

Please let me know.

Thanks

|||

See this link from my blog:

http://www.ssistalk.com/2007/04/13/ssis-access-is-denied-when-connection-to-remote-ssis-service/

|||

I have worked with the steps from this site.I still have the same problem.

Access denied when i connect to integration services on a particular server from i local machine.

Do i have any other options?

|||The answers are all right there, but need to be done on the server, not the local machine.|||

Thanks,I was working on my local machine instead of server.

Deploying SSIS pkgs

Hi,

I have some questions.

Regarding SQL Server deployment, it says to use this option if sharing packages between servers. Does this mean sharing packages between development, test, and production environments? Or just sharing among production servers?

That is, I am trying to determine if I should deploy my packages on SQL Server, or just store them on the local file system. These packages will NOT be used on any other production server. So should I just keep them on the file system?

Another question. I see that I have a package stored in the "sysdtspackages90" table in the msdb database. Since I have not done any SQL Server deployment yet, I don't understand how this particular package ended up in this table. Is it OK to remove? I think this is a previous version of a package that I have since re-written. Are there any dependencies on this "sysdtspackages90" table that I should be aware of?

Thanks!

Sharing between servers, in this case, refers to sharing between production servers. So you're probably fine sticking with the file system.

Not 100% sure about dependencies on the sysdtspackages90, but if you remove it by connecting to the Integration Service in SSMS, it should be fine.

|||

Thanks for your reply!

Is there any advantage whatsoever for deploying to SQL Server if you are not sharing packages?

Also, where do I delete the package stored in the "syspackages90" (or whatever it's called) table... I have another package by the very same name stored in the file system. But I don't think they are the same package. Is that possible?

|||

Opinion varies - personally I prefer the file system, because I find it easier to deploy there.

To delete the package, connect SSMS to the Integration Services on the server you are working on. It's one of the Server Type options when you choose File..Connect Object Explorer. You should be able to browse to the package from there.

|||As John indicates, opinions do vary. I for one love deploying to MSDB because I get to use SQL Server roles and security to control access to my packages and in my packages. So once I set up a user account in a connection inside of a package, I don't have to worry about SSIS stripping the password off of that connection when I deploy. A nice feature, I should say, and probably the method that was envisioned as being "standard." (I don't know that for sure, it's just a guess, what with all of the integration that MS tries to achieve.)|||

Thank you for your reply. Yes, that makes sense.

However, I am a little nervous about deploying to SQL Server - for one, I've never done it. Are there any caveats I need to be aware of? For example, what if I need to change something? Do I need to "re-deploy" if any of the packages change? Or are the changes saved to SQL Server automatically when changes to the packages are saved?

Also, what is this "magic folder" (the folder where dependent files go) Is there a "standard" place for this folder? My book on SSIS mentions it, but does not indicate where to put it.

One more thing, I am clueless about configuration files. Are these important? I realize this is a vague question. But the packages I am working on now are tested and working... they are not going to be migrated anywhere. So should I bother with a configuration file? That is, when would I need a configuration file?

Thanks much!

|||I will try this, thanks

Deploying SSIS pkgs

Hi,

I have some questions.

Regarding SQL Server deployment, it says to use this option if sharing packages between servers. Does this mean sharing packages between development, test, and production environments? Or just sharing among production servers?

That is, I am trying to determine if I should deploy my packages on SQL Server, or just store them on the local file system. These packages will NOT be used on any other production server. So should I just keep them on the file system?

Another question. I see that I have a package stored in the "sysdtspackages90" table in the msdb database. Since I have not done any SQL Server deployment yet, I don't understand how this particular package ended up in this table. Is it OK to remove? I think this is a previous version of a package that I have since re-written. Are there any dependencies on this "sysdtspackages90" table that I should be aware of?

Thanks!

Sharing between servers, in this case, refers to sharing between production servers. So you're probably fine sticking with the file system.

Not 100% sure about dependencies on the sysdtspackages90, but if you remove it by connecting to the Integration Service in SSMS, it should be fine.

|||

Thanks for your reply!

Is there any advantage whatsoever for deploying to SQL Server if you are not sharing packages?

Also, where do I delete the package stored in the "syspackages90" (or whatever it's called) table... I have another package by the very same name stored in the file system. But I don't think they are the same package. Is that possible?

|||

Opinion varies - personally I prefer the file system, because I find it easier to deploy there.

To delete the package, connect SSMS to the Integration Services on the server you are working on. It's one of the Server Type options when you choose File..Connect Object Explorer. You should be able to browse to the package from there.

|||As John indicates, opinions do vary. I for one love deploying to MSDB because I get to use SQL Server roles and security to control access to my packages and in my packages. So once I set up a user account in a connection inside of a package, I don't have to worry about SSIS stripping the password off of that connection when I deploy. A nice feature, I should say, and probably the method that was envisioned as being "standard." (I don't know that for sure, it's just a guess, what with all of the integration that MS tries to achieve.)|||

Thank you for your reply. Yes, that makes sense.

However, I am a little nervous about deploying to SQL Server - for one, I've never done it. Are there any caveats I need to be aware of? For example, what if I need to change something? Do I need to "re-deploy" if any of the packages change? Or are the changes saved to SQL Server automatically when changes to the packages are saved?

Also, what is this "magic folder" (the folder where dependent files go) Is there a "standard" place for this folder? My book on SSIS mentions it, but does not indicate where to put it.

One more thing, I am clueless about configuration files. Are these important? I realize this is a vague question. But the packages I am working on now are tested and working... they are not going to be migrated anywhere. So should I bother with a configuration file? That is, when would I need a configuration file?

Thanks much!

|||I will try this, thanks

Deploying SMO/RMO Applications to non-sql2005 servers.

Hi All,
Is it possible to deploy smo/rmo applications to servers and clients without installing the sql server 2005 client tools? Can I simply include the used assenblies or is there any dependance on some ActiveX objects or other configuration actions that must be performed for SMO/RMO to work?
regards,
Tore Birkeland
Yes, it is possible to deploy SMO/RMO applications without installing SQL Server 2005 client tools. The SQL Server 2005 RTM will include SMO redist setup file that you can use for your SMO-based applications. SMO relies on .NET Framework 2.0 and SQL Native Client.

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

Deploying Report Server behind web servers

We'd like to deploy our report servers behind our web tier in the app tier
in order to prevent our clients from being able to use url access directly.
My main concern has to do with a chance that a client may attempt to alter
the content of report parameters or otherwise probe around.
Our web code is able to forward requests to the report server and render
reports correctly, but toolbar functionality seems to be broken. The web
developer tells me that the toolbar functionality is too stateful, so
paging (as an example) won't work.
Is what we're trying to do (request forwarding) unsupported? Are my fears
regarding exposing the report server in our DMZ unwarranted? If so, I must
be missing something.What about building your own interfaace or getting the Report Stream from
Reporting Webservice to Qrite the Stream to the browser ? There you could
lock down your reporting server and connect to the RS with special lockedup
credentials.
HTH, Jens Suessmeyer.
--
http://www.sqlserver2005.de
--
"JoeA" <joea@.nospam.net> schrieb im Newsbeitrag
news:Xns963D69BAFC14Emailmailcom@.207.46.248.16...
> We'd like to deploy our report servers behind our web tier in the app tier
> in order to prevent our clients from being able to use url access
> directly.
> My main concern has to do with a chance that a client may attempt to alter
> the content of report parameters or otherwise probe around.
> Our web code is able to forward requests to the report server and render
> reports correctly, but toolbar functionality seems to be broken. The web
> developer tells me that the toolbar functionality is too stateful, so
> paging (as an example) won't work.
> Is what we're trying to do (request forwarding) unsupported? Are my fears
> regarding exposing the report server in our DMZ unwarranted? If so, I
> must
> be missing something.|||Thanks for the reply. We have considered that - however we didn't want to
have to recreate all of the goodies in the toolbar.
"Jens Süßmeyer" <Jens@.Remove_this_For_Contacting.sqlserver2005.de> wrote
in news:#1t7uEQRFHA.2136@.TK2MSFTNGP14.phx.gbl:
> What about building your own interfaace or getting the Report Stream
> from Reporting Webservice to Qrite the Stream to the browser ? There
> you could lock down your reporting server and connect to the RS with
> special lockedup credentials.
> HTH, Jens Suessmeyer.
> --
> http://www.sqlserver2005.de
> --
>

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
>

Deploying a database to multiple servers - smooth sailing?

Hello,
I need to copy a database to multiple servers, all of this using SQL Server
2000. -- this will enable the testing of an application with identical
databases. I'm concerned here with the original installation of the database
on the target servers and subsequent updates using restoration of the
database from the master server
I'm contemplating having the master database on one server and using data
management objects to make a database backup on that machine. That backed-up
database would be placed in a share with some scripts that would perform the
restore on the target servers - to be initiated by the users.
This works well on my master server but can I expect a smooth distribution
using this approach or is there a better approach. I like this method as
it's simple. The target servers will all be SQL Server 2000, possibly with
different service patches. The target servers would has the same local
administrators account.
Is there anything internal to the back up or the target server that would
prevent this operation? There's no dependencies such as a database can only
be restored to a server it was backed up on, is there?
TIA,
Rod
> This works well on my master server but can I expect a smooth distribution
> using this approach or is there a better approach. I like this method as
> it's simple. The target servers will all be SQL Server 2000, possibly
> with
> different service patches. The target servers would has the same local
> administrators account.
Your servers should all be at the same patch level. Occassionally, there
are differences in the structure of the backup that are not backward
compatible.

> Is there anything internal to the back up or the target server that would
> prevent this operation? There's no dependencies such as a database can
> only
> be restored to a server it was backed up on, is there?
No.
|||Thank you
"Scott Morris" wrote:

> Your servers should all be at the same patch level. Occassionally, there
> are differences in the structure of the backup that are not backward
> compatible.
>
> No.
>
>

Deploying a database to multiple servers - smooth sailing?

Hello,
I need to copy a database to multiple servers, all of this using SQL Server
2000. -- this will enable the testing of an application with identical
databases. I'm concerned here with the original installation of the database
on the target servers and subsequent updates using restoration of the
database from the master server
I'm contemplating having the master database on one server and using data
management objects to make a database backup on that machine. That backed-up
database would be placed in a share with some scripts that would perform the
restore on the target servers - to be initiated by the users.
This works well on my master server but can I expect a smooth distribution
using this approach or is there a better approach. I like this method as
it's simple. The target servers will all be SQL Server 2000, possibly with
different service patches. The target servers would has the same local
administrators account.
Is there anything internal to the back up or the target server that would
prevent this operation? There's no dependencies such as a database can only
be restored to a server it was backed up on, is there?
TIA,
Rod> This works well on my master server but can I expect a smooth distribution
> using this approach or is there a better approach. I like this method as
> it's simple. The target servers will all be SQL Server 2000, possibly
> with
> different service patches. The target servers would has the same local
> administrators account.
Your servers should all be at the same patch level. Occassionally, there
are differences in the structure of the backup that are not backward
compatible.
> Is there anything internal to the back up or the target server that would
> prevent this operation? There's no dependencies such as a database can
> only
> be restored to a server it was backed up on, is there?
No.|||Thank you
"Scott Morris" wrote:
> > This works well on my master server but can I expect a smooth distribution
> > using this approach or is there a better approach. I like this method as
> > it's simple. The target servers will all be SQL Server 2000, possibly
> > with
> > different service patches. The target servers would has the same local
> > administrators account.
> Your servers should all be at the same patch level. Occassionally, there
> are differences in the structure of the backup that are not backward
> compatible.
> > Is there anything internal to the back up or the target server that would
> > prevent this operation? There's no dependencies such as a database can
> > only
> > be restored to a server it was backed up on, is there?
> No.
>
>

Deploying a database to multiple servers - smooth sailing?

Hello,
I need to copy a database to multiple servers, all of this using SQL Server
2000. -- this will enable the testing of an application with identical
databases. I'm concerned here with the original installation of the databas
e
on the target servers and subsequent updates using restoration of the
database from the master server
I'm contemplating having the master database on one server and using data
management objects to make a database backup on that machine. That backed-u
p
database would be placed in a share with some scripts that would perform the
restore on the target servers - to be initiated by the users.
This works well on my master server but can I expect a smooth distribution
using this approach or is there a better approach. I like this method as
it's simple. The target servers will all be SQL Server 2000, possibly with
different service patches. The target servers would has the same local
administrators account.
Is there anything internal to the back up or the target server that would
prevent this operation? There's no dependencies such as a database can only
be restored to a server it was backed up on, is there?
TIA,
Rod> This works well on my master server but can I expect a smooth distribution
> using this approach or is there a better approach. I like this method as
> it's simple. The target servers will all be SQL Server 2000, possibly
> with
> different service patches. The target servers would has the same local
> administrators account.
Your servers should all be at the same patch level. Occassionally, there
are differences in the structure of the backup that are not backward
compatible.

> Is there anything internal to the back up or the target server that would
> prevent this operation? There's no dependencies such as a database can
> only
> be restored to a server it was backed up on, is there?
No.|||Thank you
"Scott Morris" wrote:

> Your servers should all be at the same patch level. Occassionally, there
> are differences in the structure of the backup that are not backward
> compatible.
>
> No.
>
>

deploy Service pack remotely

How can we deploy SP3a remotely on all our SQL servers ? Is this doable ? Is
there step by step instructions on how to do so and also verify remotely
once completed that it was successful
ThanksI suppose SMS could do this.
You might also try software policies for the Operating System... For
Software policy, that would be doc'c with the operating system and not SQL..
--
Wayne Snyder, MCDBA, SQL Server MVP
Computer Education Services Corporation (CESC), Charlotte, NC
www.computeredservices.com
(Please respond only to the newsgroups.)
I support the Professional Association of SQL Server (PASS) and it's
community of SQL Server professionals.
www.sqlpass.org
"Hassan" <fatima_ja@.hotmail.com> wrote in message
news:O4Dom6RyDHA.560@.TK2MSFTNGP11.phx.gbl...
> How can we deploy SP3a remotely on all our SQL servers ? Is this doable ?
Is
> there step by step instructions on how to do so and also verify remotely
> once completed that it was successful
> Thanks
>|||By the way, you might also try a login script which runs the setup...
--
Wayne Snyder, MCDBA, SQL Server MVP
Computer Education Services Corporation (CESC), Charlotte, NC
www.computeredservices.com
(Please respond only to the newsgroups.)
I support the Professional Association of SQL Server (PASS) and it's
community of SQL Server professionals.
www.sqlpass.org
"Hassan" <fatima_ja@.hotmail.com> wrote in message
news:O4Dom6RyDHA.560@.TK2MSFTNGP11.phx.gbl...
> How can we deploy SP3a remotely on all our SQL servers ? Is this doable ?
Is
> there step by step instructions on how to do so and also verify remotely
> once completed that it was successful
> Thanks
>

Deploy apps using sql 2005 express

i'm building apps using sql server express and I want to deploy to servers that have the 2.0 .net framework but have sql server 2000 database.

Can this be done, and if so, how?

Observing God’s Holy Spirit, I see God saying that The Lord Jesus influences every natural occurrence of kindness, righteousness, and judgment _{(Jeremiah 9:23-24)}. I believe God, so I thank The Lord Jesus for your grace in these matters.

The database format used by SQL 2005 is not compatible with that used in SQL 2000, so you can't deploy the database by copying and attaching the mdf file to the deployed server.

You could deploy your application by using scripts to create your database on the target server. The Embedding SQL Express white paper discusses one way to do this.

|||

WHy do you want to develop in a much higher version of SQL Server for deploying it to an older version of SQL Server ? I am a developer on my own, and I never would do that due to compability issues. YOu can either use the developer edition for developing of SQL 2000 or the msde which would give you in most cases the same results that you will have like on the deployed system.

HTH, Jens Suessmeyer.

http://www.sqlserver2005.de

|||

I'm experimenting with the new Microsoft express technologies, but my production hosting company has not yet upgraded to sql server 2005, but is still using sql server 2000. I found information that leads me to understand that the visual web developer express edition does not support any database except sql server 2005 express. So, I tried this new MS tech that did not work on the old servers.

Nevertheless, by the faith of The Lord Jesus, I thank The Lord Jesus for His kindness to me by the information you provided . And, by God's grace thru Christ Jesus, I'm a improved person after trying something different. Perhaps, you will find similar satisfaction in God's mercy through Christ Jesus if you did things that you thought you would never do.

Best Wishes