Net stop system error 5 access denied





.everyoneloves__top-leaderboard:empty,.everyoneloves__mid-leaderboard:empty,.everyoneloves__bot-mid-leaderboard:empty{ height:90px;width:728px;box-sizing:border-box;
}







1















From SQL server 2012 I try to do this:



DECLARE @COMMAND nvarchar(4000)
SET @COMMAND = 'net stop <servicename>'
exec master.dbo.xp_cmdshell @COMMAND


I get system error 5 and Access denied as response



The service account (checked with whoami) is added to the administrators, so what else can be wrong?










share|improve this question

























  • when you way 'From SQLServer 2012', do you mean from SQLServer Management Studio (ssms.exe) ?

    – Frank Thomas
    Aug 11 '17 at 15:31













  • Yes, if I put the command(s) in a .bat or .cmd and run that from the OS it's fine. When I try to run it from ssms I get the same error.

    – Sjef
    Aug 14 '17 at 13:29











  • run ssms as admin.

    – Frank Thomas
    Aug 14 '17 at 13:39


















1















From SQL server 2012 I try to do this:



DECLARE @COMMAND nvarchar(4000)
SET @COMMAND = 'net stop <servicename>'
exec master.dbo.xp_cmdshell @COMMAND


I get system error 5 and Access denied as response



The service account (checked with whoami) is added to the administrators, so what else can be wrong?










share|improve this question

























  • when you way 'From SQLServer 2012', do you mean from SQLServer Management Studio (ssms.exe) ?

    – Frank Thomas
    Aug 11 '17 at 15:31













  • Yes, if I put the command(s) in a .bat or .cmd and run that from the OS it's fine. When I try to run it from ssms I get the same error.

    – Sjef
    Aug 14 '17 at 13:29











  • run ssms as admin.

    – Frank Thomas
    Aug 14 '17 at 13:39














1












1








1








From SQL server 2012 I try to do this:



DECLARE @COMMAND nvarchar(4000)
SET @COMMAND = 'net stop <servicename>'
exec master.dbo.xp_cmdshell @COMMAND


I get system error 5 and Access denied as response



The service account (checked with whoami) is added to the administrators, so what else can be wrong?










share|improve this question
















From SQL server 2012 I try to do this:



DECLARE @COMMAND nvarchar(4000)
SET @COMMAND = 'net stop <servicename>'
exec master.dbo.xp_cmdshell @COMMAND


I get system error 5 and Access denied as response



The service account (checked with whoami) is added to the administrators, so what else can be wrong?







command-line sql-server-2012






share|improve this question















share|improve this question













share|improve this question




share|improve this question








edited Aug 11 '17 at 12:07









DavidPostill

108k27235271




108k27235271










asked Aug 11 '17 at 11:27









SjefSjef

62




62













  • when you way 'From SQLServer 2012', do you mean from SQLServer Management Studio (ssms.exe) ?

    – Frank Thomas
    Aug 11 '17 at 15:31













  • Yes, if I put the command(s) in a .bat or .cmd and run that from the OS it's fine. When I try to run it from ssms I get the same error.

    – Sjef
    Aug 14 '17 at 13:29











  • run ssms as admin.

    – Frank Thomas
    Aug 14 '17 at 13:39



















  • when you way 'From SQLServer 2012', do you mean from SQLServer Management Studio (ssms.exe) ?

    – Frank Thomas
    Aug 11 '17 at 15:31













  • Yes, if I put the command(s) in a .bat or .cmd and run that from the OS it's fine. When I try to run it from ssms I get the same error.

    – Sjef
    Aug 14 '17 at 13:29











  • run ssms as admin.

    – Frank Thomas
    Aug 14 '17 at 13:39

















when you way 'From SQLServer 2012', do you mean from SQLServer Management Studio (ssms.exe) ?

– Frank Thomas
Aug 11 '17 at 15:31







when you way 'From SQLServer 2012', do you mean from SQLServer Management Studio (ssms.exe) ?

– Frank Thomas
Aug 11 '17 at 15:31















Yes, if I put the command(s) in a .bat or .cmd and run that from the OS it's fine. When I try to run it from ssms I get the same error.

– Sjef
Aug 14 '17 at 13:29





Yes, if I put the command(s) in a .bat or .cmd and run that from the OS it's fine. When I try to run it from ssms I get the same error.

– Sjef
Aug 14 '17 at 13:29













run ssms as admin.

