Introduction

I am an SQL developer. Over the years, I have worked with many database developers with many different levels of talent and skill. Some were smart and talented with great skills, but most were like me, an average developer with average programming skills. But no matter what our skill level, we all tried our best to get the job done. We worked as a team. Although every developer had his or her own style and we might argue about how to get a project done, I never encountered a developer who displayed any envy or resentment of their co-workers who happened to have better skills.

That is, until my last company. I am no longer there so I can talk about it.

This was a large company with separate DBA and SQL Developer groups. There were three SQL Server DBAs in the DBA group. The company had many "SQL Server developers", of which I was one. I reported directly to a supervisor and he reported to a manager.

I thought the SQL Server skill levels at this company were pretty uneven. For example, the company used a lot of DTS Packages. But many of the packages were not properly written or used. The DBA would click on the "Schedule Package" of all the DTS Packages to create the job. When I opened the job, I saw the DTSRUN names were filled with long strings of

numbers and characters. The name of the job had to be manually matched with the name of the DTS package. I spoke to the manager of the DBA group about this and he said that was the only way they knew how to schedule a DTS package. I opened a DTS package; it transferred five tables from one database of one server to another database of another

server. Well, how many connections would you create? Two right? I saw TEN connections - two for each table. The most amazing thing was the DTS package was written by a DBA who claimed to have over 10 years' experiences.

My Work !!!

My manager did not understand SQL and did not claim to. He just made sure my work was finished before the deadline assigned to it. My supervisor claimed to be an expert in SQL, but I don't think he was. For example, one time we had to backup a table in production because we had to change something in the table. My supervisor insisted on doing the job. He told my manager it would take him a couple of hours to write the script to create the table and insert the data from the original table. I made the mistake of suggesting in the presence of the manager that they use a simple "SELECT * INTO TableA_bak FROM TableA" query. My supervisor took the suggestion, but was not too happy with me.

Things did not go well from then on.

My first major assignment at that company was creating a data mart for a reporting system. I had to create 20 dimension tables. Each dimension came from a flat file created by another group. Each flat file had its own format file. I could create a big DTS Package and have all 20 files transfer to different SQL Server tables or create one DTS

package per each file. I was not happy with either choice.

I created a lookup table and had the following fields: text file directory, text file name, format file directory, and format file name, number of column in the file, SQL server name, SQL Server database name and table name. I wrote a DTS package. I put the text file, format file, server and database name, and table name in global variables. I then created a "Dynamic Property Task". The first entry was to read the lookup table to get the server and database names, and put in the connection property. This way when the DTS package moved from one server to another server, the DBA did not need to open the package to change the connection. The lookup table would have the correct server name. Then I assigned the rest of the global variables using Active X script. First the package made sure the format file and text file existed. It used a "Transform Data Task" to load the file into a staging table. If the staging table was empty, an error email would be sent out to the developer; otherwise it loaded the data into the real table. The last step moved the text file into the backup directory.

I wrote a stored procedure to read the lookup table. The procedure created a loop and used dynamic SQL to execute the DTS package for each entry in the lookup table. However, I found out if I executed the DTS package, it executed only one file at a time. There were some big files and the procedure would run for a long time. So instead of executing the DTS package, I changed the procedure to create a temporary job for processing each file. One step in the procedure was execution of the DTS package. If the job finished successfully, it would kill itself. In this way, all files could be processed at the same time. I also wrote the DTSRUN so users could see the server name, package name and all the parameters.

With these changes, if I had to add more files later on, all I needed to do was to add an entry in the lookup table. I was pretty proud of my work. Unfortunately no one in the company shared my happiness. In fact, things really started to go downhill now.

Instead of praising my work, my supervisor wrote in my review that I was lousy at writing documentation. I wrote about four pages for each procedure, it stated all the tables and fields and how the procedure functioned. He said it was not enough. I admit it; I am a developer and not a writer. But he changed my documentation by writing about 25 pages

of useless information for each procedure. He turned the documentation into a book that basically listed all the hardware, software and all kinds of stuff that no one cares about.

The DBA group was not too thrilled either even though I showed them how to write a proper DTSRUN statement. I showed them that when they moved my DTS package they did not need to change the connection.

One time I complained that a junior DBA screwed up and forgot to move a table into production. The DBA manager complained to my manager and said I was difficult to work with. He said I told his people how to do their work. And he said I complained about the junior DBA who was an Indian woman. He suggested that I might be a racist against Indian women, despite the fact I am a woman and a minority. The DBA manager wrote a book teaching IT managers how to fire computer professionals "With Cause", so if he did not like me and want me to get fired, he knew exactly what to do!!!!! My manager warned me to be more careful about what I said and basically just to keep my mouth shut.

Conclusion

I began to wonder why I did all this work. Should I just write 20 DTS packages and let the DBA group schedule the job? Should I just let them open the DTS package every time when they moved from server to server? I felt that I came up with good ideas but just kept getting shot in the foot.

It is a valuable lesson. What did I learn from all this? From then on I talked very carefully and did my work very carefully, making sure I fit in with the others. I did not know who my friends were, or who my enemies were. I was surrounded by more than 200 people in my company, but I felt very lonely at work.