December 14, 2011 at 7:40 am
This one is driving me nuts. I cannot, for the life of me, figure out what the issue is. All the variables are correct. I've tried removing the embedded configuration file, I don't know what's wrong.
The package works in BIDS. I run it via a job and I get the non-helpful error of:
Error Text
Job 'MyJob' : Step 1, 'Run Package' : Began Executing 2011-12-14 09:29:16Msg 102, Sev 15, State 1, Line 1 : Incorrect syntax near '/'. [SQLSTATE 42000]
I run it via the GUI and get a more explicit (but untranslatable) error of:
GUI Error
Error: System.Reflection.TargetInvocationException: Exception has been thrown by the target of an invocation. --> System.IO.DirectoryNotFoundException: Could not find part of the path. at System.IO.__Error.Win10Error(Int32 errorCode, String maybeFullPath) at System.IO.__Error.WinIOError() at System.IO.File.Move(String sourceFileName, String destFileName) at ScriptTask_e14fee2eb23649b4bb9f226424a40e08.vbproj.ScriptMain.Main() -- End of inner exception stack trace -- at Signature sig, MethodAttributes methodAttributes, Runtime TypeHandle typeOwner) at System.Reflection.RuntimeMethodInfo.Invoke(Object obj, BindingFlags invokeAttr, Binder binder, Object[] parameters, CultureInfo culture, Boolean skipVisibilityChecks) at System.Reflection.RuntimeMethodInfo.Invoke(Object obj, BindingFlags invokeAttr, Binder binder, Object[] parameters, CultureInfo culture) at System.RuntimeType.InvokeMembers(String name, BindingFlags bindingflags, Binder binder, Object target, Object[] providedArgs, ParameterModifier[] modifers, CultureInfo culture, String[] namedParams) at System.Type.InvokeMember(String name, BindingFlags invokeAttr, Binder binder, Object target, Object[] args, CultureInfo culture) at Microsoft. SQLServer.Dts.Tasks.ScriptTask.VSTATaskScriptingEngine.ExecuteScript()
I have two script tasks in this package, neither of which uses any of the names above as variables or parameters. Only one appears to do a file move, but it evaluated fine when I was testing everything and did actually move everything where it was supposed to. The other script task just assigns values for an email to be sent out.
I'm really lost as to what to check next. Any hints?
December 14, 2011 at 8:05 am
Open each of the script tasks individually, and right click - build them... Do they build successfully?
_____________________________________________________________________
Disclaimer - The opinions expressed by the mouth are not necessarily those of the brain
December 14, 2011 at 8:24 am
TedT (12/14/2011)
Open each of the script tasks individually, and right click - build them... Do they build successfully?
Build succeeded on both.
EDIT: Although now I can see, on the Build menu, the ScriptTask_xxxx names. Which means now I know for sure that the one with the file move is definitely the one the error is complaining about.
December 14, 2011 at 9:23 am
Sounds like a permission issue? Are you moving the file on a network drive maybe? It could be when you run it in BIDS its using your windows authentication and when you run it in the job its trying to use the account that is associated with SQL Server and it doesn't have permission?
Just throwing that out there. 🙂
December 14, 2011 at 10:57 am
Good idea, but if it were a permissions issue, I would not expect a syntax error.
We've had permissions issues on other packages / jobs before, and never gotten this error in those situations.
December 14, 2011 at 11:23 am
So I'm about ready to murder a pork chop or two at this point. Anyone have a pork chop flinger handy?
Moved the package to another environment. Recreated the job (scripted off of Production) but changed all the relevant Operator / Job Log / Package & Config file location information to point to our QC environment.
When I did this, I discovered the script task was adding an extra / to the file destination name. Yay! I say, thinking this will resolve the problem. Package runs fine in BIDS, move it into QC, and it's working in the GUI now (after accounting for a duplicate file issue).
So I try the job again. Same syntax error. I run it in the GUI to make sure I'm not imaging things. Yep, it works. Cut-n-paste the command line from the GUI run in the job (just in case), and I'm STILL getting the syntax error.
I'm about to post the line in my job to this post for someone to look it over and guess what I find? Instead of the type being "Operating system (CmdExec)", it's set to "Transact-SQL script (T-SQL)".
I need to have a chat with the person who created this job. He owes me a very fancy (and expensive) hot cocoa for going through this pain.
EDIT: Yes, I've fixed the problem. Thank you both for trying to help.
December 14, 2011 at 11:28 am
Sorry that was a DUH on my part... I didn't read the exact message at the top.:blush:
Glad you figured it out!
Viewing 7 posts - 1 through 7 (of 7 total)
You must be logged in to reply to this topic. Login to reply