none
SQL Server 2016 Launchpad Error RRS feed

  • Question

  • Greetings,

    We have SQL Server 2016 with CU5 (v13.0.4451.0) configured R Server 9.1.0. When first installed, we had the usual headaches like R Launchpad service not running, temp folder issues, etc. All of these issues have been resolved and we have been developing in our development environment with no issues. 

    Today, when we came to office, none of the scripts ran. All the stored procedures have failed. Running simple R scripts from SQL Management Studio gives the famous error

    Msg 39011, Level 16, State 1, Line 0

    SQL Server was unable to communicate with the LaunchPad service. Please verify the configuration of the service.

    This error normally happens when Launchpad Service is not running. However, it is running and logs are not showing any errors. Restarting SQL Server and the Launchpad Service does not help. Event Viewer shows no errors when the service restarts. We have checked all login permissions, temp folder permission, user access permissions. Everything is intact. The server itself has not been updated, not restarted. Nothing has changed since yesterday. 

    This happened once again and the only solution was to completely remove the R in-database from SQL Server and re-install it. 

    I simply do not understand why it suddenly stops working. I have gone through the list of common issues in the article "Common issues with external script execution in SQL Server" and everything seems to be working just fine. Has anyone faced an issue similar to this? What are the steps to troubleshoot this?

    I would appreciate any insights into this.

    Cheers.


    Thursday, November 16, 2017 10:14 PM

All replies

  • I haven't had the problem you describe myself but one additional thing you might try first is to unbind/rebind R Services with SqlBindR.exe.

    https://docs.microsoft.com/en-us/sql/advanced-analytics/r/use-sqlbindr-exe-to-upgrade-an-instance-of-sql-server

    Also, I can't tell from what you've said above whether or not you looked at the logs in the "ExtensibilityLog" folder. That should have additional details.

    This is usually located in <instanceroot>\MSSQL13.MSSQLSERVER\MSSQL\Log\ExtensibilityLog

    Bob

    Friday, November 17, 2017 1:48 AM