Det forekommer mig, at du ikke venter på en SQL-kode i svaret på dit spørgsmål. Hovedaspektet af dit spørgsmål er sikkerhedsaspektet. Hvad skal du gøre for at implementere dit krav uden sysadmin privilegier og uden et nyt sikkerhedshul? Dette er dit rigtige spørgsmål, tror jeg.
Jeg ser mindst 3 måder at løse dit problem på. Men først og fremmest en kort forklaring på, hvorfor sysadmin-rettigheder findes i alle løsninger baseret på Udvidede lagrede procedurer . Udvidede lagrede procedurer som xp_cmdshell er meget gamle. De eksisterede i det mindste før SQL Server 4.2, den første Microsoft SQL Server, der kørte under det første Windows NT (NT 3.1). I den gamle version af SQL Server var jeg ikke sikkerhedsbegrænset til at udføre sådanne procedurer, men senere lavede man sådanne begrænsninger. Det er vigtigt at forstå, at alle generelle formål procedurer, der gør det muligt at starte enhver proces under SQL Server-konto som xp_cmdshell og sp_OACreate skal har sysadmin begrænsning af privilegier. Kun en opgaveorienteret procedurer med et klart brugsområde og rollebaserede tilladelser kan løse problemet uden et sikkerhedshul. Så dette er de 3 løsningsmåder, som jeg lovede før:
- Du opretter en ny SQL-konto på din SQL-server med sysadmin privilegier. Derefter opretter du en lagret procedure, som bruger nogle fra Udvidede lagrede procedurer som
xp_cmdshellellersp_OACreateog implementere dine krav teknisk (eksporter nogle oplysninger til en CSV-fil). Med respekt for EXECUTE AS Klausul (se http://msdn.microsoft.com/en-us/ library/ms188354.aspx ) du konfigurerer den oprettede lagrede procedure, så den kører under kontoen med sysadmin privilegier. Du uddelegerer udførelsen af denne procedure til brugere med en eller anden SQL-rolle for at være mere fleksibel fra siden af delegering af tilladelser. - Du kan bruge CLR Stored Procedures i stedet for
xp_cmdshellogsp_OACreate. Du bør også bruge rollebaserede tilladelser på den oprettede procedure. - Slutbrugeren kalder ikke direkte nogen SQL-lagret procedure, hvad du opretter. Der findes et stykke software (som WCF-tjeneste eller et websted), som kalder din SQL-lagrede procedure. Du kan implementere eksporten til CSV-fil inde i denne software og ikke inde i nogen SQL-lagret procedure.
På alle implementeringsmåder bør du præcist definere hvor du vil opbevare adgangskoden af den konto, som du får adgang til filsystemet med. Der er forskellige muligheder, som du har, alle med tilsvarende fordele og ulemper. Det er muligt at bruge personefterligning til at give adgang til filsystemet med slutbrugerens konto. Den bedste måde afhænger af den situation, du har i dit miljø.