Please start any new threads on our new
site at https://forums.sqlteam.com. We've got lots of great SQL Server
experts to answer whatever question you can come up with.
| Author |
Topic |
|
skaggsSQL
Starting Member
5 Posts |
 Posted - 2002-01-03 : 11:13:42
|
| I have a long running job (a VB exe) I am creating to do all the imports and exports for our company. The job runs anywhere between 1 and 8 hours depending on the number and size of the files. When the job takes longer than I am expecting it to I will stop the job. However at this point the .exe file is locked and can not be overwritten or deleted. I was wondering why this was happening and what I can do to release the file. I can not stop the server during the day so I must wait till evening at this point to update my .exe.Jim SkaggsProgrammer |
|
|
izaltsman
A custom title
1139 Posts |
Posted - 2002-01-03 : 11:28:23
|
| Even though your job is stopped, your VB executable may remain in memory until it runs to completion. Use task manager to find your the VB process and end it. Once the process is terminated, you should be able to delete the exe file. |
 |
|
|
skaggsSQL
Starting Member
5 Posts |
Posted - 2002-01-03 : 11:57:48
|
quote:
Even though your job is stopped, your VB executable may remain in memory until it runs to completion. Use task manager to find your the VB process and end it. Once the process is terminated, you should be able to delete the exe file.
The task manager will not allow us to terminate that job. It gives the error message access is denied when we try to terminate the job. Any other suggestions? Thanks for you help!Jim SkaggsProgrammer |
|
|
|
izaltsman
A custom title
1139 Posts |
Posted - 2002-01-03 : 12:32:15
|
| Interesting... After you stop the job in SQL Server, does the spid that launched the VB program stay around? If it does -- see if you can kill it... |
|
|
|
skaggsSQL
Starting Member
5 Posts |
Posted - 2002-01-03 : 16:08:51
|
quote:
Interesting... After you stop the job in SQL Server, does the spid that launched the VB program stay around? If it does -- see if you can kill it...
The SPID is still around and I did attempt to Kill it, but it then began the rollback process which said it would take approximately 5855 seconds to complete. I am now wondering if I can Kill the process without the rollback. It is just for testing so I am not so concerned about the data. We are constructing a development server at this time and when it becomes active it won't be such a big deal to down the server, but I am one of those people who hates to not know the answer to a question. Thanks again for your help.Jim SkaggsProgrammer |
|
|
|
robvolk
Most Valuable Yak
15732 Posts |
Posted - 2002-01-03 : 16:25:16
|
| I had a similar problem, unfortunately I wasn't able to resolve it except to bounce the server. Stooopid NT processes!It might be less painful if the EXE file was written to process batches of rows, say commit every 1000 rows of an import. That may not exactly solve the problem, but it would reduce the rollback time and maybe release the EXE sooner.BTW, is the EXE the only step in the job or are there others? Can the process be rewritten in SQL? What else does it do besides import files? |
|
|
|
skaggsSQL
Starting Member
5 Posts |
Posted - 2002-01-04 : 09:16:08
|
quote:
I had a similar problem, unfortunately I wasn't able to resolve it except to bounce the server. Stooopid NT processes!It might be less painful if the EXE file was written to process batches of rows, say commit every 1000 rows of an import. That may not exactly solve the problem, but it would reduce the rollback time and maybe release the EXE sooner.BTW, is the EXE the only step in the job or are there others? Can the process be rewritten in SQL? What else does it do besides import files?
The import process is a fully tested process which has been in place for some time now. The importing procedure just became too time consuming to do manually anymore. I am attempting to not rewrite this import procedure for 2 reasons: 1. The testing which would have to be done and 2. We would then have two import routines which would have to be updated and tested whenever a new and exciting twist was thrown into our operation.I believe I have an idea how to accomplish this by writing my own scheduler in VB or C. I am much more experienced programming in these languages anyway. (I really think that the key lies in killing the thread to the shell which is invoked) If you know of any prewritten schedulers written out in the free community anywhere let me know otherwise I am off and running. Also, if you want to know WHEN I solve this let me know. Jim SkaggsProgrammer |
|
|
|
|
|
|
|
|
Stopping a Job & Releasing files