xSQL Bundle receives highest marks and praise from SSWUG

Just realized that we never published a link to this review of our database comparison tools xSLQ Object and xSQL Data Compare. The review was conducted by Stephen Wynkoop, Microsoft SQL Server MVP and SSWUG founder who was duly impressed with our products and gave them the highest rating possible in all aspects of the review, overall score, installation, usage and real-World usefulness. You can read Stephen's review here:
http://www.xsqlsoftware.com/reviews/sswug_xsql_compare_review.pdf

User an idiot no more!

Not more than 10 years ago it was not unusual to hear programmers vent their frustration about the users who were all “idiots“, and see users sheepishly admit of having clicked the “wrong button”. During those 10 years things have changed dramatically in both sides – the users are increasingly savvy and their expectations have increased significantly while the programmers, no more shielded by the mystique of the profession, dread hearing a user proclaim “who is the moron that wrote this code!”. Nowadays it is common to see puzzled users tell their programmers “what do you mean that can’t be done…?”, nowadays there is no such thing as “the wrong button”, nowadays if something goes bad with the application it is not the user who is the idiot but rather the programmer is the inept moron.

Not trying to make any point here – just an observation on one of the aspects of the evolution of the profession. Do you agree with this observation?

SQL Server Resource Index

Here is a great page http://www.sqlserverindex.com with links to SQL Server resources: official sites; global user groups; learning resources; events; books; third party SQL Server tools, local user groups, and local SQL Server consultants on the major US metropolitan areas.

SQL Server Profiler – a lesson learned the hard way

Background: I was recently at the site of a client who was concerned that the CPU utilization had shot up in the last few months without any apparent reason. Since this was a node on an Active/Active cluster and was supposed to be the failover node for their more important node they had moved quickly and upgraded from a 64-bit dual processor to a 64-bit quad. The CPU utilization had dropped from over 70% to somewhere in the 30-35% range however the concern was still there – they wanted to find out what caused the trouble in the first place.

Trouble starts: After spending a bit of time understanding the environment, looking at the trends and documenting the current status I decided to start a trace on the effected node and save a few minutes of data on a SQL Server table. I was feeling pretty good about it until I clicked on “start” and the trace fired away. I looked at the CPU utilization and I noticed, to my utter surprise that it dropped significantly and it was staying down – I did not like that and stopped the trace immediately (it must have been running for about 65 seconds).

There, now I had another puzzle on my hand – was that a simple coincidence that as soon as I started the trace it so happened that the “demand” on the server dropped, maybe a great number of users just logged off and went to eat lunch or was it something else?! Soon after a very concerned user came buy and was telling the resident IT person in charge that this third party application had gone haywire – it had started assigning case numbers from the beginning of time creating duplicate entries in the system etc…

Now I am not going to go into how totally unacceptable it is for a professional software application to behave that way… regardless, it was my trace that somehow caused this trouble that ended up taking hours of manual labor to clean up.

So, now I am stuck, I am looking at all kinds of reports but without current trace data I can’t see what’s going on and after what happened I don’t dare start another trace.

Solution: After I ran out of alternative options I decided to give it another try – this time I was not going to run a trace from SQL Server Profiler on my remote client machine but instead a server side trace. Furthermore, instead of storing the trace data on SQL Server I directed it to file on another drive. I got the script ready and keeping my fingers crossed executed it while watching the CPU utilization – this time I was pleasantly surprised to see that nothing seemed to change, the trace was not affecting the CPU utilization at all – I also had someone monitoring that third party application to make sure that it wasn’t going haywire again – everything seemed good.

I let the trace run for a whole hour. I downloaded the trace files (a couple of gigs of data) and uploaded all the data in a SQL Server database on my local machine. Now things were a lot easier – it did not take more than a few minutes to identify the query that was causing all the trouble - a trigger from that third party had failed and a couple of tables had ballooned to hundreds of thousands of rows when they were supposed to have no more than something like 50 rows! Trigger was fixed and CPU utilization went down to 10% and it is staying at that level.

Lesson: Overall it was a great success but not without some bruising on the way. The lesson learned – never run a client side trace on a sensitive production system it can bring the server to its knees.