– Frank Thomas
Aug 14 '17 at 13:39





run ssms as admin.

– Frank Thomas
Aug 14 '17 at 13:39










2 Answers
2






active

oldest

votes


















0














Run SQL Server 2012 as administrator, and the problem will go away.






share|improve this answer
























  • The service account mentioned has administrator rights.

    – Sjef
    Aug 11 '17 at 13:52











  • Yes, but even so, the runtime has to be performed as administrator. You have to right-click the program, and choose run as administrator, to give the application extra rights. You can see the exact same behavior if you try to do the command in a command prompt window. Even if your user has admin rights, it will not work until you launch the command prompt as administrator. Its an UAC thing.

    – LPChip
    Aug 11 '17 at 14:25











  • In this case, the user running the DB service is unimportant to the issue. The issue is who can CONTROL the service, by starting/stopping/editing the service. SQL Injection attacks would be disastrous if just any old user could execute xp_cmdshell and by virtue of the SQLServers privileged access be able to run arbitrary commands as a server admin.

    – Frank Thomas
    Aug 11 '17 at 15:34



















0














Allow non-sysadmin user to execute xp_cmdshell from SSMS



I helped troubleshoot an issue where we needed to grant an app developer access to execute xp_cmdshell from within an SSMS session rather than "Run as" from SQL Agent Job on a non-critical development server without making him a sysadmin on the SQL Server instance.



What We Did



Note: Domain user account can be replaced by work group account, local machine account, etc.



Important: You need to understand the risk of allowing users in your environment to execute OS level commands, and you should only grant this level of permissions to xp_cmdshell to those which are trustworthy enough with this level of security with the proxy method.




  1. Created a new domain user account with a strong password and took note of the username and password. Made sure the account was enabled and the password was set to never expire.


  2. Created a new SQL Server Login tied to the new domain user account we created.



  3. Created a new proxy credential tied to the domain user account.




    EXEC sp_xp_cmdshell_proxy_account '<Domain><NewUser>', '<password>' -- you have to type actual password




  4. Granted that SQL Server Login explicit EXECUTE access to the system extended stored proc from the Master DB named sys.xp_cmdshell.




    --see who all has execute access to xp_cmdshell   
    Use master
    EXEC sp_helprotect 'xp_cmdshell'


    -- To allow advanced options to be changed.
    EXEC sp_configure 'show advanced options', 1
    RECONFIGURE
    GO

    -- Enable the xp_cmdshell procedure
    EXEC sp_configure 'xp_cmdshell', 1
    RECONFIGURE
    GO

    -- Grant execute permissions to account
    GRANT EXECUTE ON xp_cmdshell TO [<Domain><NewUser>]




  5. Grant the person the uses the EXECUTE AS impersonate permission to the new SQL Server Login.




    GRANT IMPERSONATE ON LOGIN::[<Domain><NewUser>] TO [<Domain><UserGrantingExecuteAsUser>]




  6. Now run the command with the EXECUTE AS LOGIN and pass the net stop command to the xp_cmdshell stored procedure. The security principal as listed in step #5 above in the <Domain><UserGrantingExecuteAsUser> should be that of the person you are running SSMS as security context wise for this task.




    EXECUTE AS LOGIN = '<Domain><NewUser>'
    DECLARE @COMMAND nvarchar(4000)
    SET @COMMAND = 'net stop <servicename>'
    EXEC xp_cmdshell @COMMAND
    REVERT






Further Resources




  • sp_xp_cmdshell_proxy_account

  • CREATE USER (Transact-SQL)

  • GRANT Server Principal Permissions (Transact-SQL)

  • EXECUTE AS (Transact-SQL)






