An advice

[meny21]

Hi guys!

We are some guys that are working with Stored Procedures, tables, view and more with SQL Server 7.0.....

We are experience some difficults changing Online Stored Procedures or tables affecting other people.

What do you recommend for us to work with, we need some advices from expert people.....

It is better to use always:
*Set Transactions (Rollback) always?
*Use Access linking SQL Tables?
*Another Server using a copy of our Database?

Thanks for any advice

 

[rac2]

Another Server using a copy of their Database.

I am assuming that you are developers, adding functionality to a live application. Code it and debug it on a development server. The live data is irrelevant, only the structure matters. Then very carefully install one piece at a time on the live system. Be prepared to immediately revert to original version when your new piece causes the whole system to crash and managers to rain down on you like the furies of hell. This is the key, to be able to put the new piece in and to remove it quickly. If you cant do that then you need to schedule down-time to install and test.

Access linked tables would be a lot of aggravation and not provide any advantage. Access linked tables are good for a power user to obtain ad hoc results, or to connect to ODBC databases when you dont have Enterprise Manager.

Rolling back transactions would only save you from wierd data modification statements. If you plan to develop new stored procs as part of a live system, you should convert all of your assets to cash and get out of town before your client finds out.

Well that is my opinion. But there are some real experts on this forum who may have better advice.


Set up a development server.

 

[meny21]

Thanks Rac2, Is good to hear advices and experiences about it... I hope some other experts give us some other good advices too...

 

[SQLSister]

Absolutely, set up a development server. You can do some pretty dumb things while developing, no need to hurt production while you figure it out. In fact I recommend a test server (set up exactly like the production server) as well. First you develop, then you load to test and someone else completely tests the application, then you load to production. SQLCompare is a good tool for identifying the database differnces between production and development. Nothing worse than loading a change and having the production system fail because you forgot one critical item.

Questions about posting. See faq183-874

 

[meny21]

Oki doki SQLSister.... I'll try it

Thanks!!!

 

[ttba]

Meny21,

I Don't remember all of the limitations of SQL 7 but in SQL 2000 you have a couple of options if you are short on $$$. Perhaps SQL 7 has some of these capabilities. I'm sure some other folks can chime in for more info on the differences...

First, you can install multiple instances of SQL 2000 on the same server and use one instance for production and the other instance for development. Alternately, you can also run multiple databases under the same instance - so one could be production and the other could be development. Either way you are running 2 separate databases.

Just be sure to keep track which one you are connected to at any given time...

Access Projects (.adp/.ade) are also very nice for generating stuff quick (tables, sp's, views, etc). No need for adhoc linking of tables unless you are pulling data in from multiple sources. It is also easy to change back and forth between db's, copy/paste procedures, etc.

Hope this helps.
ttba

 

[meny21]

Excelent ttba, this is going to help us too!!!

Meny21