9 июля 2012 г. 18:28
First, I have read through the numerous posts on this topic and now of the provided solutions have worked. So I post my specidifc issue.
Using VSTA2008 from SQL2008 STD edition.
Using local machine for development. I am the local and domain admin.
The path that I am denied access to is the Local C:\TEMP directory.
In BId, I now have two scripts that run. the first script sets the file level permissions to full control under the context of the task that is being run.
The secong task performs a PGP decryption of the files. This is were I get the error. I can set the file permissions with out an issue, yet as soon as I caaess the same files to decrypt them, I get the error. The error is being thrown as soon as I access the files. The PGP decryption routine will run when attached to a windows forms project on the same machine. This is how I was able to test and debug the code prior to adding it to the SSIS Task.
In total the job picks up a file from an FTP site, moves it to the local machine, decrypts file, then pipes it along for further processing. The only point of failure is in the one script task. and I am at a loss.
Let me add this in case it is relevant. in the affected script, I reference a third party dll (bouncycastle.crypto) for the PGP encrypt/decrypt utilities. A second code (class) file exists that performs all of the logic, and i call it from the script main() passing in the validated arguments.
If anyone has any ideas, I am open to any and all suggestions.
Thanks in advance.
9 июля 2012 г. 18:37Модератор
SQL Agent job?
The account then has no access to %temp% dir, fix by running the job with the proxy account
Arthur My Blog
9 июля 2012 г. 18:50
I haven't gotten far enough to run an agent job. i am running in the Dev environment under my credentials. I am running the dev env "as administrator" as that was suggested as a possible solution in one of the threads.
9 июля 2012 г. 18:54МодераторTake the Process Explorer and find out what requests the access to the temp folder and what happens next. I am under an impression the other script runs under its own under-elevated rights and thus cannot access it.
Arthur My Blog
9 июля 2012 г. 19:06
9 июля 2012 г. 19:10Модераторyes, it is a special tool: http://technet.microsoft.com/en-us/sysinternals/bb896653.aspx
Arthur My Blog
9 июля 2012 г. 19:13
(smack's Head with palm of hand) OH! that process explorer!
All processes spawned by the DevEnv are run under my cred's.
- Изменено HallMarc 9 июля 2012 г. 19:24
9 июля 2012 г. 20:01
you can give a try with UNC path say "C:\Users\usersName\AppData\Local\Temp" or whatever instead of %temp%. in one scenario, we faced this kind of issues. also, please note that you will need to deploy any third party dll included in ssis package to GAC to run it in that machine.
9 июля 2012 г. 22:03
I will look and make sure the the dll is in the GAC. As for the path, It is explicit 'c:\temp' and not using a system variable. I've never have good luck with system variables.
10 июля 2012 г. 13:31
The dll has been registered in the GAC. I am not sure where to look at this point. I have gone so far as to set the file & foler permission in the statement just prior to calling the decrypt function. but that has not gotten me anywhere either.
I am at a loss as to where to go from here. I really do not want to create a custom windows service to handle this.
10 июля 2012 г. 13:42
maybe the same file being copied to C:\Temp folder is still be accessed by ssis engine at that folder(wild guess) ?? have you tried to run that code separately in some .net code(say in a console application just to decrypt the file from C:\Temp folder)?
10 июля 2012 г. 20:00
I used VS2010 to write the code, test and debug. Works just fine with a winform front end. That is what is maddening.
20 июля 2012 г. 18:12
Now that I'm back from Vacation,
I have just taken the C# project that I used to test and debug the decryption module in a windows form, changed the project to a Console application, set the start up object, added the neccessary code to the add the console functionality. As this is a console app, opend a command prompt 'as administrator' and executed the program.
All references to the .dll have remained the same. Accessing the functionality in the same manner as in the winform (copy/paste).
Still getting the Error "Access is denied to path ....."
If I comment out the code for the console app and reset the project type, no error.
What on earth can I be doing wrong. It's been 10+ years since I last wrote a Console app, and that was in vb6. So I know it's an error between the desk and chair.
I am open to any suggestions, no matter how bizzare.
16 августа 2012 г. 3:00МодераторTry using UNC path. If that does nor help, then you need to find out what is blocking access (perhaps it is the local policy).
Arthur My Blog