share|improve this answer


























    Your Answer








    StackExchange.ready(function() {
    var channelOptions = {
    tags: "".split(" "),
    id: "3"
    };
    initTagRenderer("".split(" "), "".split(" "), channelOptions);

    StackExchange.using("externalEditor", function() {
    // Have to fire editor after snippets, if snippets enabled
    if (StackExchange.settings.snippets.snippetsEnabled) {
    StackExchange.using("snippets", function() {
    createEditor();
    });
    }
    else {
    createEditor();
    }
    });

    function createEditor() {
    StackExchange.prepareEditor({
    heartbeatType: 'answer',
    autoActivateHeartbeat: false,
    convertImagesToLinks: true,
    noModals: true,
    showLowRepImageUploadWarning: true,
    reputationToPostImages: 10,
    bindNavPrevention: true,
    postfix: "",
    imageUploader: {
    brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
    contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
    allowUrls: true
    },
    onDemand: true,
    discardSelector: ".discard-answer"
    ,immediatelyShowMarkdownHelp:true
    });


    }
    });














    draft saved

    draft discarded


















    StackExchange.ready(
    function () {
    StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fsuperuser.com%2fquestions%2f1239888%2fnet-stop-service-system-error-5-access-denied%23new-answer', 'question_page');
    }
    );

    Post as a guest















    Required, but never shown

























    2 Answers
    2






    active

    oldest

    votes








    2 Answers
    2






    active

    oldest

    votes









    active

    oldest

    votes






    active

    oldest

    votes









    0














    Run SQL Server 2012 as administrator, and the problem will go away.






    share|improve this answer
























    • The service account mentioned has administrator rights.

      – Sjef
      Aug 11 '17 at 13:52











    • Yes, but even so, the runtime has to be performed as administrator. You have to right-click the program, and choose run as administrator, to give the application extra rights. You can see the exact same behavior if you try to do the command in a command prompt window. Even if your user has admin rights, it will not work until you launch the command prompt as administrator. Its an UAC thing.

      – LPChip
      Aug 11 '17 at 14:25











    • In this case, the user running the DB service is unimportant to the issue. The issue is who can CONTROL the service, by starting/stopping/editing the service. SQL Injection attacks would be disastrous if just any old user could execute xp_cmdshell and by virtue of the SQLServers privileged access be able to run arbitrary commands as a server admin.

      – Frank Thomas
      Aug 11 '17 at 15:34
















    0














    Run SQL Server 2012 as administrator, and the problem will go away.






    share|improve this answer
























    • The service account mentioned has administrator rights.

      – Sjef
      Aug 11 '17 at 13:52











    • Yes, but even so, the runtime has to be performed as administrator. You have to right-click the program, and choose run as administrator, to give the application extra rights. You can see the exact same behavior if you try to do the command in a command prompt window. Even if your user has admin rights, it will not work until you launch the command prompt as administrator. Its an UAC thing.

      – LPChip
      Aug 11 '17 at 14:25











    • In this case, the user running the DB service is unimportant to the issue. The issue is who can CONTROL the service, by starting/stopping/editing the service. SQL Injection attacks would be disastrous if just any old user could execute xp_cmdshell and by virtue of the SQLServers privileged access be able to run arbitrary commands as a server admin.

      – Frank Thomas
      Aug 11 '17 at 15:34














    0












    0








    0







    Run SQL Server 2012 as administrator, and the problem will go away.






    share|improve this answer













    Run SQL Server 2012 as administrator, and the problem will go away.







    share|improve this answer












    share|improve this answer



    share|improve this answer










    answered Aug 11 '17 at 12:30









    LPChipLPChip

    36.8k55588




    36.8k55588













    • The service account mentioned has administrator rights.

      – Sjef
      Aug 11 '17 at 13:52











    • Yes, but even so, the runtime has to be performed as administrator. You have to right-click the program, and choose run as administrator, to give the application extra rights. You can see the exact same behavior if you try to do the command in a command prompt window. Even if your user has admin rights, it will not work until you launch the command prompt as administrator. Its an UAC thing.

      – LPChip
      Aug 11 '17 at 14:25











    • In this case, the user running the DB service is unimportant to the issue. The issue is who can CONTROL the service, by starting/stopping/editing the service. SQL Injection attacks would be disastrous if just any old user could execute xp_cmdshell and by virtue of the SQLServers privileged access be able to run arbitrary commands as a server admin.

      – Frank Thomas
      Aug 11 '17 at 15:34



















    • The service account mentioned has administrator rights.

      – Sjef
      Aug 11 '17 at 13:52











    • Yes, but even so, the runtime has to be performed as administrator. You have to right-click the program, and choose run as administrator, to give the application extra rights. You can see the exact same behavior if you try to do the command in a command prompt window. Even if your user has admin rights, it will not work until you launch the command prompt as administrator. Its an UAC thing.

      – LPChip
      Aug 11 '17 at 14:25











    • In this case, the user running the DB service is unimportant to the issue. The issue is who can CONTROL the service, by starting/stopping/editing the service. SQL Injection attacks would be disastrous if just any old user could execute xp_cmdshell and by virtue of the SQLServers privileged access be able to run arbitrary commands as a server admin.

      – Frank Thomas
      Aug 11 '17 at 15:34

















    The service account mentioned has administrator rights.

    – Sjef
    Aug 11 '17 at 13:52





    The service account mentioned has administrator rights.

    – Sjef
    Aug 11 '17 at 13:52













    Yes, but even so, the runtime has to be performed as administrator. You have to right-click the program, and choose run as administrator, to give the application extra rights. You can see the exact same behavior if you try to do the command in a command prompt window. Even if your user has admin rights, it will not work until you launch the command prompt as administrator. Its an UAC thing.

    – LPChip
    Aug 11 '17 at 14:25





    Yes, but even so, the runtime has to be performed as administrator. You have to right-click the program, and choose run as administrator, to give the application extra rights. You can see the exact same behavior if you try to do the command in a command prompt window. Even if your user has admin rights, it will not work until you launch the command prompt as administrator. Its an UAC thing.

    – LPChip
    Aug 11 '17 at 14:25













    In this case, the user running the DB service is unimportant to the issue. The issue is who can CONTROL the service, by starting/stopping/editing the service. SQL Injection attacks would be disastrous if just any old user could execute xp_cmdshell and by virtue of the SQLServers privileged access be able to run arbitrary commands as a server admin.

    – Frank Thomas
    Aug 11 '17 at 15:34





    In this case, the user running the DB service is unimportant to the issue. The issue is who can CONTROL the service, by starting/stopping/editing the service. SQL Injection attacks would be disastrous if just any old user could execute xp_cmdshell and by virtue of the SQLServers privileged access be able to run arbitrary commands as a server admin.

    – Frank Thomas
    Aug 11 '17 at 15:34













    0














    Allow non-sysadmin user to execute xp_cmdshell from SSMS



    I helped troubleshoot an issue where we needed to grant an app developer access to execute xp_cmdshell from within an SSMS session rather than "Run as" from SQL Agent Job on a non-critical development server without making him a sysadmin on the SQL Server instance.



    What We Did



    Note: Domain user account can be replaced by work group account, local machine account, etc.



    Important: You need to understand the risk of allowing users in your environment to execute OS level commands, and you should only grant this level of permissions to xp_cmdshell to those which are trustworthy enough with this level of security with the proxy method.




    1. Created a new domain user account with a strong password and took note of the username and password. Made sure the account was enabled and the password was set to never expire.


    2. Created a new SQL Server Login tied to the new domain user account we created.



    3. Created a new proxy credential tied to the domain user account.




      EXEC sp_xp_cmdshell_proxy_account '<Domain><NewUser>', '<password>' -- you have to type actual password




    4. Granted that SQL Server Login explicit EXECUTE access to the system extended stored proc from the Master DB named sys.xp_cmdshell.




      --see who all has execute access to xp_cmdshell   
      Use master
      EXEC sp_helprotect 'xp_cmdshell'


      -- To allow advanced options to be changed.
      EXEC sp_configure 'show advanced options', 1
      RECONFIGURE
      GO

      -- Enable the xp_cmdshell procedure
      EXEC sp_configure 'xp_cmdshell', 1
      RECONFIGURE
      GO

      -- Grant execute permissions to account
      GRANT EXECUTE ON xp_cmdshell TO [<Domain><NewUser>]




    5. Grant the person the uses the EXECUTE AS impersonate permission to the new SQL Server Login.




      GRANT IMPERSONATE ON LOGIN::[<Domain><NewUser>] TO [<Domain><UserGrantingExecuteAsUser>]




    6. Now run the command with the EXECUTE AS LOGIN and pass the net stop command to the xp_cmdshell stored procedure. The security principal as listed in step #5 above in the <Domain><UserGrantingExecuteAsUser> should be that of the person you are running SSMS as security context wise for this task.




      EXECUTE AS LOGIN = '<Domain><NewUser>'
      DECLARE @COMMAND nvarchar(4000)
      SET @COMMAND = 'net stop <servicename>'
      EXEC xp_cmdshell @COMMAND
      REVERT






    Further Resources




    • sp_xp_cmdshell_proxy_account

    • CREATE USER (Transact-SQL)

    • GRANT Server Principal Permissions (Transact-SQL)

    • EXECUTE AS (Transact-SQL)






    share|improve this answer






























      0














      Allow non-sysadmin user to execute xp_cmdshell from SSMS



      I helped troubleshoot an issue where we needed to grant an app developer access to execute xp_cmdshell from within an SSMS session rather than "Run as" from SQL Agent Job on a non-critical development server without making him a sysadmin on the SQL Server instance.



      What We Did



      Note: Domain user account can be replaced by work group account, local machine account, etc.



      Important: You need to understand the risk of allowing users in your environment to execute OS level commands, and you should only grant this level of permissions to xp_cmdshell to those which are trustworthy enough with this level of security with the proxy method.




      1. Created a new domain user account with a strong password and took note of the username and password. Made sure the account was enabled and the password was set to never expire.


      2. Created a new SQL Server Login tied to the new domain user account we created.



      3. Created a new proxy credential tied to the domain user account.




        EXEC sp_xp_cmdshell_proxy_account '<Domain><NewUser>', '<password>' -- you have to type actual password




      4. Granted that SQL Server Login explicit EXECUTE access to the system extended stored proc from the Master DB named sys.xp_cmdshell.




        --see who all has execute access to xp_cmdshell   
        Use master
        EXEC sp_helprotect 'xp_cmdshell'


        -- To allow advanced options to be changed.
        EXEC sp_configure 'show advanced options', 1
        RECONFIGURE
        GO

        -- Enable the xp_cmdshell procedure
        EXEC sp_configure 'xp_cmdshell', 1
        RECONFIGURE
        GO

        -- Grant execute permissions to account
        GRANT EXECUTE ON xp_cmdshell TO [<Domain><NewUser>]




      5. Grant the person the uses the EXECUTE AS impersonate permission to the new SQL Server Login.




        GRANT IMPERSONATE ON LOGIN::[<Domain><NewUser>] TO [<Domain><UserGrantingExecuteAsUser>]




      6. Now run the command with the EXECUTE AS LOGIN and pass the net stop command to the xp_cmdshell stored procedure. The security principal as listed in step #5 above in the <Domain><UserGrantingExecuteAsUser> should be that of the person you are running SSMS as security context wise for this task.




        EXECUTE AS LOGIN = '<Domain><NewUser>'
        DECLARE @COMMAND nvarchar(4000)
        SET @COMMAND = 'net stop <servicename>'
        EXEC xp_cmdshell @COMMAND
        REVERT






      Further Resources




      • sp_xp_cmdshell_proxy_account

      • CREATE USER (Transact-SQL)

      • GRANT Server Principal Permissions (Transact-SQL)

      • EXECUTE AS (Transact-SQL)






      share|improve this answer




























        0












        0








        0







        Allow non-sysadmin user to execute xp_cmdshell from SSMS



        I helped troubleshoot an issue where we needed to grant an app developer access to execute xp_cmdshell from within an SSMS session rather than "Run as" from SQL Agent Job on a non-critical development server without making him a sysadmin on the SQL Server instance.



        What We Did



        Note: Domain user account can be replaced by work group account, local machine account, etc.



        Important: You need to understand the risk of allowing users in your environment to execute OS level commands, and you should only grant this level of permissions to xp_cmdshell to those which are trustworthy enough with this level of security with the proxy method.




        1. Created a new domain user account with a strong password and took note of the username and password. Made sure the account was enabled and the password was set to never expire.


        2. Created a new SQL Server Login tied to the new domain user account we created.



        3. Created a new proxy credential tied to the domain user account.




          EXEC sp_xp_cmdshell_proxy_account '<Domain><NewUser>', '<password>' -- you have to type actual password




        4. Granted that SQL Server Login explicit EXECUTE access to the system extended stored proc from the Master DB named sys.xp_cmdshell.




          --see who all has execute access to xp_cmdshell   
          Use master
          EXEC sp_helprotect 'xp_cmdshell'


          -- To allow advanced options to be changed.
          EXEC sp_configure 'show advanced options', 1
          RECONFIGURE
          GO

          -- Enable the xp_cmdshell procedure
          EXEC sp_configure 'xp_cmdshell', 1
          RECONFIGURE
          GO

          -- Grant execute permissions to account
          GRANT EXECUTE ON xp_cmdshell TO [<Domain><NewUser>]




        5. Grant the person the uses the EXECUTE AS impersonate permission to the new SQL Server Login.




          GRANT IMPERSONATE ON LOGIN::[<Domain><NewUser>] TO [<Domain><UserGrantingExecuteAsUser>]




        6. Now run the command with the EXECUTE AS LOGIN and pass the net stop command to the xp_cmdshell stored procedure. The security principal as listed in step #5 above in the <Domain><UserGrantingExecuteAsUser> should be that of the person you are running SSMS as security context wise for this task.




          EXECUTE AS LOGIN = '<Domain><NewUser>'
          DECLARE @COMMAND nvarchar(4000)
          SET @COMMAND = 'net stop <servicename>'
          EXEC xp_cmdshell @COMMAND
          REVERT






        Further Resources




        • sp_xp_cmdshell_proxy_account

        • CREATE USER (Transact-SQL)

        • GRANT Server Principal Permissions (Transact-SQL)

        • EXECUTE AS (Transact-SQL)






        share|improve this answer















        Allow non-sysadmin user to execute xp_cmdshell from SSMS



        I helped troubleshoot an issue where we needed to grant an app developer access to execute xp_cmdshell from within an SSMS session rather than "Run as" from SQL Agent Job on a non-critical development server without making him a sysadmin on the SQL Server instance.



        What We Did



        Note: Domain user account can be replaced by work group account, local machine account, etc.



        Important: You need to understand the risk of allowing users in your environment to execute OS level commands, and you should only grant this level of permissions to xp_cmdshell to those which are trustworthy enough with this level of security with the proxy method.




        1. Created a new domain user account with a strong password and took note of the username and password. Made sure the account was enabled and the password was set to never expire.


        2. Created a new SQL Server Login tied to the new domain user account we created.



        3. Created a new proxy credential tied to the domain user account.




          EXEC sp_xp_cmdshell_proxy_account '<Domain><NewUser>', '<password>' -- you have to type actual password




        4. Granted that SQL Server Login explicit EXECUTE access to the system extended stored proc from the Master DB named sys.xp_cmdshell.




          --see who all has execute access to xp_cmdshell   
          Use master
          EXEC sp_helprotect 'xp_cmdshell'


          -- To allow advanced options to be changed.
          EXEC sp_configure 'show advanced options', 1
          RECONFIGURE
          GO

          -- Enable the xp_cmdshell procedure
          EXEC sp_configure 'xp_cmdshell', 1
          RECONFIGURE
          GO

          -- Grant execute permissions to account
          GRANT EXECUTE ON xp_cmdshell TO [<Domain><NewUser>]




        5. Grant the person the uses the EXECUTE AS impersonate permission to the new SQL Server Login.




          GRANT IMPERSONATE ON LOGIN::[<Domain><NewUser>] TO [<Domain><UserGrantingExecuteAsUser>]




        6. Now run the command with the EXECUTE AS LOGIN and pass the net stop command to the xp_cmdshell stored procedure. The security principal as listed in step #5 above in the <Domain><UserGrantingExecuteAsUser> should be that of the person you are running SSMS as security context wise for this task.




          EXECUTE AS LOGIN = '<Domain><NewUser>'
          DECLARE @COMMAND nvarchar(4000)
          SET @COMMAND = 'net stop <servicename>'
          EXEC xp_cmdshell @COMMAND
          REVERT






        Further Resources




        • sp_xp_cmdshell_proxy_account

        • CREATE USER (Transact-SQL)

        • GRANT Server Principal Permissions (Transact-SQL)

        • EXECUTE AS (Transact-SQL)







        share|improve this answer














        share|improve this answer



        share|improve this answer








        edited Aug 21 '17 at 22:30

























        answered Aug 21 '17 at 18:07









        Pimp Juice ITPimp Juice IT

        25.4k114178




        25.4k114178






























            draft saved

            draft discarded




















































            Thanks for contributing an answer to Super User!


            • Please be sure to answer the question. Provide details and share your research!

            But avoid



            • Asking for help, clarification, or responding to other answers.

            • Making statements based on opinion; back them up with references or personal experience.


            To learn more, see our tips on writing great answers.




            draft saved


            draft discarded














            StackExchange.ready(
            function () {
            StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fsuperuser.com%2fquestions%2f1239888%2fnet-stop-service-system-error-5-access-denied%23new-answer', 'question_page');
            }
            );

            Post as a guest















            Required, but never shown





















































            Required, but never shown














            Required, but never shown












            Required, but never shown







            Required, but never shown

































            Required, but never shown














            Required, but never shown












            Required, but never shown







            Required, but never shown







            Popular posts from this blog

            Probability when a professor distributes a quiz and homework assignment to a class of n students.

            Aardman Animations

            Are they similar matrix