April 13, 2007 at 5:10 pm
Thanks for the comments and that's a great idea for 10 ways to get promoted. I'll work on that one. Not sure I have 10 ways, but I have a few!
April 16, 2007 at 3:28 am
Steve - excellent article. I've managed to learn most of the things you talk about but struggle with tuning. Do you have any suggestions for learning the fundamentals of tuning?
January 8, 2008 at 7:24 am
I agree with your list and found a few areas where I could improve. But, I also agree that more people get fired or not hired for interpersonal reasons than technical. In corporate IT, "playing well with others" is a higher skill than being a technical wizard. Is that true or untrue for IT employment at hardware or software firms?
January 8, 2008 at 8:52 am
I'm not sure many people are fired for "interpersonal reasons". They might be let go first in a layoff, but there are plenty of people that no one likes or that don't get along with others and they're not fired from their jobs. I would think in the US that "I don't like you" is not a good reason for HR to allow you to fire someone. Too easy to claim discrimination.
Now if you don't get along and don't do your job....watch out.
January 8, 2008 at 2:03 pm
I was pushed to resign myself because my manager and I did not get along. One example he wanted to use trigger to insert data into the one main table by multiple input tables. I told him it would not work. Sure enough it had a dead lock the next day. Instead of changing the way of inserting data, he told everyone to put in NOLOCK in every select statement. He did not like me because I disagreed with him even for a good reason. He even told me not to do any research on web site or read any book.
Yes you can lose your job for interpersonal reason, it does not matter you are good doing your job or not.
March 16, 2008 at 10:28 pm
Nice article. In the GIS world, DBA work sometimes gets watered down with all of the other aspects and issues involved. This article was just what I needed to provide some focus to showing the ropes to a new DBA.
Instilling the right attitude has been my main focus but your 10 points provide a good jumping off point for the "nitty-gritty" of DBA work; stuff I could probably recall if pressed but since you laid it out so nicely, I'm going to use it.
Thanks for encapsulating these key issues for both the student and the working DBA.
Cheers.
May 20, 2008 at 9:50 am
PLEASE HELP:
Speaking of loosing a job, I'm a junior level programmer and if I don't get the following issue figured out quickly - I might be in danger of this also,
I AM TRYING TO USE THE FOLLOWING SCRIPT TO :
1. FOR EACH TABLE IN A GIVEN DATABASE (I am using a cursor for this)
2. FIND IF A COLUMN OF NAME "row_id" exists
3. IF it does, delete it
4. if it doesn't, proceed to next table
Right now I am getting error messages when it comes to a table where the column does not exist, it simply stops because the drop statement fails - what am I doing wrong ???????????????????????????
code:
--ALTER TABLES SCRIPT
--change the line marked *** to suit your update needs....
IF EXISTS (SELECT *
FROM sysobjects o WITH(NOLOCK),
syscolumns b WITH(NOLOCK)
WHERE o.[id] = b.[id] AND b.name = 'row_id'
AND O.name = ''+o.name)
BEGIN
DECLARE tableNamesCursor CURSOR
FOR
--***
--select 'ALTER TABLE ['+ o.name+ '] ADD row_id as '+o.name+'+'ID'
-- CONSTRAINT AddDateDflt'+ cast(o.id as varchar(10))+ ' DEFAULT getdate() WITH VALUES'
-- removes the TimeStamp column, and constraint from all tables
select 'ALTER TABLE ['+ o.name+ '] DROP COLUMN row_id'
from sysobjects o, sysindexes i
where i.id = o.id
and indid in(0,1)
and o.name not like 'sys%'
and o.name not like 'dt%'
order by o.name
OPEN tableNamesCursor
DECLARE @alterTableSql nvarchar(400)
FETCH NEXT FROM tableNamesCursor INTO @alterTableSql
WHILE (@@FETCH_STATUS <> -1)
BEGIN
IF (@@FETCH_STATUS <> -2)
BEGIN
print @alterTableSql
exec sp_executesql @alterTableSql
END
FETCH NEXT FROM tableNamesCursor INTO @alterTableSql
END
CLOSE tableNamesCursor
DEALLOCATE tableNamesCursor
END
Post #503824
May 20, 2008 at 9:52 am
I'd also learn about running your SQL services under an account that is not a member of the Administrator group on your server.
If you're running SQL 2000 its not easy, as it means a lot of specific permissions assignment, but its far easier under 2005 - just make sure the service account has normal user permissions when you do the install.
Then you just assign permissions for extra folders as needed (eg external backup files to the service account). Its what the MS training material calls "Principle of Least Privilege" - ie only run with the permissions you need.
Running SQL Server under Local System should be another cause of immediate dismissal for a DBA.
July 14, 2008 at 4:12 am
I found this article today. Its very good.
Thanks,
Sreeju
Viewing 9 posts - 46 through 53 (of 53 total)
You must be logged in to reply to this topic. Login to reply