Developers and DBAs
-
Any experiences you'd like to share?
-
The other DBA who "claimed" to have 10 years experience may know a little more about DTS then you do. First off if you don't create separate connections for each transform then they will not run in parallel. Having a few extra connections for a shorter time is much better than running the package in serial, and ironically, it would have solved your 20 temporary jobs problem that you discuss later in the article!
Secondly, there are good security reasons to not have your SQL Server connection information sitting in your job text. The hash that is created by right-clicking and scheduling a package is more secure than username and password clear text that might end up in a dts log file.
Thirdly, your solution of select * into b from a would have of course created a shared lock on table a. If the table was large you could have locked the original table, breaking your application. Moving the data in batches (which may have been what your supervisor was suggesting) may have been a better move. The sad thing is that you criticized before you tried to find out!
It also seems that you created a DTS solution that was not easy to understand and easily modify and were upset with your boss' legitimate request for more documentation on this complex process. If it were me I would have written one package with 20 transformations (yes, using 40 connections so they will run in parallel!) with perhaps a small application or stored procedure to change the connections from code if needed, so you don't have to change the package. It would run faster and be easier to understand, and be a heck of a lot less messy than 20 temporary jobs.
Finally, even calling someone a junior DBA is something that's not necessary in this day and age. We're all a team and if the corporation stratifies us that doesn't mean we need to do it to ourselves. It all just reeks of arrogance and lack of flexibility in your point of view.
It's always frustrating when people don't fully appreciate the work you do, but worse than any manager is another DBA who thinks he's better than everyone else. You need to ask yourself, did anyone leave the company because of me?
-
LOL. Too numerous to count.
One of my favorites was when the owner of the small business I worked for (which shall remain nameless...) called me into his office and went off on a rant. He informed me that he was a better person than me because he earned "$200 an hour", and I turned in my resignation on the spot.
Well, after I left he hired 3 consultants (at exhorbitant rates) to come in and implement a system for the business. The key was his biggest customers were demanding that he get this system implemented quickly or lose their business (some of the biggest store chains in the world). About 1-1/2 years and $150,000 later, he still didn't have the system in place.
So, basically he had one of his people call me up and ask me to implement the system for him on a contract basis. Which I did, and it took about 3 months.
At $200 an hour.
-
Can I just tell you that's the best story I've heard all day? I love karma...
Maria Myers
maria@ergsearch.com
920.996.9700 x126 -
Lol, Can I send him my resume.
I think you should have charged 300$ plus overtime
.Message me if you find another one like this
. -
GREAT ARTICLE! Not unusual. It's great when you work with a true group of professionals, all with a goal to make the process work more efficiently, take suggestions and give suggestions and the atmosphere is friendly. Been there ONCE in my career at a large startup company.
-
Man, stories like this make me think about how lucky I am. Our company is a medium sized one so our politics and stucture are different than many out there. I am the senior DBA at our company and I have a team of three DBAs/Database developers. Our task is to maintain the whole database layer of our company. We write all DTS/SSIS packages and all sps. I guess I am very territorial in this respect. We all know that the databases cause many performance issues and I am a believer that only very skilled SQL developers should be doing any database work. If you allow all other developers to all do their own work against your data stores you are destined to have problems. Having SQL syntax knowledge is one thing, but knowing how the SQL Server works internally is very important to successful database implementation. I can't believe that your DBAs didn't listen to or were aware of the performance problems. It sounds like their knowledge was lacking and because their pride was hurt they took it out on you. Very unfortunate, especially to play that race card.
-
I'm a SQL developer too and have been in that situation, however I learned from my mistakes. I admit it, it wasn't always other people's fault! The thing is that they might have thought you were showing off. They probably built a case against you and ... I think it was a bit your fault too. Even if your suggestion is way better and easier, you shouldn't say that "I have a better idea". Or, if someone does a mistake, that's OK. It can be easily be handled by telling that junior DBA that you can't see one of the tables in production. As developers, we all know "BUG" means we did a mistake. I don't like if someone runs to my manager and complains.
-
I have to agree with Alex that it is not about DBA vs Developer. It's about people.
Her boss is in the position to leverage Janet's enthusiasm, creativity and skills to help the department/group to perform better. However, her boss saw her as a threat.
This is very unfortunate. Hope you got a better job.
-
I wanted to clear something.
When I put anything into production, the company required us to fill out a form and had at least 6 manangers signed the form. The DBA got the form and put in production. Then I would check if it was alright and signed off. I did not make a big show to complain the junior DBA, I just did not sign off because the implemention was incorrect. This went to her boss. All these were the company procedure, I could not control it. I would like to tell the junior DBA myself but the company required 'proper signature'.
When I suggested 'SELECT * into Backup FROM tableA', it was because I knew the table was small and it was an emergency production problem. Instead of taking a couple hour to create the backup file, I just wanted to get it done fast before the DBA went home.
I did make the whole process a little complicated. The senior DBA told me the junior DBA tried to read my procedure and had no clue what I was doing. However I did it because I knew later on, there would be more files to copy to the database. I did it this way so I did not have to create a DTS package or change DTS package. All I had to do was put the name of the file in the table. BTW, we all use window authentication, so I did not need to put sign on ID and password in the DTS package.
In the dtsrun, I just put down the server name, the package name and all the global variables.
When you put twenty connections in the DTS package, it ran in parallel, but the DTS package still keeps running until all the transfer were finished.
I created a job for each file was because all the files were created by main frame programs. Each file came down at different time. Part of the DTS package was checking if the file exists in the directory, if not, then it would wait five minutes and check again until it finds the file or until after certain hour. If I put all these in one DTS package, I had no idea which file was processed. The reason I created a job to run was I would know which file had processed and which file had not processed.
Maybe I made the whole process too complicated. But I like to make long term solution for every project.
Just my opinion.
-
Sounds like you did a great job. And if they didn't agree, then they could have discussed it!
You made some of the points i was going to make.
In todays climate 'being helpful' is usually a bad thing. It has to do with the nature of offering. If they express interest and you help them then thats great. If you offer, and you are not a good team with trust and communication, then it can be taken many different ways. And you have no way of knowing how they will take it. They could take it as 'they must think they know more than me', 'they must think i am stupid', 'they are making me look bad', etc...!
However if you help them when they ask for it then you will get more respect and they will start trusting you more. Just the nature of things. This is true for most people. Even some of the people posting.
To make it more of a technical post perhaps you could have included an example of what you did.
-
What a terrible article. There are a bajillion stories that nearly anyone can tell about how messed up a previous workplace may have been. It is silly to mis-represent this article to make it seem like it has something relevant to say about the relationship between developers and DBAs.
-
This thing happen anytime anywhere, no matter you are contractor or staff. I learn it through the hard way too. Now I just do what ever I can do under my user right. That's might because I still kindly like be a contractor in this area.
-
Good article about trying to work together. But it goes both ways. I'm a DBA and we have a developer who does EVERYTHING as a DTS package. Each step in the package has two 'side' steps to email her if that step is 1) successful or 2) fails. Yes for every step in the package. We try to get her to change her ways, but nothing happens. She will have a problem and then makes it our problem to solve.
-SQLBill
-
The above are all good responses. I don't think anyone has an overwhelming ability to resiliance to dysfunctional corporate / work group behavior. It is interesting to consider or discover the reasons for the behavior. Incompetence, paranoia, fear. Does it pay to speak in private and directly to people who are behaving dysfunctially about what is happening? I guess it depends.
Viewing 15 posts - 31 through 45 (of 50 total)
You must be logged in to reply to this topic. Login to reply