September 11, 2007 at 9:41 am
I have a small job : vb script that creates a load file of IIS logs using logparser. I wanted to schedule as a 2-step job process where
step1 runs the vb script and creates the load file
step2 loads file created by step1.
For some reason the network mapping of out web servers come up as not found when I schedule step1 in SQL job. If I run the command from command line, it runs fine.
What am I missing?
This SQLSERVER 2000 sp4, win2k+3. The script runs as cscript:
cscript file1.vbs > loadfile.txt
September 11, 2007 at 12:00 pm
Running the command from DOS and running it from a job step is executing the code from different contexts.
Recommendation - code the vbs file to not assume ANY drive mapping (which by the way would be the drive mappings available to the account running the scheduled task, a.k.a. in most cases the SQL Agent service accountr).
Otherwise - try finding out what drive mappings you might see while within the same context as the file1.vbs. The command for that would be something like:
NET USE > somefilename.txt
You'll likely need to encapsulate THAT into a .BAT file you then run (for testing purposes) from the job step running the cscript.
----------------------------------------------------------------------------------
Your lack of planning does not constitute an emergency on my part...unless you're my manager...or a director and above...or a really loud-spoken end-user..All right - what was my emergency again?
September 11, 2007 at 12:20 pm
I am looking for best alternatives now. The SQL job is run by a SQL service account. If I schedule via SQL Job, this account needs read permissions on the web servers. I will do a 2 different step process:
1. windows schedule job using a service account to create file
2. dts schedule to load and delete the load file.
any better idea.
and yes, the script does not assume any drive mappings,
-
September 11, 2007 at 12:54 pm
If you don't want the SQLAgent to have a bunch of network privileges (which is usually a good idea security-wise), then your next alternative in SQL 2000 is probably to design a DTS package (or an OSQL script) which you can schedule OUTSIDE of SQLServer. That way - the account security is managed by who the "job owner" is within the Windows Scheduler process.
----------------------------------------------------------------------------------
Your lack of planning does not constitute an emergency on my part...unless you're my manager...or a director and above...or a really loud-spoken end-user..All right - what was my emergency again?
September 11, 2007 at 1:47 pm
Thats most probably I'll do. I do not want to set a precedence of SQL service accounts having file system rights over the network. Will use the windows scheduler to create the file and run dts from command line.
Viewing 5 posts - 1 through 4 (of 4 total)
You must be logged in to reply to this topic. Login to reply