So today I spent debugging a report.
What was the issue, I didn't know.
Just knew it was wrong and I was assigned to fix it.
So I found the report in Team Foundation Server, added it to my MS Project.
Looked at the SQL.
Then looked at the Spreadsheet.
Hmmm. Still don't know.
So I sent an email to the user.
She called shortly and we discussed the issue.
I brought in another guy on the speaker phone.
So I knew what the problem was.
Next I cleaned up the SQL put everything in Table Variables.
And formatted the code so it was legible.
Then ran each piece of code separately.
There it was, one of the records was duplicated.
Spent a few hours trudging through the logic.
5pm. Holy cow the day flew by.
On the way out I discussed my findings.
Sure enough, when I explained what I found, I found the solution without knowing it.
Some data was not entered in one of the tables which was mandatory for the correct results.
So tomorrow I should have loaded data.
And then I can view the changes.
I think the other issue with the double entries has to do with a Left Outer Join which should be an INNER JOIN.
Will research tomorrow.
Moral of the story.
It IS possible to troubleshoot a report, without knowing the database structure, the business logic or anything about the report.
With a phone call and some analysis of the SQL code, you can fix bugs and be proficient at troubleshooting.
However, it's still essential to learn the business rules so you can troubleshoot quicker.
And then document the process' and really speed things up.
And there you have it!
I signed up for the Hortonworks Certified Associate exam last Thursday. Figured if I sign up, I'd have to take the test. And if I tak...
Saw a post today on Twitter, " Microsoft releases CNTK, its open source deep learning toolkit, on GitHub " This is big news. Be...
It seems like open source applications are the mainstream today. So many new products delivered through Aache foundation. Some do this. S...