March 20, 2018 at 9:35 am
robert.sterbal 56890 - Tuesday, March 20, 2018 8:20 AMDoes anyone track and report on the causes of data breaches? How much of the risk if from social engineering, how much is from failing to keep up and how much is from a combination of these two?
Troy Hunt has a sweet site called "Have I Been Pwned". Might be of interest.
https://haveibeenpwned.com/
March 20, 2018 at 11:01 am
robert.sterbal 56890 - Tuesday, March 20, 2018 8:20 AMDoes anyone track and report on the causes of data breaches? How much of the risk if from social engineering, how much is from failing to keep up and how much is from a combination of these two?
man, one in three would give up their credentials.
Heck I remember a decade ago watching an employee go to joe-random-website and when the WEBSITE asked for credentials, she entered her local username and password.
We should quit calling it social engineering, because for most folks there isn't really any "engineering" needed LOL
March 20, 2018 at 12:22 pm
I think I might fall more into the classic Irish cop mold. Stop someone when they're going to be, or trying to do, something that will lead to problems down the road, explain why it would be a problem, then work with them to find a solution that will work (might be more work to implement, or be slightly less efficient) and guide them through what they need to do to get their change approved and implemented.
I must be doing something right, because every so often my team lead tells me the developers' bosses are quite happy with the support I've been providing...
:w00t:
March 20, 2018 at 1:25 pm
robert.sterbal 56890 - Tuesday, March 20, 2018 8:20 AMDoes anyone track and report on the causes of data breaches? How much of the risk if from social engineering, how much is from failing to keep up and how much is from a combination of these two?
Fairly good list at this site as well -
Privacy Rights Clearinghouse - Data Breaches
Sue
March 20, 2018 at 1:51 pm
Mike Hinds - Tuesday, March 20, 2018 5:18 AM'There's a joke that a DBA's favorite word is "no". 'Actually, it's often said that DBA stands for "Don't Bother Asking."
The actual order of things is often:
1) Traffic Cop
2) Fireman
3) Mechanic
4) Architect
5) TeacherThings can go much smoother when #s 4 and 5 can get the higher priorities.
Going along with your "Don't bother asking" acronym, another good one I have heard is "default blame acceptor". I don't know how many time's I've been told "this system is broken because the database is down!!!" and I spend more time than I like to invest to prove that it wasn't a database problem but a software update or application certificate or something unrelated to the database that actually went bad.
But the call comes in saying "the database is down" and instead of arguing straight out (as there is a tiny chance it could be the database is down and they know before I do, but I have a few different tools in place to monitor them and alert me as soon as there is trouble so I SHOULD know first) and most of the time, it isn't the database. I only remember one time when it was the database and that was because the failover server was set up differently than the primary and a planned failover occurred. Which was partially my fault (somebody else set up the failover, but I was to be supporting them).
But back on topic, I work as a DBA AND a developer so I feel both sides of that fight.
Developer - Can we enable feature XYZ on the server?
DBA - I can make that happen for you no problem. But why do you need that feature? Have you tested that feature on test to make sure it does what you think?
Developer - I need it because of reasons. it worked fine on test! Let's do this live. It makes things better.
DBA - can you show me which server you tested this on, your test plan, your test results? I would like to replicate this
Developer - never mind... I can make things work without it.
I generally like to let the developers come up with solutions and work with them to get those solutions into more of a "best practice".
Our developers have a lot of permissions on test, but very limited permissions on live. This way if a developer needs to test a feature on the test system, they can turn things on and off as they see fit and I just do spot checks on the test systems to make sure they are configured in a similar manner to live. There is risk with this method too as a developer could turn on a feature in test and forget to let the DBA know to turn it on in live and then their thing doesn't work as expected.
Also, if I don't have documentation telling me what I can and cannot do, I find that other developers sometimes go over my head and my boss comes down with "make it so". Haven't noticed that with my new boss yet, but my previous boss told me to make things happen because I was "holding up development". I do know when to make exceptions, but I need documentation as to why they need that exception (like RPC-OUT on a linked server... that exception should have VERY rarely go through, and I have yet to see a case where it is a good idea, but that was set up before my time and fixing it is a non-trivial thing at this piont. So, I get stuck trying to fix that mess :/).
The above is all just my opinion on what you should do.
As with all advice you find on a random internet forum - you shouldn't blindly follow it. Always test on a test server to see if there is negative side effects before making changes to live!
I recommend you NEVER run "random code" you found online on any system you care about UNLESS you understand and can verify the code OR you don't care if the code trashes your system.
March 20, 2018 at 1:59 pm
bmg002 - Tuesday, March 20, 2018 1:51 PMMike Hinds - Tuesday, March 20, 2018 5:18 AM'There's a joke that a DBA's favorite word is "no". 'Actually, it's often said that DBA stands for "Don't Bother Asking."
The actual order of things is often:
1) Traffic Cop
2) Fireman
3) Mechanic
4) Architect
5) TeacherThings can go much smoother when #s 4 and 5 can get the higher priorities.
Going along with your "Don't bother asking" acronym, another good one I have heard is "default blame acceptor". I don't know how many time's I've been told "this system is broken because the database is down!!!" and I spend more time than I like to invest to prove that it wasn't a database problem but a software update or application certificate or something unrelated to the database that actually went bad.
But the call comes in saying "the database is down" and instead of arguing straight out (as there is a tiny chance it could be the database is down and they know before I do, but I have a few different tools in place to monitor them and alert me as soon as there is trouble so I SHOULD know first) and most of the time, it isn't the database. I only remember one time when it was the database and that was because the failover server was set up differently than the primary and a planned failover occurred. Which was partially my fault (somebody else set up the failover, but I was to be supporting them).But back on topic, I work as a DBA AND a developer so I feel both sides of that fight.
Developer - Can we enable feature XYZ on the server?
DBA - I can make that happen for you no problem. But why do you need that feature? Have you tested that feature on test to make sure it does what you think?
Developer - I need it because of reasons. it worked fine on test! Let's do this live. It makes things better.
DBA - can you show me which server you tested this on, your test plan, your test results? I would like to replicate this
Developer - never mind... I can make things work without it.I generally like to let the developers come up with solutions and work with them to get those solutions into more of a "best practice".
Our developers have a lot of permissions on test, but very limited permissions on live. This way if a developer needs to test a feature on the test system, they can turn things on and off as they see fit and I just do spot checks on the test systems to make sure they are configured in a similar manner to live. There is risk with this method too as a developer could turn on a feature in test and forget to let the DBA know to turn it on in live and then their thing doesn't work as expected.
Also, if I don't have documentation telling me what I can and cannot do, I find that other developers sometimes go over my head and my boss comes down with "make it so". Haven't noticed that with my new boss yet, but my previous boss told me to make things happen because I was "holding up development". I do know when to make exceptions, but I need documentation as to why they need that exception (like RPC-OUT on a linked server... that exception should have VERY rarely go through, and I have yet to see a case where it is a good idea, but that was set up before my time and fixing it is a non-trivial thing at this piont. So, I get stuck trying to fix that mess :/).
Those details about what actually went down or failed are pointless most of the time outside of the IT group. Business often sees the entire system as the "Application Database". The normal user has no distinction between the application layer and the data layer, nor do they care. All they know is they can't use the system. They don't actually care what system portion is down as long as it gets fixed and they can carry on.
_______________________________________________________________
Need help? Help us help you.
Read the article at http://www.sqlservercentral.com/articles/Best+Practices/61537/ for best practices on asking questions.
Need to split a string? Try Jeff Modens splitter http://www.sqlservercentral.com/articles/Tally+Table/72993/.
Cross Tabs and Pivots, Part 1 – Converting Rows to Columns - http://www.sqlservercentral.com/articles/T-SQL/63681/
Cross Tabs and Pivots, Part 2 - Dynamic Cross Tabs - http://www.sqlservercentral.com/articles/Crosstab/65048/
Understanding and Using APPLY (Part 1) - http://www.sqlservercentral.com/articles/APPLY/69953/
Understanding and Using APPLY (Part 2) - http://www.sqlservercentral.com/articles/APPLY/69954/
March 20, 2018 at 2:22 pm
Sean Lange - Tuesday, March 20, 2018 1:59 PMbmg002 - Tuesday, March 20, 2018 1:51 PMMike Hinds - Tuesday, March 20, 2018 5:18 AM'There's a joke that a DBA's favorite word is "no". 'Actually, it's often said that DBA stands for "Don't Bother Asking."
The actual order of things is often:
1) Traffic Cop
2) Fireman
3) Mechanic
4) Architect
5) TeacherThings can go much smoother when #s 4 and 5 can get the higher priorities.
Going along with your "Don't bother asking" acronym, another good one I have heard is "default blame acceptor". I don't know how many time's I've been told "this system is broken because the database is down!!!" and I spend more time than I like to invest to prove that it wasn't a database problem but a software update or application certificate or something unrelated to the database that actually went bad.
But the call comes in saying "the database is down" and instead of arguing straight out (as there is a tiny chance it could be the database is down and they know before I do, but I have a few different tools in place to monitor them and alert me as soon as there is trouble so I SHOULD know first) and most of the time, it isn't the database. I only remember one time when it was the database and that was because the failover server was set up differently than the primary and a planned failover occurred. Which was partially my fault (somebody else set up the failover, but I was to be supporting them).But back on topic, I work as a DBA AND a developer so I feel both sides of that fight.
Developer - Can we enable feature XYZ on the server?
DBA - I can make that happen for you no problem. But why do you need that feature? Have you tested that feature on test to make sure it does what you think?
Developer - I need it because of reasons. it worked fine on test! Let's do this live. It makes things better.
DBA - can you show me which server you tested this on, your test plan, your test results? I would like to replicate this
Developer - never mind... I can make things work without it.I generally like to let the developers come up with solutions and work with them to get those solutions into more of a "best practice".
Our developers have a lot of permissions on test, but very limited permissions on live. This way if a developer needs to test a feature on the test system, they can turn things on and off as they see fit and I just do spot checks on the test systems to make sure they are configured in a similar manner to live. There is risk with this method too as a developer could turn on a feature in test and forget to let the DBA know to turn it on in live and then their thing doesn't work as expected.
Also, if I don't have documentation telling me what I can and cannot do, I find that other developers sometimes go over my head and my boss comes down with "make it so". Haven't noticed that with my new boss yet, but my previous boss told me to make things happen because I was "holding up development". I do know when to make exceptions, but I need documentation as to why they need that exception (like RPC-OUT on a linked server... that exception should have VERY rarely go through, and I have yet to see a case where it is a good idea, but that was set up before my time and fixing it is a non-trivial thing at this piont. So, I get stuck trying to fix that mess :/).Those details about what actually went down or failed are pointless most of the time outside of the IT group. Business often sees the entire system as the "Application Database". The normal user has no distinction between the application layer and the data layer, nor do they care. All they know is they can't use the system. They don't actually care what system portion is down as long as it gets fixed and they can carry on.
I would have to disagree with that, at least where I work. We have a path that end users are told to follow when reporting problems. First it goes to their supervisor who has more knowledge of the system than the end user and the supervisor will read the error and help them determine who should be contacted. With the above example I gave, it was a manufacturing support group (who are developers) who contacted me about the database being down. Later I found out they released a new version of their software which was not properly tested and was buggy.
Generally, our end users don't come crying to the DBA when things are bad as they have a list of people they should have contacted first and usually the DBA is contacted by a developer who has determined their code is valid and the problem must exist on the database. Sometimes the developer's pride gets in the way and they "know" their code is perfect and 100% bug free; therefore, it MUST be the database.
But I know I work at an atypical place. Our BI developer also does C# development. Our DBAs do C# development and one of our DBA's is also the one in charge of windows updates on some systems. And all of our developers have some TSQL knowledge. They also do SSIS and SSRS development on top of the C# and android development.
The above is all just my opinion on what you should do.
As with all advice you find on a random internet forum - you shouldn't blindly follow it. Always test on a test server to see if there is negative side effects before making changes to live!
I recommend you NEVER run "random code" you found online on any system you care about UNLESS you understand and can verify the code OR you don't care if the code trashes your system.
March 20, 2018 at 2:34 pm
bmg002 - Tuesday, March 20, 2018 2:22 PMSean Lange - Tuesday, March 20, 2018 1:59 PMbmg002 - Tuesday, March 20, 2018 1:51 PMMike Hinds - Tuesday, March 20, 2018 5:18 AM'There's a joke that a DBA's favorite word is "no". 'Actually, it's often said that DBA stands for "Don't Bother Asking."
The actual order of things is often:
1) Traffic Cop
2) Fireman
3) Mechanic
4) Architect
5) TeacherThings can go much smoother when #s 4 and 5 can get the higher priorities.
Going along with your "Don't bother asking" acronym, another good one I have heard is "default blame acceptor". I don't know how many time's I've been told "this system is broken because the database is down!!!" and I spend more time than I like to invest to prove that it wasn't a database problem but a software update or application certificate or something unrelated to the database that actually went bad.
But the call comes in saying "the database is down" and instead of arguing straight out (as there is a tiny chance it could be the database is down and they know before I do, but I have a few different tools in place to monitor them and alert me as soon as there is trouble so I SHOULD know first) and most of the time, it isn't the database. I only remember one time when it was the database and that was because the failover server was set up differently than the primary and a planned failover occurred. Which was partially my fault (somebody else set up the failover, but I was to be supporting them).But back on topic, I work as a DBA AND a developer so I feel both sides of that fight.
Developer - Can we enable feature XYZ on the server?
DBA - I can make that happen for you no problem. But why do you need that feature? Have you tested that feature on test to make sure it does what you think?
Developer - I need it because of reasons. it worked fine on test! Let's do this live. It makes things better.
DBA - can you show me which server you tested this on, your test plan, your test results? I would like to replicate this
Developer - never mind... I can make things work without it.I generally like to let the developers come up with solutions and work with them to get those solutions into more of a "best practice".
Our developers have a lot of permissions on test, but very limited permissions on live. This way if a developer needs to test a feature on the test system, they can turn things on and off as they see fit and I just do spot checks on the test systems to make sure they are configured in a similar manner to live. There is risk with this method too as a developer could turn on a feature in test and forget to let the DBA know to turn it on in live and then their thing doesn't work as expected.
Also, if I don't have documentation telling me what I can and cannot do, I find that other developers sometimes go over my head and my boss comes down with "make it so". Haven't noticed that with my new boss yet, but my previous boss told me to make things happen because I was "holding up development". I do know when to make exceptions, but I need documentation as to why they need that exception (like RPC-OUT on a linked server... that exception should have VERY rarely go through, and I have yet to see a case where it is a good idea, but that was set up before my time and fixing it is a non-trivial thing at this piont. So, I get stuck trying to fix that mess :/).Those details about what actually went down or failed are pointless most of the time outside of the IT group. Business often sees the entire system as the "Application Database". The normal user has no distinction between the application layer and the data layer, nor do they care. All they know is they can't use the system. They don't actually care what system portion is down as long as it gets fixed and they can carry on.
I would have to disagree with that, at least where I work. We have a path that end users are told to follow when reporting problems. First it goes to their supervisor who has more knowledge of the system than the end user and the supervisor will read the error and help them determine who should be contacted. With the above example I gave, it was a manufacturing support group (who are developers) who contacted me about the database being down. Later I found out they released a new version of their software which was not properly tested and was buggy.
Generally, our end users don't come crying to the DBA when things are bad as they have a list of people they should have contacted first and usually the DBA is contacted by a developer who has determined their code is valid and the problem must exist on the database. Sometimes the developer's pride gets in the way and they "know" their code is perfect and 100% bug free; therefore, it MUST be the database.
But I know I work at an atypical place. Our BI developer also does C# development. Our DBAs do C# development and one of our DBA's is also the one in charge of windows updates on some systems. And all of our developers have some TSQL knowledge. They also do SSIS and SSRS development on top of the C# and android development.
To be fair I think nearly everyone works in an atypical place. Sort of like everybody's family is weird. Find me a place of employment or family that isn't eccentric in some way or another. For example, in our place we don't really have a DBA, nor do we have an actual help desk. The users encounter an error and they may contact the development manager, the CIO or the developer they know the best. We are all somewhat responsible for routing these issues to the right person. As a developer I always assume it must be my code that is bad, I know the dummy who wrote it. 🙂 Sadly if it is a DB problem, well I know the dummy who designed it....it is the same dummy who wrote the bad code.
_______________________________________________________________
Need help? Help us help you.
Read the article at http://www.sqlservercentral.com/articles/Best+Practices/61537/ for best practices on asking questions.
Need to split a string? Try Jeff Modens splitter http://www.sqlservercentral.com/articles/Tally+Table/72993/.
Cross Tabs and Pivots, Part 1 – Converting Rows to Columns - http://www.sqlservercentral.com/articles/T-SQL/63681/
Cross Tabs and Pivots, Part 2 - Dynamic Cross Tabs - http://www.sqlservercentral.com/articles/Crosstab/65048/
Understanding and Using APPLY (Part 1) - http://www.sqlservercentral.com/articles/APPLY/69953/
Understanding and Using APPLY (Part 2) - http://www.sqlservercentral.com/articles/APPLY/69954/
March 20, 2018 at 2:49 pm
Sean Lange - Tuesday, March 20, 2018 2:34 PMTo be fair I think nearly everyone works in an atypical place. Sort of like everybody's family is weird. Find me a place of employment or family that isn't eccentric in some way or another. For example, in our place we don't really have a DBA, nor do we have an actual help desk. The users encounter an error and they may contact the development manager, the CIO or the developer they know the best. We are all somewhat responsible for routing these issues to the right person. As a developer I always assume it must be my code that is bad, I know the dummy who wrote it. 🙂 Sadly if it is a DB problem, well I know the dummy who designed it....it is the same dummy who wrote the bad code.
I've been in that boat too. Thankfully I am not the sole developer or sole DBA where I work. We have a policy in place that a developer cannot realease their own code (myself included). So if my application does something on the database, I need the other DBA to do the release for me. The other sucker... I mean DBA also gets the joy of doing code review for me. I feel bad for anybody that has to review my code.
And I do agree that everyone works in an atypical place. I do recommend getting a help desk like application in place though. We used to not have one and we implemented an expensive piece of junk 9 years ago then replaced that with something decent (but not excellent) 7 years ago. But prior to having one in place, we had a lot of people contacting support persons directly and it meant that some support staff was stupid busy and others were bored. And if somebody took a day off, it could be that an email would go unnoticed for a day (or more).
I also know my code is bad. It generally does what it is supposed to; not always the most efficient, not always the prettiest code, but it generally does what I expect it to do... or it crashes in a horrible mess. But the crashing I usually catch in our test environments before it hits live... well, unless a windows update causes it to explode... What is fun is trying to figure out if my code is bad in C# or if it is a bad stored procedure or trigger.
The above is all just my opinion on what you should do.
As with all advice you find on a random internet forum - you shouldn't blindly follow it. Always test on a test server to see if there is negative side effects before making changes to live!
I recommend you NEVER run "random code" you found online on any system you care about UNLESS you understand and can verify the code OR you don't care if the code trashes your system.
March 21, 2018 at 2:39 am
If a person behaves a certain way that is perceived to be detrimental I think it is important to ask why. If Traffic Cop behaviour is deemed undesirable then why does it manifest? It may not be because the person is an ass.
Quite possibly the thing that needs fixing may not be the individual but the environment in which they work.
March 21, 2018 at 7:30 am
bmg002 - Tuesday, March 20, 2018 2:49 PMSean Lange - Tuesday, March 20, 2018 2:34 PMTo be fair I think nearly everyone works in an atypical place. Sort of like everybody's family is weird. Find me a place of employment or family that isn't eccentric in some way or another. For example, in our place we don't really have a DBA, nor do we have an actual help desk. The users encounter an error and they may contact the development manager, the CIO or the developer they know the best. We are all somewhat responsible for routing these issues to the right person. As a developer I always assume it must be my code that is bad, I know the dummy who wrote it. 🙂 Sadly if it is a DB problem, well I know the dummy who designed it....it is the same dummy who wrote the bad code.I've been in that boat too. Thankfully I am not the sole developer or sole DBA where I work. We have a policy in place that a developer cannot realease their own code (myself included). So if my application does something on the database, I need the other DBA to do the release for me. The other sucker... I mean DBA also gets the joy of doing code review for me. I feel bad for anybody that has to review my code.
And I do agree that everyone works in an atypical place. I do recommend getting a help desk like application in place though. We used to not have one and we implemented an expensive piece of junk 9 years ago then replaced that with something decent (but not excellent) 7 years ago. But prior to having one in place, we had a lot of people contacting support persons directly and it meant that some support staff was stupid busy and others were bored. And if somebody took a day off, it could be that an email would go unnoticed for a day (or more).
I also know my code is bad. It generally does what it is supposed to; not always the most efficient, not always the prettiest code, but it generally does what I expect it to do... or it crashes in a horrible mess. But the crashing I usually catch in our test environments before it hits live... well, unless a windows update causes it to explode... What is fun is trying to figure out if my code is bad in C# or if it is a bad stored procedure or trigger.
I have been begging for a help desk system for the entire time I have been here...10 years this summer. When I started here they used zip files to pass code around and had not even heard of source control. In fairness we are not an IT business, we are in manufacturing. But our entire ERP was written in house and been in place for more than 30 years. How they managed it without any source code is a miracle.
_______________________________________________________________
Need help? Help us help you.
Read the article at http://www.sqlservercentral.com/articles/Best+Practices/61537/ for best practices on asking questions.
Need to split a string? Try Jeff Modens splitter http://www.sqlservercentral.com/articles/Tally+Table/72993/.
Cross Tabs and Pivots, Part 1 – Converting Rows to Columns - http://www.sqlservercentral.com/articles/T-SQL/63681/
Cross Tabs and Pivots, Part 2 - Dynamic Cross Tabs - http://www.sqlservercentral.com/articles/Crosstab/65048/
Understanding and Using APPLY (Part 1) - http://www.sqlservercentral.com/articles/APPLY/69953/
Understanding and Using APPLY (Part 2) - http://www.sqlservercentral.com/articles/APPLY/69954/
March 21, 2018 at 7:56 am
Sean Lange - Wednesday, March 21, 2018 7:30 AMbmg002 - Tuesday, March 20, 2018 2:49 PMSean Lange - Tuesday, March 20, 2018 2:34 PMTo be fair I think nearly everyone works in an atypical place. Sort of like everybody's family is weird. Find me a place of employment or family that isn't eccentric in some way or another. For example, in our place we don't really have a DBA, nor do we have an actual help desk. The users encounter an error and they may contact the development manager, the CIO or the developer they know the best. We are all somewhat responsible for routing these issues to the right person. As a developer I always assume it must be my code that is bad, I know the dummy who wrote it. 🙂 Sadly if it is a DB problem, well I know the dummy who designed it....it is the same dummy who wrote the bad code.I've been in that boat too. Thankfully I am not the sole developer or sole DBA where I work. We have a policy in place that a developer cannot realease their own code (myself included). So if my application does something on the database, I need the other DBA to do the release for me. The other sucker... I mean DBA also gets the joy of doing code review for me. I feel bad for anybody that has to review my code.
And I do agree that everyone works in an atypical place. I do recommend getting a help desk like application in place though. We used to not have one and we implemented an expensive piece of junk 9 years ago then replaced that with something decent (but not excellent) 7 years ago. But prior to having one in place, we had a lot of people contacting support persons directly and it meant that some support staff was stupid busy and others were bored. And if somebody took a day off, it could be that an email would go unnoticed for a day (or more).
I also know my code is bad. It generally does what it is supposed to; not always the most efficient, not always the prettiest code, but it generally does what I expect it to do... or it crashes in a horrible mess. But the crashing I usually catch in our test environments before it hits live... well, unless a windows update causes it to explode... What is fun is trying to figure out if my code is bad in C# or if it is a bad stored procedure or trigger.I have been begging for a help desk system for the entire time I have been here...10 years this summer. When I started here they used zip files to pass code around and had not even heard of source control. In fairness we are not an IT business, we are in manufacturing. But our entire ERP was written in house and been in place for more than 30 years. How they managed it without any source code is a miracle.
No source code huh? Then it might have been written by Mel.
March 21, 2018 at 8:00 am
patrickmcginnis59 10839 - Wednesday, March 21, 2018 7:56 AMSean Lange - Wednesday, March 21, 2018 7:30 AMbmg002 - Tuesday, March 20, 2018 2:49 PMSean Lange - Tuesday, March 20, 2018 2:34 PMTo be fair I think nearly everyone works in an atypical place. Sort of like everybody's family is weird. Find me a place of employment or family that isn't eccentric in some way or another. For example, in our place we don't really have a DBA, nor do we have an actual help desk. The users encounter an error and they may contact the development manager, the CIO or the developer they know the best. We are all somewhat responsible for routing these issues to the right person. As a developer I always assume it must be my code that is bad, I know the dummy who wrote it. 🙂 Sadly if it is a DB problem, well I know the dummy who designed it....it is the same dummy who wrote the bad code.I've been in that boat too. Thankfully I am not the sole developer or sole DBA where I work. We have a policy in place that a developer cannot realease their own code (myself included). So if my application does something on the database, I need the other DBA to do the release for me. The other sucker... I mean DBA also gets the joy of doing code review for me. I feel bad for anybody that has to review my code.
And I do agree that everyone works in an atypical place. I do recommend getting a help desk like application in place though. We used to not have one and we implemented an expensive piece of junk 9 years ago then replaced that with something decent (but not excellent) 7 years ago. But prior to having one in place, we had a lot of people contacting support persons directly and it meant that some support staff was stupid busy and others were bored. And if somebody took a day off, it could be that an email would go unnoticed for a day (or more).
I also know my code is bad. It generally does what it is supposed to; not always the most efficient, not always the prettiest code, but it generally does what I expect it to do... or it crashes in a horrible mess. But the crashing I usually catch in our test environments before it hits live... well, unless a windows update causes it to explode... What is fun is trying to figure out if my code is bad in C# or if it is a bad stored procedure or trigger.I have been begging for a help desk system for the entire time I have been here...10 years this summer. When I started here they used zip files to pass code around and had not even heard of source control. In fairness we are not an IT business, we are in manufacturing. But our entire ERP was written in house and been in place for more than 30 years. How they managed it without any source code is a miracle.
No source code huh? Then it might have been written by Mel.
LOL. Obviously meant to say source control. 😀
_______________________________________________________________
Need help? Help us help you.
Read the article at http://www.sqlservercentral.com/articles/Best+Practices/61537/ for best practices on asking questions.
Need to split a string? Try Jeff Modens splitter http://www.sqlservercentral.com/articles/Tally+Table/72993/.
Cross Tabs and Pivots, Part 1 – Converting Rows to Columns - http://www.sqlservercentral.com/articles/T-SQL/63681/
Cross Tabs and Pivots, Part 2 - Dynamic Cross Tabs - http://www.sqlservercentral.com/articles/Crosstab/65048/
Understanding and Using APPLY (Part 1) - http://www.sqlservercentral.com/articles/APPLY/69953/
Understanding and Using APPLY (Part 2) - http://www.sqlservercentral.com/articles/APPLY/69954/
March 21, 2018 at 8:12 am
Sean Lange - Wednesday, March 21, 2018 8:00 AMpatrickmcginnis59 10839 - Wednesday, March 21, 2018 7:56 AMSean Lange - Wednesday, March 21, 2018 7:30 AMbmg002 - Tuesday, March 20, 2018 2:49 PMSean Lange - Tuesday, March 20, 2018 2:34 PMTo be fair I think nearly everyone works in an atypical place. Sort of like everybody's family is weird. Find me a place of employment or family that isn't eccentric in some way or another. For example, in our place we don't really have a DBA, nor do we have an actual help desk. The users encounter an error and they may contact the development manager, the CIO or the developer they know the best. We are all somewhat responsible for routing these issues to the right person. As a developer I always assume it must be my code that is bad, I know the dummy who wrote it. 🙂 Sadly if it is a DB problem, well I know the dummy who designed it....it is the same dummy who wrote the bad code.I've been in that boat too. Thankfully I am not the sole developer or sole DBA where I work. We have a policy in place that a developer cannot realease their own code (myself included). So if my application does something on the database, I need the other DBA to do the release for me. The other sucker... I mean DBA also gets the joy of doing code review for me. I feel bad for anybody that has to review my code.
And I do agree that everyone works in an atypical place. I do recommend getting a help desk like application in place though. We used to not have one and we implemented an expensive piece of junk 9 years ago then replaced that with something decent (but not excellent) 7 years ago. But prior to having one in place, we had a lot of people contacting support persons directly and it meant that some support staff was stupid busy and others were bored. And if somebody took a day off, it could be that an email would go unnoticed for a day (or more).
I also know my code is bad. It generally does what it is supposed to; not always the most efficient, not always the prettiest code, but it generally does what I expect it to do... or it crashes in a horrible mess. But the crashing I usually catch in our test environments before it hits live... well, unless a windows update causes it to explode... What is fun is trying to figure out if my code is bad in C# or if it is a bad stored procedure or trigger.I have been begging for a help desk system for the entire time I have been here...10 years this summer. When I started here they used zip files to pass code around and had not even heard of source control. In fairness we are not an IT business, we are in manufacturing. But our entire ERP was written in house and been in place for more than 30 years. How they managed it without any source code is a miracle.
No source code huh? Then it might have been written by Mel.
LOL. Obviously meant to say source control. 😀
I know but it reminded me of that link so had to take advantage!
March 21, 2018 at 8:57 am
Sean Lange - Wednesday, March 21, 2018 7:30 AMbmg002 - Tuesday, March 20, 2018 2:49 PMSean Lange - Tuesday, March 20, 2018 2:34 PMTo be fair I think nearly everyone works in an atypical place. Sort of like everybody's family is weird. Find me a place of employment or family that isn't eccentric in some way or another. For example, in our place we don't really have a DBA, nor do we have an actual help desk. The users encounter an error and they may contact the development manager, the CIO or the developer they know the best. We are all somewhat responsible for routing these issues to the right person. As a developer I always assume it must be my code that is bad, I know the dummy who wrote it. 🙂 Sadly if it is a DB problem, well I know the dummy who designed it....it is the same dummy who wrote the bad code.I've been in that boat too. Thankfully I am not the sole developer or sole DBA where I work. We have a policy in place that a developer cannot realease their own code (myself included). So if my application does something on the database, I need the other DBA to do the release for me. The other sucker... I mean DBA also gets the joy of doing code review for me. I feel bad for anybody that has to review my code.
And I do agree that everyone works in an atypical place. I do recommend getting a help desk like application in place though. We used to not have one and we implemented an expensive piece of junk 9 years ago then replaced that with something decent (but not excellent) 7 years ago. But prior to having one in place, we had a lot of people contacting support persons directly and it meant that some support staff was stupid busy and others were bored. And if somebody took a day off, it could be that an email would go unnoticed for a day (or more).
I also know my code is bad. It generally does what it is supposed to; not always the most efficient, not always the prettiest code, but it generally does what I expect it to do... or it crashes in a horrible mess. But the crashing I usually catch in our test environments before it hits live... well, unless a windows update causes it to explode... What is fun is trying to figure out if my code is bad in C# or if it is a bad stored procedure or trigger.I have been begging for a help desk system for the entire time I have been here...10 years this summer. When I started here they used zip files to pass code around and had not even heard of source control. In fairness we are not an IT business, we are in manufacturing. But our entire ERP was written in house and been in place for more than 30 years. How they managed it without any source code is a miracle.
oh wow... I feel for you then. We are in manufacturing as well, but are big enough that running without source control (especially when there are free solutions out there) is just scary. BUT we do have some applications used in production that have no source code and thus are stuck on Windows XP (or with 1 program... windows 95... but thankfully we don't make that product anymore).
as for help desk, there are "free" solutions if you have no budget. Mind you "free" still means somebody has to support it and it still requires an OS license, unless you piggyback your systems.
We are a company of approximately 500 people and we only recently got a document control system in place. Mind you, it is for a very small department (7 people) and we are using the community edition so if anything goes sour, we have no support. And we don't have any real TSQL source control in place. We have tools in place to watch for any schema level changes, but it is more of a monitoring tool than revision control.
The above is all just my opinion on what you should do.
As with all advice you find on a random internet forum - you shouldn't blindly follow it. Always test on a test server to see if there is negative side effects before making changes to live!
I recommend you NEVER run "random code" you found online on any system you care about UNLESS you understand and can verify the code OR you don't care if the code trashes your system.
Viewing 15 posts - 16 through 30 (of 40 total)
You must be logged in to reply to this topic. Login to reply