September 27, 2016 at 5:42 am
Brandie Tarvin (9/27/2016)
SET RANT Brandie ON;I just spent the past week working on a bug fix to get into our production systems before month end. Last night, after I leave for the day, the BU user testing this decided to complain about "bugs" that aren't even related to the bug fix. X item isn't working, therefore I need to investigate.
Like a good tech support dooby, I do the due diligence. What do you know? The code is working the way it's been working for 3 years. The way the original business rules stated it should work. Why is this issue coming up now? And why doesn't the user remember the rules he helped write?
Why is it incumbent upon me to remember the business rules for processes and to teach the users the rules every time they decide something isn't working? It would be different if the user was someone new to the company, but still HE WROTE THE RULES.
I suppose it's a form of job security, but if I could spend all the time I use researching and pushing back on the user about business rule confusion doing other work, I'd have enough time to complete upcoming projects and automation of processes.
SET RANT Brandie OFF;
I assure you that you are not alone in having to do this!
If you haven't even tried to resolve your issue, please don't expect the hard-working volunteers here to waste their time providing links to answers which you could easily have found yourself.
September 27, 2016 at 6:17 am
Phil Parkin (9/27/2016)
Brandie Tarvin (9/27/2016)
SET RANT Brandie ON;I just spent the past week working on a bug fix to get into our production systems before month end. Last night, after I leave for the day, the BU user testing this decided to complain about "bugs" that aren't even related to the bug fix. X item isn't working, therefore I need to investigate.
Like a good tech support dooby, I do the due diligence. What do you know? The code is working the way it's been working for 3 years. The way the original business rules stated it should work. Why is this issue coming up now? And why doesn't the user remember the rules he helped write?
Why is it incumbent upon me to remember the business rules for processes and to teach the users the rules every time they decide something isn't working? It would be different if the user was someone new to the company, but still HE WROTE THE RULES.
I suppose it's a form of job security, but if I could spend all the time I use researching and pushing back on the user about business rule confusion doing other work, I'd have enough time to complete upcoming projects and automation of processes.
SET RANT Brandie OFF;
I assure you that you are not alone in having to do this!
DBA=Doing Bout Anything
Michael L John
If you assassinate a DBA, would you pull a trigger?
To properly post on a forum:
http://www.sqlservercentral.com/articles/61537/
September 27, 2016 at 6:35 am
Michael L John (9/27/2016)
Phil Parkin (9/27/2016)
Brandie Tarvin (9/27/2016)
SET RANT Brandie ON;I just spent the past week working on a bug fix to get into our production systems before month end. Last night, after I leave for the day, the BU user testing this decided to complain about "bugs" that aren't even related to the bug fix. X item isn't working, therefore I need to investigate.
Like a good tech support dooby, I do the due diligence. What do you know? The code is working the way it's been working for 3 years. The way the original business rules stated it should work. Why is this issue coming up now? And why doesn't the user remember the rules he helped write?
Why is it incumbent upon me to remember the business rules for processes and to teach the users the rules every time they decide something isn't working? It would be different if the user was someone new to the company, but still HE WROTE THE RULES.
I suppose it's a form of job security, but if I could spend all the time I use researching and pushing back on the user about business rule confusion doing other work, I'd have enough time to complete upcoming projects and automation of processes.
SET RANT Brandie OFF;
I assure you that you are not alone in having to do this!
DBA=Doing Bout Anything
Brandie, Phil is absolutely right - you aren't alone. Better yet, when the "official business rule documentation" that the BU wrote is wrong and horribly out of date, it's our fault when production code doesn't do what their documentation says it should do. The fact that they're the ones who requested the 35 changes and didn't document it is immaterial.
Another meaning for DBA is Default Blame Acceptor, so the fact that other people don't maintain their documentation is clearly our fault.
September 27, 2016 at 7:18 am
Ed Wagner (9/27/2016)
Michael L John (9/27/2016)
Phil Parkin (9/27/2016)
Brandie Tarvin (9/27/2016)
SET RANT Brandie ON;I just spent the past week working on a bug fix to get into our production systems before month end. Last night, after I leave for the day, the BU user testing this decided to complain about "bugs" that aren't even related to the bug fix. X item isn't working, therefore I need to investigate.
Like a good tech support dooby, I do the due diligence. What do you know? The code is working the way it's been working for 3 years. The way the original business rules stated it should work. Why is this issue coming up now? And why doesn't the user remember the rules he helped write?
Why is it incumbent upon me to remember the business rules for processes and to teach the users the rules every time they decide something isn't working? It would be different if the user was someone new to the company, but still HE WROTE THE RULES.
I suppose it's a form of job security, but if I could spend all the time I use researching and pushing back on the user about business rule confusion doing other work, I'd have enough time to complete upcoming projects and automation of processes.
SET RANT Brandie OFF;
I assure you that you are not alone in having to do this!
DBA=Doing Bout Anything
Brandie, Phil is absolutely right - you aren't alone. Better yet, when the "official business rule documentation" that the BU wrote is wrong and horribly out of date, it's our fault when production code doesn't do what their documentation says it should do. The fact that they're the ones who requested the 35 changes and didn't document it is immaterial.
Another meaning for DBA is Default Blame Acceptor, so the fact that other people don't maintain their documentation is clearly our fault.
You'll also be the one blamed for requiring people to follow the procedure to get something they want, even if you had no hand in the creation of said procedure.
You want to be able to create an Agent job to do something? Here's where you go to put in the request for that access, which leads to the "you're keeping me from getting my work done by not just giving me what I want when I want it."
I've got one developer that's my personal thorn for this, I'd *love* to see him work with Jeff Moden, see how long before Jeff hits him with a porkchop...
:hehe:
September 27, 2016 at 8:01 am
Ed Wagner (9/27/2016)
Michael L John (9/27/2016)
Phil Parkin (9/27/2016)
Brandie Tarvin (9/27/2016)
SET RANT Brandie ON;I just spent the past week working on a bug fix to get into our production systems before month end. Last night, after I leave for the day, the BU user testing this decided to complain about "bugs" that aren't even related to the bug fix. X item isn't working, therefore I need to investigate.
Like a good tech support dooby, I do the due diligence. What do you know? The code is working the way it's been working for 3 years. The way the original business rules stated it should work. Why is this issue coming up now? And why doesn't the user remember the rules he helped write?
Why is it incumbent upon me to remember the business rules for processes and to teach the users the rules every time they decide something isn't working? It would be different if the user was someone new to the company, but still HE WROTE THE RULES.
I suppose it's a form of job security, but if I could spend all the time I use researching and pushing back on the user about business rule confusion doing other work, I'd have enough time to complete upcoming projects and automation of processes.
SET RANT Brandie OFF;
I assure you that you are not alone in having to do this!
DBA=Doing Bout Anything
Brandie, Phil is absolutely right - you aren't alone. Better yet, when the "official business rule documentation" that the BU wrote is wrong and horribly out of date, it's our fault when production code doesn't do what their documentation says it should do. The fact that they're the ones who requested the 35 changes and didn't document it is immaterial.
Another meaning for DBA is Default Blame Acceptor, so the fact that other people don't maintain their documentation is clearly our fault.
That's when it's a good time to have solid consistent support from above.
The Business needs to be held accountable for the spec.
And understand you are following what was agreed upon.
If they need a change in design, it is a change or enhancement.
Very different from a bug fix.
When you mention BU, it implies code shared by all.
It could be 1 BU seems to have a different opinion of how it should work, which may not be shared.
I'd assume that there is an owner of the spec, not a BU tester, who can add clarity to the picture.
You verified the programming worked as designed.
Maybe you could offer to look at their testing scenarios to see why this was not discovered several years ago.
When we pushed back on changes, specs became more defined, testing was improved, and rework dropped.
Which was a win for all.
September 27, 2016 at 8:25 am
Greg Edwards-268690 (9/27/2016)
You verified the programming worked as designed.Maybe you could offer to look at their testing scenarios to see why this was not discovered several years ago.
Ha. He just agreed that the code was supposed to be doing what it did, but said that it should have reported in our QA September month end process because a certain date read 9/1 on the data in question, therefore my code was wrong.
I pointed out that our QA August month end process ran from August to September 6th, so yeah, the code is working correctly and the only reason it looks wrong is because we do our month ends in UAT based on the needs of testing, not on the usual calendar month end dates we have in production. Which means usually we fast track (running several month ends only days apart) but in this case, it was a "catchup" kind of situation.
We'll see if he continues to push back.
September 27, 2016 at 9:38 am
Brandie Tarvin (9/27/2016)
Greg Edwards-268690 (9/27/2016)
You verified the programming worked as designed.Maybe you could offer to look at their testing scenarios to see why this was not discovered several years ago.
Ha. He just agreed that the code was supposed to be doing what it did, but said that it should have reported in our QA September month end process because a certain date read 9/1 on the data in question, therefore my code was wrong.
I pointed out that our QA August month end process ran from August to September 6th, so yeah, the code is working correctly and the only reason it looks wrong is because we do our month ends in UAT based on the needs of testing, not on the usual calendar month end dates we have in production. Which means usually we fast track (running several month ends only days apart) but in this case, it was a "catchup" kind of situation.
We'll see if he continues to push back.
We went by a fiscal calendar.
Took some awhile to adjust vs. calendar month.
Was always interesting when they presented data to management.
They were very good at picking this out.
September 27, 2016 at 3:31 pm
Okay, is it just me? I've seen two different people post sample data where the datetime data is given in hex and converted to datetime. It's not like the datetime data is sensitive, and it certainly isn't human legible.
Drew
J. Drew Allen
Business Intelligence Analyst
Philadelphia, PA
September 27, 2016 at 3:49 pm
drew.allen (9/27/2016)
Okay, is it just me? I've seen two different people post sample data where the datetime data is given in hex and converted to datetime. It's not like the datetime data is sensitive, and it certainly isn't human legible.Drew
Particularly when there are only 2 columns of data, an ID and the datetime.
September 27, 2016 at 3:50 pm
drew.allen (9/27/2016)
Okay, is it just me? I've seen two different people post sample data where the datetime data is given in hex and converted to datetime. It's not like the datetime data is sensitive, and it certainly isn't human legible.Drew
if you use the SSMS GUI for "generate scripts" and "schema and data".....MS used to script as such...cant remember which version it changed on though
in SQL 2016 it scripts as CAST(N'2016-08-20T22:25:00.000' AS DateTime)
________________________________________________________________
you can lead a user to data....but you cannot make them think
and remember....every day is a school day
September 28, 2016 at 4:17 am
J Livingston SQL (9/27/2016)
drew.allen (9/27/2016)
Okay, is it just me? I've seen two different people post sample data where the datetime data is given in hex and converted to datetime. It's not like the datetime data is sensitive, and it certainly isn't human legible.Drew
if you use the SSMS GUI for "generate scripts" and "schema and data".....MS used to script as such...cant remember which version it changed on though
in SQL 2016 it scripts as
CAST(N'2016-08-20T22:25:00.000' AS DateTime)
That is terribly annoying. Why would MS do that?
Unless they're making a general "scrub everything" kind of decision for people.
September 28, 2016 at 4:49 am
I was doing another internal intro to DB maintenance session with the DevOps here.
And I used the GUI to create a backup script and scripted it out to a query window and closed the GUI without running to show the script... Both of them went along.
I then did the same thing for a Log backup. One of them said 'Oh how to you generate the script?' So I showed the script button in the top corner. 'Oh wow I hadn't seen that', I've been writing them out from scratch every time. can you do that anywhere else?'
Note to self remember to point out things like this with a 'did you know you can do this' type statement. My bad 🙁
Rodders...
September 28, 2016 at 4:57 am
rodjkidd (9/28/2016)
I was doing another internal intro to DB maintenance session with the DevOps here.And I used the GUI to create a backup script and scripted it out to a query window and closed the GUI without running to show the script... Both of them went along.
I then did the same thing for a Log backup. One of them said 'Oh how to you generate the script?' So I showed the script button in the top corner. 'Oh wow I hadn't seen that', I've been writing them out from scratch every time. can you do that anywhere else?'
Note to self remember to point out things like this with a 'did you know you can do this' type statement. My bad 🙁
Rodders...
There are many cases in history where instructions leave out what the writer thinks everyone knows. Oh, wait, that is a BOL. 🙂
September 28, 2016 at 8:46 am
J Livingston SQL (9/27/2016)
drew.allen (9/27/2016)
Okay, is it just me? I've seen two different people post sample data where the datetime data is given in hex and converted to datetime. It's not like the datetime data is sensitive, and it certainly isn't human legible.Drew
if you use the SSMS GUI for "generate scripts" and "schema and data".....MS used to script as such...cant remember which version it changed on though
in SQL 2016 it scripts as
CAST(N'2016-08-20T22:25:00.000' AS DateTime)
And when are script generators going to start using the table value constructor?
Drew
J. Drew Allen
Business Intelligence Analyst
Philadelphia, PA
September 28, 2016 at 8:52 am
Reposting from twitter:
"I'm looking for examples of extremely big or extremely busy relational database systems doesn't have to be SQL Server."
Case studies or similar, don't need detail, just
It's for a university lecture I'm giving next week, on the data-side of the IT industry. I'm finding that the grads from the local universities know a fair bit about the job opportunities on the software development side, but are woefully ignorant of the data side (relational, no-sql, Big Data, machine learning, data visualisation, etc)
Help?
Gail Shaw
Microsoft Certified Master: SQL Server, MVP, M.Sc (Comp Sci)
SQL In The Wild: Discussions on DB performance with occasional diversions into recoverability
Viewing 15 posts - 55,966 through 55,980 (of 66,549 total)
You must be logged in to reply to this topic. Login to reply