The other day I had a need to get introduced to an individual, let’s call her Jane Doe, who worked for company X. I searched for her on LinkedIn and was delighted to find that she was “in” my network – only one step away, directly connected to my friend “Jon”. So, I ask Jon to introduce me to Jane explaining why I wanted to talk to Jane. Jon’s response was the shocker – he said “I am really sorry but I barely know Jane (translation: I don’t really know Jane). I will send her an email but I am not sure if she will respond or not!” But, that defeats the very purpose of this media I said to myself!
Well. after this I decided to examine my contact list and to my dismay I realized that gradually a good number of individuals that I can’t remember ever meeting has made it into my list of connections! Who are those people? Why are they on my list? What does it really mean to me to have those people in my list and what does it mean to them to be on my list? I certainly can’t vouch for them nor can I rely on them for anything since I don’t know them BUT the very fact that they are on my list of direct connections constitutes some sort of an endorsement. What a mess! What is now the real value of this thing to the end users other than to sales professionals who may use it as a cheap way to compile prospect lists or to marketing professionals who can run highly targeted ads? What motivates someone who has no prospecting interest to waste much valuable time there? I can't find a good answer!
I am not trying to bash LinkedIn here – the concept was great and the implementation near perfect but we the people seem to have ruined a good thing as we often do.
Thursday, August 11, 2011
Wednesday, August 10, 2011
Tech Evangelists – exclusive territories, great potential
If you "live" online and have solid knowledge of databases, especially SQL Server, this may be the perfect gig for you. As a technology evangelist you will promote the use of our database tools through blogging, reviews, demonstrations, presentations etc. You will be compensated for your effort based on your performance. Here are the guidelines:
- if you are selected to be the exclusive tech evangelist for a given territory we will show you the current status of affairs in that territory and establish a baseline based on historical data;
- you will receive $0.1 for every unique visitor to our site, originating from your territory, over the established baseline.
- you will receive $0.5 for every unique product download (your territory only) over the established baseline.
- you will receive 15% commission on all sales on your territory regardless of how the customer found us.
Monday, August 8, 2011
$250 for the most creative use of xSQL Data Compare
Have you used xSQL Data Compare to solve a challenging problem? Send us a short essay describing your scenario and how you made use of xSQL Data Compare and you may win $250.
How will this work?
Please submit your entries via email to info@xsql.com
How will this work?
- All entries submitted from now until November 30, 2011 will be evaluated by an internal commission for:
- Creativity
- Challenge level
- Presentation
- The commission will select 3 winners and the winning entries will be announced no later than December 16, 2011. The prizes are:
- First place winner -> $250
- Second place -> $100
- Third place -> $50
Please submit your entries via email to info@xsql.com
Wednesday, July 6, 2011
Major release: SQL Server Data Compare 4
Coming 7 years after the release of the very first version of xSQL Data Compare, the new xSQL Data Compare for SQL Server version 4 reflects a wealth of accumulated experience, countless comments and suggestions we have received from you over those years, and the latest trends in software architecting and design.
Quick links:
Important notes:
Stay connected: - follow us on Twitter http://twitter.com/xsqlsoftware, and like us on Facebook http://www.facebook.com/xsqlsoftware. Also, next time you stop by our site don't forget to click on those "like" buttons on our product pages. As always, your comments, suggestions, and your critique are greatly appreciated!
Quick links:
Important notes:
- Have an active upgrade subscription? You do not need to contact us. In the next 3-5 days you will receive your new license.
- Have a licensed version installed already? Please note that the new version installs on top of the existing version but the license you have will not work with the new version.
- Single edition: when you visit our site you will notice that there are no more standard and professional editions available. There is only one edition that includes everything.
Stay connected: - follow us on Twitter http://twitter.com/xsqlsoftware, and like us on Facebook http://www.facebook.com/xsqlsoftware. Also, next time you stop by our site don't forget to click on those "like" buttons on our product pages. As always, your comments, suggestions, and your critique are greatly appreciated!
Thursday, March 17, 2011
Why is SQL Server doing a clustered index scan?
This is a simple real life scenario I ran into recently. Client is experiencing performance issues with SQL Server. A quick investigation reveals that a certain table, let's call it MyTable which contains over 50 million rows seems to be the source of contention. In particular there is a frequently run, innocent looking query that is causing the trouble. The query looks something like this
SELECT c1, c2 FROM MyTable WHERE MyTable_PK BETWEEN 5 and 9
The execution plan shows that the SQL Server query optimizer has decided to do a clustered index scan on the primary key (terribly expensive on a large table like this). Why can't the query optimizer "see" that an index seek would be significantly more efficient than the scan? Upon closer examination I realized that an implicit conversion of the PK is happening. Now I can see the light – I check the table structure and realize that the Primary Key column has been defined as a varchar and that is being compared with integer values. That is what's "tricking" the query optimizer into picking the wrong plan. A little tweak:
SELECT * FROM MyTable WHERE MyTable_PK IN (' 5', '6', '7',' 8', '9')
Success - now instead of scanning 50 million rows the query optimizer has picked the right plan, that is, it is doing a quick index seek and getting the rows we need in a fraction of the time. All the contention disappears – everybody is happy!
Note: the real query was much more complex and the tweak is not necessarily as simple, but the point here is to highlight the fact that if the type of the index column does not match the type of the values with which it is being compared then the index is rather useless.
SELECT c1, c2 FROM MyTable WHERE MyTable_PK BETWEEN 5 and 9
The execution plan shows that the SQL Server query optimizer has decided to do a clustered index scan on the primary key (terribly expensive on a large table like this). Why can't the query optimizer "see" that an index seek would be significantly more efficient than the scan? Upon closer examination I realized that an implicit conversion of the PK is happening. Now I can see the light – I check the table structure and realize that the Primary Key column has been defined as a varchar and that is being compared with integer values. That is what's "tricking" the query optimizer into picking the wrong plan. A little tweak:
SELECT * FROM MyTable WHERE MyTable_PK IN (' 5', '6', '7',' 8', '9')
Success - now instead of scanning 50 million rows the query optimizer has picked the right plan, that is, it is doing a quick index seek and getting the rows we need in a fraction of the time. All the contention disappears – everybody is happy!
Note: the real query was much more complex and the tweak is not necessarily as simple, but the point here is to highlight the fact that if the type of the index column does not match the type of the values with which it is being compared then the index is rather useless.
Tuesday, February 15, 2011
Script Executor for MySQL free today
Today and tomorrow only (February 15-16, 2011) you can get a free license for Script Executor for MySQL - simply plug in the MYSQLEX11 discount code on the shopping cart page - the price will go down to $0 and you will not be asked to provide any payment information. One license per customer only please.
Script Executor is one of the best tools for deploying t-sql scripts to your database server "farm". Whether you are running MySQL, DB2, SQL Server or a combination of those platforms, Script Executor allows you to easily create deployment packages involving hundreds of scripts that have to be executed in a certain order targeting as many servers as you need on any of those platforms, simultaneously.
Download a free, fully functional trial version and see for yourself what you have been missing until now: http://www.xsql.com/download/script_executor/
Script Executor is one of the best tools for deploying t-sql scripts to your database server "farm". Whether you are running MySQL, DB2, SQL Server or a combination of those platforms, Script Executor allows you to easily create deployment packages involving hundreds of scripts that have to be executed in a certain order targeting as many servers as you need on any of those platforms, simultaneously.
Download a free, fully functional trial version and see for yourself what you have been missing until now: http://www.xsql.com/download/script_executor/
Tuesday, January 18, 2011
Don’t rename SPs, UDFs and Views – drop and create instead
When developers at client X need to make changes to an SP (let’s call that SP1) they usually go through those simple steps:
With SQL Server 2008 Microsoft decided to eliminate this little annoyance, so now step 3 above will work just fine, the new SP1 is created successfully and you will be happy until you decide to look into SYS.sql_modules and realize that you now have two SPs with identical names in the definition. Fine, that’s not the end of the World you say. But just for a little fun try executing the sp_refreshsqlmodule 'dbo.SP1_Backup' - this should be completely harmless, simply updates the outdated metadata right? Well, try looking into SYS.sql_modules again after you execute that – surprise, all the work you did on SP1 just disappeared! Now, the definition of the SP1 is exactly the same as that of SP1_backup. Definitely not what you wanted or expected!
The renaming issue has been there forever – they (Microsoft) must have a pretty good reason for not fixing it, so I am assuming it will never be fixed. In the meantime the advise to SSMS user is: when it comes to SPs, UDFs and Views just pretend that the rename functionality does not exist – if you want to rename such an object script it out, change the name in the CREATE statement and execute the script; then just drop the original object.
- Script SP1 out as CREATE
- Right click on SP1 on the left panel and rename it to SP1_backup
- Work with the script and when done with the changes execute it to create the new SP1
With SQL Server 2008 Microsoft decided to eliminate this little annoyance, so now step 3 above will work just fine, the new SP1 is created successfully and you will be happy until you decide to look into SYS.sql_modules and realize that you now have two SPs with identical names in the definition. Fine, that’s not the end of the World you say. But just for a little fun try executing the sp_refreshsqlmodule 'dbo.SP1_Backup' - this should be completely harmless, simply updates the outdated metadata right? Well, try looking into SYS.sql_modules again after you execute that – surprise, all the work you did on SP1 just disappeared! Now, the definition of the SP1 is exactly the same as that of SP1_backup. Definitely not what you wanted or expected!
The renaming issue has been there forever – they (Microsoft) must have a pretty good reason for not fixing it, so I am assuming it will never be fixed. In the meantime the advise to SSMS user is: when it comes to SPs, UDFs and Views just pretend that the rename functionality does not exist – if you want to rename such an object script it out, change the name in the CREATE statement and execute the script; then just drop the original object.
Subscribe to:
Posts (Atom)