Yesterday, on a whim I launched SQL Profiler on my laptop. I had not launched the Profiler client for a long time, especially given its deprecated status. All the more, with the recent introduction of XE Profiler within SSMS 17.3, there is even lesser motivation to use the old standalone Profiler. But still… I launched Profiler yesterday and when I tried to connect to my SQL Server 2017 instance, this is what I got:
When you look at the detailed exception information provided this is what we get:
Class not registered
While Profiler is deprecated, it should certainly not throw errors like this. So I decided to take a closer look. With some debugging I figured that somehow Profiler is not able to create a OLEDB connection using the SQLNCLI11 provider. This triggered some ‘connections’ in my mind, because I remembered that I had recently had to uninstall and reinstall the same for usage with the RML Utilities for SQL Server. I figured that somehow those steps might have caused some COM registration issues with SQLNCLI11.DLL. So I executed the following command from an administrative command prompt:
Voila! That fixed the issue. So in the rare event that you are still using Profiler and happen to run into this even more rare error, I hope the simple step to register SQLNCLI11 will help you recover quickly!
EDIT 8 March 2019: The progress reporting of these steps has greatly improved in SQL Server 2019. Individual sub-steps (downloading, installing etc.) are now reported. Thank you for your feedback.
SQL Server 2017 is one more step further in Microsoft’s philosophy of bringing advanced analytics capabilities closer to where the data resides. With Python now supported as an ‘external script’ language (adding to the existing support for R), customers have the full power of Python at their disposal, including external packages like Tensorflow.
Now, what we have seen with some cases is that when the option to install Python has been selected, setup seems to ‘be stuck’ with the string sql_inst_mpyConfigAction_upgrade_confignonrc_Cpu64 being displayed on UI for a while. This is actually not a hang, it is just the setup taking a longer time. The reason for this is that when we install Python with SQL, we have to download and install the Python runtime. That step can take a while, because of the size of the associated packages. If you look at our documentation, you will notice that the size of the Microsoft Python Open component (circled in the screenshot below) is 850MB+). Depending on the speed of the Internet connection that download can take a while!
On top of the time it would take to download, there is an additional step of extracting the various files from within the CAB file into their actual folders within the SQL Server binary folder. That step too takes a while, typically because of disk speeds and also sometimes anti-virus scanning overheads. You can see the progress of that extraction step if you periodically look at the below file (replace the 20170804_162723 date-time stamp folder name with the actual one on your server):
C:\Program Files\Microsoft SQL Server\140\Setup Bootstrap\Log\20170804_162723\RSetup.log
When you look at this file, you will see lines indicating setup is extracting several files. When you close and open the file again, you should notice the timestamp increasing. That will prove to you that SQL Python Setup is indeed progressing and not ‘hung’. In my experience, the overall installation time for this step can be order of magnitude of a few minutes – not too bad, but it can be anxious moments if you just rely on the UI!
- SQL Server 2017 Python setup can take a while, due to file download and file extraction times. A few minutes is normal.
- To save on download times, pre-download the CAB files mentioned above and pass the path to those files using the MRCACHEDIRECTORY command line parameter as shown in this blog post
Happy scripting with Python and SQL Server 2017!