Diffrence between Production & Development Server ?? 2

[sqldevrequiretektips]

I am totaly new with SQL Server & DTS.

Project i am working on righ now require to Create DTS package which import data from DB2 Sever to SQL Server and run some store procudure which update cetain fields.

So my question is on my computer I have threee SQL Server Register

1 -local
2- For Production
3- for Development

so if i create a DTS Pakage on Local SQL Server and after testing part done how do i transfer DTS package to
production server.

Also I don't know what's diffrent between Production server & Development Server.

Any help really appriciate....

Thanks

ND

 

[checkai]

when you're in your package locally, you can save as...to a different server...

 

[SQLBill]

What do you mean by this:

Also I don't know what's diffrent between Production server & Development Server.

We obviously can't tell you the difference between the two as we don't have access to them. Or do you mean what are Production and a Development servers used for?

If the latter, a Development server is used to test scripts/changes/updates before applying them to a Production server. That way if something 'breaks' the server or database, it won't affect the Production server. Another way to think about is a Development server is a 'practice' or 'test' server and a Production server is the 'real' or 'live' server.

-SQLBill

 

[SQLSister]

Saving it to a diffent sever may or may not do you any good. You will need to change the connections inside the package as well to production. Personally I keep all my DTS packages on development and then use the connection string to specify which server I want to take the data from or send the data to. I also generally import data to development first and make sure it is ok, then send to production, but my imports are on an infrequent schedule, this would not be as practical if the imports were more frequent. Personally I would not consider moving a DTS package until I was familar with exactly what it does, you may not need to move it depending on how it is set-up.

What is the difference between development and production servers? Development servers are used to create structural changes, revised and maintian existing code and create new features. You do development on a development server and then test it there, so you do not risk your existing users being taken down due to a programmer creating a bug while in the process of working something out. Production is the server that users use. In my case, the only people who can change production are my boss and I (and he never does, he had the rights though in case I'm not there.) All developers have create rights to the development server but read only rights on production. This prevents them from making quick fixes on production and bringing down the system by accident or making fixes to production that I don't know about and forgetting to make them to development, therby casuing them to be overwritten when I load a new version from development to production. When it is time to laod a new version to production, dbas typically use some tool (like SQL Compare) to find the objects which don'tt match and overwrite them with the version that is on development. YOu also may need to upload the data from lookup tables on development.

People also frequently send data back from production to development in order to test against recordsets that are siliar in size and data values. Some organizations also have a staging or test server which is set up exactly like the production server and testers use this to fully test new versions inteh environment they will be going to before mcommitting the change to production. This is espcially useful if development is inside the firewall and production is outside it or if the servers are in different domains or have diffent physical set-ups.

Questions about posting. See faq183-874
Click here to learn Ways to help with Tsunami Relief

 

[sqldevrequiretektips]

Thanks for your reply SQLBill

So Now I understand diffrence between production & development.

So, let me tell you more in detail...
I am working on project which is Client server application...(Never Worked on before) Enviroment VB/SQL Server...

So right now all store procudure and new tables which i have designed it's on my local sql server(which register with Main Database) ...so when my project will complete how would I deploy my application how would i transfer my store procudure and Tables to production server...

What are the other aspects i need to be keep in my mind while i do the deployment.....

( Working on project that relize new version of existing pplication )

Please let me know when you get chance....

Thank you so much

ND

 

[SQLBill]

Disclaimer: I've never done anything like that before.

You say you have stored procedures and new tables on you 'development' system. Are these new tables that are to be added to the existing database tables on the 'production' system? Or are they going to replace the current production tables?

Are you just transferring empty tables? Or do the new tables have all the same data as the tables you are replacing?

As I see it there seem to be two steps for you....
1. get the new structure to the production system
2. get the data from the old tables to the new tables.

I would take detach the development database. Copy the .mdf and .ldf files. Move them to the production system and attach them. Then use the copy wizard to copy the data from the original tables to the new tables.

-SQLBill

 

[SQLSister]

Here's what I do. I have a program called SQLCompare. I run it against the two databases and it shows me the differences between the database and then I can choose which objects I want to move and which I do not. You have to carefully select the order to move objects based on foreign key constraints and other things.

Generally I script changes to tables and new tables first. Often I have to do this in one or more groups depending on table relationships. Clearly if two tables have a relationship, steps must be taken to move them in the correct order.) Then I do views (if a view involves a new table, you can't create it until the table exists). Then I do UDFs, then SPs.

After I have made all the object changes, I move data from lookup tables (which I clearly define withthe prefixlkp to make them easier to find) to production lookup tables. Generally I do not need to move any other data, unless I have added a column to an existing table and need to populate it. But if there are any other data changes, I would do them at this time. There is a product called SQLDataCompare which can help with this.

In your case, since you did your work on a local database, I would move everything to the development server first. This will give you practice before you move to development and allow you to ID any problems you might have with order, so you can fix them before going to production. We always upload our changes to a staging server first and connect a staging version of our app to that server and test the heck out of it to make sure we haven't missed anything. Much better to find that someone forgot to set the permissions correctly or didn't move some needed data looking at staging than to disrupt production. When I move to staging, I document everything I moved and in what order. So when I move to production things, almost always go very smoothly because I have worked out any problems in staging first and I have a list of the necessary steps, so I don't forget anything.


Questions about posting. See faq183-874
Click here to learn Ways to help with Tsunami Relief