November 28, 2017 at 5:14 pm
Hi
I'm having problems parsing the correct expression for a Process Task
I'm attempting to use a ForEach loop to process a directory of zip files.
The aim is to extract the first zip file with 7zip, upload the contents into a db, process them, extract the processed files, zip them to another directory and repeat until the zip files are done.
The processing part works fine and the ForEach loop finds the first file passing the filename to the loop as the string variable [User::CurrentFile].
I also have a string variable [User::PathCurrentFile] that is set to the source directory.
I can read both these as script tasks inside the loop so that bit works fine.
I've created an expression for the 7zip Process Task argument which looks right:
" e + @[User::PathCurrentFile] + @[User::CurrentFile]+ -y -o\"C:\\2017\\For adding to Collection\\\""
this parses as
e + @[User::PathCurrentFile] + @[User::CurrentFile]+ -y -o"C:\2017\For adding to Collection\" Where from experience I'd expect to see
e "" -y -o"C:\2017\For adding to Collection\" and the process fails with
Error: 0xC0029151 at Extract downloaded NAT files, Execute Process Task: In Executing "C:\Program Files\7-Zip\7z.exe" " e + @[User::PathCurrentFile] + @[User::CurrentFile]+ -y -o"C:\2017\For adding to Collection\"" at "", The process exit code was "2" while the expected was "0". So the escaped quotes appear to be the problem. But as the file path and file names have spaces they are needed for the 7zip DOS command line. When I run the following command from DOS it works fine
"C:\Program Files\7-Zip\7z.exe" e "C:\\Processed\0452 The Company of Exporters_20171012.zip" -y -o"C:\2017\For adding to Collection\"If I remove any of the filepath quotes it obviously fails in DOS.Can anyone please tell me where I'm making the stupid mistake in my argument line?
November 29, 2017 at 12:23 am
At the first glance, it looks like the parameters @[User:TongueathCurrentFile] and @[User::CurrentFile] are not enclosed in double quotation marks,
😎
Exit code 2 for 7zip means a fatal error, almost always related to bad parameters passed to the program.
November 29, 2017 at 4:07 pm
Thanks Erikur
Where the hell did the emoticons come from? I typed a P! It should read [User:PathCurrentFile]
I've tried various versions of escaped quotes but they seem to lock in the variable name as a 'word'.
Today I'll see if I can build a second(third) variable that includes the quote marks, but I'm not hopeful at this stage.
There must be a way to handle long filenames as a variable in a process task.
November 29, 2017 at 5:59 pm
Hi guys
Thanks for the help.
I had a rethink about the process. I've had no problem with using 7zip in an SSIS Process task on a 'static' file.
So what I've done to solve my problem is to use the fully qualified source a variable in a new connection string. A file task copies it to the processing folder as "source.zip" which can then be processed easily as a 'static' file.
I still think there must be a way to handle long filenames as a variable in a process task, but I'll think about it later 🙂
November 29, 2017 at 6:28 pm
steve.alston - Wednesday, November 29, 2017 5:59 PMHi guys
Thanks for the help.
I had a rethink about the process. I've had no problem with using 7zip in an SSIS Process task on a 'static' file.So what I've done to solve my problem is to use the fully qualified source a variable in a new connection string. A file task copies it to the processing folder as "source.zip" which can then be processed easily as a 'static' file.
I still think there must be a way to handle long filenames as a variable in a process task, but I'll think about it later 🙂
I've definitely had this problem myself in the past. It's not the length of the filename, I think, but the fact that it contains spaces which is causing the problem. If you can get rid of the spaces, I think you might find that it will work.
You could also write a quick script task which would use the built in .NET libraries to do your unzipping. This is the sort of thing I mean. No need for third-party applications.
The absence of evidence is not evidence of absence.
Martin Rees
You can lead a horse to water, but a pencil must be lead.
Stan Laurel
Viewing 5 posts - 1 through 4 (of 4 total)
You must be logged in to reply to this topic. Login to reply