Related Info: In case you don’t have much experience and are wondering how to run a server side trace here is a quick guide:

• Start SQL Server Profiler on your local machine;
• Click on “New Trace” and connect to a non-sensitive server – if you have an instance of SQL Server on your local machine all the better – just connect to that one;
• Define your trace;
• Start the trace;
• Stop the trace;
• Go to File / Export / Script Trace Definition / For SQL Server [2005 / 2000];
• Open the just saved script and change the path/file where you want your real trace data to go. Also, make sure all the other parameters are what you want them to be.
• When you are ready to start the trace on the “real” server simply execute the script against the target server.
• Note down the trace id so that you can stop and delete it when you are done.

Lastly, check out our products a lot of them are free - see the left panel here.

xSQL Documenter released

We are very excited to announce a new addition to our suite of cool SQL Server tools, xSQL Documenter a professional grade tool for documenting your databases.You can read more about xSQL Documenter on our website at: http://www.xsql.com/products/database_documenter/ but here is a quick list of what this new tool brings:

• Supports all objects in all major dbms-es including SQL Server, Oracle, DB2, MySQL
• Generates HTML and compiled CHM output
• Generates dependency and primary/foreign key graphs
• Shows DDL/XMLA code for all documented objects
• You can run it from the command line
• You can easily brand the documentation

You can download an evaluation copy of the xSQL Documenter from: http://www.xsql.com/download/database_documenter/ Please do post your comments and suggestions regarding this products or any of our other products at: http://www.xsql.com/suggestfeature.aspx.

Why is he making more than me?

As much as employers try to conceal the compensation that each employee receives and as much as the rules of etiquette dictate that we shouldn’t poke around to find out how much our peers are making we are all curious to know and it is a justified curiosity that sooner or later will result into some employees getting hold of such information. In a perfect World the fact that some employees (or even all) know how much their peers are making should have no bearing on your organization but chances are high that the compensation has gradually gotten out of whack and assuming that is the case, such information will have a powerful deteriorating effect on the moral of the employees and consequently on the productivity of the organization.

How does the compensation get out of whack?

There are many factors that contribute in creating an unbalanced unfair compensation structure in an organization. Here are a few obvious ones:

• Organizations do not keep up with the market therefore the compensation of the employees hired at different points in time may vary widely despite the similar qualifications, experience and the work they do. Example: the regular raises have not kept up with the market – in other words if you hired a programmer in year X when the average going rate for a rookie programmer with a CS degree was $45K / year and increased his/her compensation by 3% every year – after 3 years his compensation will be just above $49K. Let’s say that in the meantime the market conditions have pushed the average going rate to $55K. Now a new rookie with no experience starts at $55K … A rational mind would argue that the market will take care of such discrepancies as the employee that is stuck at a lower pay grade will leave the company and will find a new job at the going market rate! Well, not quite - there are many factors that make it very hard if not impossible for an employee to simply jump ship and go climb aboard another ship.
• Ability of the employee to negotiate / sell himself – again, a rational mind would argue that unless you are applying for a sales or management type position your selling and negotiating abilities should have no effect in your compensation since you will not be “producing” any more or better than your peers. However the reality does not follow the rational – the fact is that your compensation depends heavily on your ability to sell yourself and negotiate. The effect can sometimes be that you end up with a charismatic programmer that is making significantly more than his peers that may be better and harder working programmers than he is! The humble shy programmer on that corner cubicle may not say a word but he will definitely be unhappy and start questioning his loyalty towards the organization when he learns of such injustice.
• New managers – a new manager customarily brings on board new people some of whom are possibly his/ her old acquaintances and often agrees to compensate them at levels above those of their peers…

How can a manager tell if the compensation for his department needs to be adjusted?

There is a quick and easy “test” you as a manager can do: just imagine for a moment that you have to get all your direct reports on a room and disclose to them all the details of the compensation of each one of them. Would you feel comfortable doing that? If not then there are two possible explanations:

• You are not compensating them fairly; OR/AND
• There is a gap between your perception and your employees’ perceptions of the value they bring to the organization and you are aware of that discrepancy and that is the cause of you feeling uncomfortable with such potential disclosure.

