February 25, 2002 at 10:52 am
We recently went thru a process of data migration from an AS\400 system to SQL2000. Since then, we have found a few areas of disconnect. When these areas of disconnect were discovered, those involved would go directly into the tables via Enterprise Mgr and make the change. (only when there is no way thru the front end app to correct).
Our policy now is to only make edits via scripts so that we have records, and so that we can backout. I am getting a lot of pushback from staff because they are unfamiliar with scripting and feel that in some cases, it would be easier to edit directly. Any advise or books to recommend?
February 25, 2002 at 11:02 am
There are ways you could generate scripts without them doing it, but those ways entail a lot of watching or potentially missing changes if multiple people make changes on the app in a short period of time between scripting being done. Having them do it thru script themselves insures that their changes are noted and that knowing what to undo is simpler. Mostly doing this although benneficial to you, your company, and even those developers is still up to you and IMHO I would be adimant that if they want to develope they must submit proper documentation and scripting is easier by far.
"Don't roll your eyes at me. I will tape them in place." (Teacher on Boston Public)
February 25, 2002 at 11:28 am
Scripts allow for testing in a non-production environment. If the script works in development and QA, it should be fine in production. Scripts also ensure consistent application of changes. Anyone can fat-finger when typing. Using scripts reduce the likelihood of human error, though certainly it doesn't eliminate it.
K. Brian Kelley
http://www.sqlservercentral.com/columnists/bkelley/
K. Brian Kelley
@kbriankelley
February 25, 2002 at 11:35 am
It's pretty easy to build a web interface to allow edits. That would allow you to trap the changes.
Alternatively you could get a copy of Log Explorer (see our newsletter or the banner ads). There is a light version for auditing that is not too expensive.
You could implement triggers to to auditing. Not the best choice, but it works.
You could link tables from Access to make it easier, but this doesn't provide an audit trail.
You could schedule, run and archive profiler log files. Could be tough to do through.
Steve Jones
February 25, 2002 at 2:34 pm
A few topics...
1. Database Roles
2. Scripting Standards
3. Change Request Management
4. Source Control
No one should be able to modify the tables directly. Looks like everybody is sa or sysadmin.
You can push back scripting to you developers if there is a standard. The change must only be done if there is a CR #. Check in your code using source control, such as Clearcase or Source Safe with the CR#. As a DBA,you will need to techlead the scripts.
Use a text editor with syntax highlighter such as textpad or Query Analyzer for scripting.
I hope your migration has a test and production phase.
Best of luck...
Viewing 5 posts - 1 through 5 (of 5 total)
You must be logged in to reply to this topic. Login to reply