What would you do?

Ciphon

Ciphon

Ciphon

Associate
Joined
9 Dec 2008
Posts
2,341
Location
Somewhere!
We have a user in our support team who is constantly forgetting his WHERE Clauses in his SQL statements.

He's had all of his access stripped, and for the mean time I've having to check and execute all of his SQL for him. Even though he knows I'm going to be checking for WHERE clauses, he still managed to forget one when sending an UPDATE over to me.

What would you do in this situation? He's worked with us for about a year, passed his probation etc.. There have been talks of disciplinary action, and we're having a meeting to discuss tomorrow.

I've never really delved into the world of triggers, but would it be possible to set up a for insert / delete trigger that checks for a WHERE?

Any other options?
 
This is true... ultimately I doubt he'll be fired over it - but I'm currently having to do my own job as well as effictively doing his.

I'm just trying to think of some options that could be taken to the table / discussed in our meeting tomorrow.
 
I would definately make management aware of it (if they aren't already) and say that it's impacting your performance/productivity. Hopefully then someone will take him aside and have a word.

I don't know your level in the company, but if he's part of your team I would say it's not your problem to come to a solution about him.

Now thats the serious reply out of the way - How the **** can you forget the WHERE clause?? That's the most vital bit? The guy's got to be a complete kermit.
 
How in the world can you forget the WHERE clause? I actually fail to see how you can miss a vital thing like that when you are trying to access certain bits of data O.o
 
I know.. I know.

I'm a data analyst within the company and work along side one other person in this role. We are basically in charge of all data tasks - admin, reporting, SSIS... etc.

I worked with the person in question for about a year in the support team, and he is pretty useless. As mentioned I'm not sure how you can forget a WHERE.

My boss is aware of the situation and we're going to be having a meeting a little later today to discuss how to handle the issue.

Just wondered if anyone had any experience in dealing with someone like this?

I'll let all know the outcome after our meeting in case anyone is ever in a similar situation.
 
The only thing I could suggest is to get him to wrap all his SQL in BEGIN TRAN / ROLLBACK TRAN statements. At least then he can take a look at the number of rows affected before committing the transaction.

However, if he's forgetting his WHERE then I doubt he will remember to do everything in a transaction...
 
What we've done is, give him his Write Access back - but at the same time have asked him not to write any SQL Deletes / Inserts / Updates, and instead use the edit mode. This way he can only ever update one record at a time.

Does anyone know of a way of purely locking him down to write with Edit mode?
 
Thats interesting, I really wouldnt trust someone who always forgot where clauses to be doing anything with a DB.

Its not very tricky to write sql but one of the first things you should learn is that you want to keep backups and that you check your statements before you run them.

Managed to do this once when I was in a mad hurry but realised as soon as I had done it. Never again.

You shouldnt really be babysitting him with something like this, if he is incapable of doing his job then he needs to be sorted out. What is his job? Is he rushed off his feet with a million and one things to think about?
 
Post it on monitor saying "Remember your WHERE clauses ****wit" ?? :D

I agree, after a year and he can't do his job properly, get rid.
 
Ciphon said:
We have a user in our support team who is constantly forgetting his WHERE Clauses in his SQL statements.

He's had all of his access stripped, and for the mean time I've having to check and execute all of his SQL for him. Even though he knows I'm going to be checking for WHERE clauses, he still managed to forget one when sending an UPDATE over to me.

What would you do in this situation? He's worked with us for about a year, passed his probation etc.. There have been talks of disciplinary action, and we're having a meeting to discuss tomorrow.

I've never really delved into the world of triggers, but would it be possible to set up a for insert / delete trigger that checks for a WHERE?

Any other options?
Click to expand...

I would consider retraining him - sounds like he shouldn't be trusted with your live data. I don't know your set-up but have you considered removing automatic commits? Make the process explicit so this individual has to confirm his changes rather than blow everything up straight away. As for triggers as an option to protect against this kind of thing I think this is a bad idea, triggers become hard to trace and eventually you'll be wondering WTF is going on when something happens based on a legacy trigger from the year dot...
 
Teq said:
I don't know your set-up but have you considered removing automatic commits? Make the process explicit so this individual has to confirm his changes rather than blow everything up straight away.
Click to expand...

I had considered this option, but then if he's forgetting to add a where clause, he would surely forget to commit his transactions - thus possibly locking all of our websites users out!
 
I assume you're using a single transaction db by the above statement. Sounds like the guy is a bit of a risk no matter how you play it but at least with manual commits he can't do so much damage without first acknowledging the danger.
 
Retraining him is the first port of call. Hell, asking him (politely) why he keeps forgetting the where clauses is the first.

I'd also address the issue that you have people using raw SQL against a live system. Why isn't an Admin interface/api setup for these tasks?
 
Give him read only access. Pull a report on CPU time per user and show your boss. He's a bad hire, or at least shouldn't be anywhere near a database.
 
You must log in or register to reply here.
Back
Top Bottom