The latter is the easy case – don’t let the time go by, talk to your employees and make sure your perceptions are aligned – an open, honest conversation will go a long way towards avoiding issues that may arise from disclosure of compensation information.

If you are not compensating them fairly then you need to take action – devise the adjustments you need to make and don’t wait for the next performance review to let your employee know – even if you have to wait to implement the changes when the next budget is approved you can sit down now with each and every one of your direct reports that will be affected and let them know how your plan will affect them. That will show them that you care; that they have not been forgotten, that they matter to you and the organization; that they don’t have to struggle thinking of how to bring up the compensation issue as you have taken the initiative to bring it up and instead they can focus on doing their job to the best of their ability confident that they are not being taken advantage of… The results you will get from those simple actions will be nothing short of outstanding!

Keep in mind though that the above test works only in one direction – in other words, if you wouldn’t be comfortable then you know for sure that something is wrong but being comfortable does not guarantee that everything is ok. It may simply be that you have a perfect compensation structure but it may also be that you are out of touch with reality and you don’t realize the need for action. To determine whether everything is ok or that you are out of touch with reality you can conduct a simple truly anonymous survey to get a feel of what the perception of your employees is. Such survey can contain a few questions like:

• are you happy with your compensation;
• do you think you are being compensated fairly compared to peers within our organization;
• do you think you are being compensated fairly compared to peers across the industry;
• etc

To ensure that you will get true answers I would strongly suggest utilizing a third party to conduct the survey. It is also very critical that the survey be designed professionally to avoid manipulative answers (just one of the pitfalls of such surveys) – example: an unprofessional survey may inadvertently create the impression that the intention of the survey is to justify an increase in the compensation of your employees in which case they will do the best they can to “help” you get your justification! What you will get is a worthless survey that does not tell you anything more than the natural desire of everyone to make more money. Furthermore you would have wasted your time and their time while planting the seeds of unhappiness within your team – they will be disappointed when they see that you simply trashed the survey results.

A professionally designed and conducted survey will provide invaluable insight that will help you tremendously in making the right decisions and building a great team.

Well, this is not meant to be an exhaustive paper on the subject – I have barely scratched the surface and I see that it is already too long a read so I am stopping right here.

Please feel free to leave your comments and suggestions on the subject.

Don't thank me - I am not doing it for you

Have you ever worked for an “over appreciative” boss that uses thank you, great job, awesome job etc. in abundance. If you have you will understand where I am coming from.

When we put ourselves on the line for someone else then a heartfelt thank you is in order; when we deliver a piece of work that is truly impressive because of its superior quality, the efficiency with which it was carried out or some other measurable factor then a "great job" would be appreciated...getting recognized in these cases is necessary, it makes us feel good, it motivates us to do it again, it works.

On the other hand, if you thank me for simply doing my job and praise my average work as awesome it does not work. Most likely the insincerity of your “thankfulness” will be obvious and that will not help, your praise will be meaningless and your “troops” will think of you as a manipulative person; they will start despising you. In the rare cases when you may be so good an actor that you come across as sincerely appreciative the “troops” will consider you an incompetent dummy that has no clue what a good job is and what the responsibilities and duties of the troops are and you will inadvertently cultivate a culture of mediocrity.

So, to all you bosses out there, do yourself and your organization a favor and don't thank me when I am simply doing my job! I am not doing it for you, I am doing it for me; I am doing it because I want to keep my job... don't ever say thank you because you think that is your job to do, only say it when you really mean it! Don’t praise my work because its your job to do that, only praise my work if you truly believe its outstanding. Most of the time let me do my job and you do yours and we don’t need to thank each other; that’s ok, it works.

From the practical point of view however, things are not as clear cut as I am presenting them to be – people are all different and a good boss will need to consider those differences. An inexperienced employee who lacks confidence may need constant re-assurance that he is doing a good job; an emotionally un-stable individual may need re-assurance that the boss is not out to get him; yet another, just wants to be left alone; and so on, and so on… it is not easy to be a boss; people are all different, they come from different cultural backgrounds, they have received widely varied educations, different experiences have shaped them; in short, they all “speak a different language” and managing a group of them effectively is a delicate balancing act.