Prev: vb script to retrieve DNS records, identify hostname and ip duplic
Next: Return top level folder list and respective sizes from current fol
From: Tom Lavedas on 6 Jul 2010 17:01 On Jul 6, 4:20 pm, "Pegasus [MVP]" <n...(a)microsoft.com> wrote: > "Saucer Man" <saucer...(a)nospam.com> wrote in message > > news:4c33499e$0$2407$cc2e38e6(a)news.uslec.net... > > >> The lines you quote after "writelog" are fine but none of them will alter > >> the behaviour of your script in any way. You could omit the whole lot. > >> After the interpreter has executed the WriteLog subroutine it will > >> disassociate the various variables from their objects and terminate the > >> script, even without the "nothing" and "quit" keywords. The problem > >> therefire lies in your WriteLog subroutine. What does it look like? > > > Thank you both for your input. The script I am using is this one... > > >http://www.anonymoos.com/scripting/logonscript.txt > > I don't really have the time to work my way through your 350 lines of code. > Suffice it to say that the WriteLog subroutine looks suspicious: > > sub WriteLog(sEntry) > if bolWriteLog then objLogFile.WriteLine(Now() & ": Log: " & sEntry) > End Sub > > I would modify it like so: > > sub WriteLog(sEntry) > wscript.echo "Label 1", sEntry > if bolWriteLog then objLogFile.WriteLine(Now() & ": Log: " & sEntry) > objLogFile.close > wscript.echo "Label 2" > End Sub > > I also have serious concerns about the widespread use of "On error resume > next" statements. This is a highly effective means of covering up errors in > the script and it can make debugging a real chore. I wouldn't be surprised > if the error occurs in one of the blocks of code that is covered by an "On > error" statement. Use them very, very sparingly and only for those lines of > code where they are relevant, never for whole functions. I initially had a concern about the ON ERROR lines, but it appears on a quick scan that every use has a corresponding IF ERR.Number trap to handle the errors. I also don't have the time ore interest to do more than a quick scan of the script. But, I don't think that is the ultimate problem. Your approach to debug is a useful one, but it should not have a CLOSE in it, as the file is opened external to that subroutine and the routine is called from many places in the script. Therefore, the file must remain open until the cleanup at the end of the script. I would like to know what the last line of the log file contains (or last few). That might give a clue as to what part of the script is really the problem. I don't think it is in the log write itself, but I have now way of troubleshooting it (even if I wanted to). _____________________ Tom Lavedas
From: Saucer Man on 7 Jul 2010 08:24 "Tom Lavedas" <tglbatch(a)verizon.net> wrote in message news:ab5c64eb-8c9c-4bbe-804d-7ce6755c5efe(a)d37g2000yqm.googlegroups.com... > I initially had a concern about the ON ERROR lines, but it appears on > a quick scan that every use has a corresponding IF ERR.Number trap to > handle the errors. I also don't have the time ore interest to do more > than a quick scan of the script. But, I don't think that is the > ultimate problem. > Your approach to debug is a useful one, but it should not have a CLOSE > in it, as the file is opened external to that subroutine and the > routine is called from many places in the script. Therefore, the file > must remain open until the cleanup at the end of the script. > I would like to know what the last line of the log file contains (or > last few). That might give a clue as to what part of the script is > really the problem. I don't think it is in the log write itself, but > I have now way of troubleshooting it (even if I wanted to). > _____________________ > Tom Lavedas The last lines of code show the printers being connected like so. Sometimes there are more than one printer connected depending on the users group membership. 7/7/2010 7:59:45 AM: Success: User is member of Printers - Accounting 7/7/2010 7:59:45 AM: Success: Connect to printer: \\DataNetwork\S-MX3501N-(.207) 7/7/2010 7:59:46 AM: Log : ################ End Login Script ###################
From: Tom Lavedas on 7 Jul 2010 08:44 On Jul 7, 8:24 am, "Saucer Man" <saucer...(a)nospam.com> wrote: > "Tom Lavedas" <tglba...(a)verizon.net> wrote in message > > news:ab5c64eb-8c9c-4bbe-804d-7ce6755c5efe(a)d37g2000yqm.googlegroups.com... > > > I initially had a concern about the ON ERROR lines, but it appears on > > a quick scan that every use has a corresponding IF ERR.Number trap to > > handle the errors. I also don't have the time ore interest to do more > > than a quick scan of the script. But, I don't think that is the > > ultimate problem. > > Your approach to debug is a useful one, but it should not have a CLOSE > > in it, as the file is opened external to that subroutine and the > > routine is called from many places in the script. Therefore, the file > > must remain open until the cleanup at the end of the script. > > I would like to know what the last line of the log file contains (or > > last few). That might give a clue as to what part of the script is > > really the problem. I don't think it is in the log write itself, but > > I have now way of troubleshooting it (even if I wanted to). > > _____________________ > > Tom Lavedas > > The last lines of code show the printers being connected like so. Sometimes > there are more than one printer connected depending on the users group > membership. > > 7/7/2010 7:59:45 AM: Success: User is member of Printers - Accounting > 7/7/2010 7:59:45 AM: Success: Connect to printer: > \\DataNetwork\S-MX3501N-(.207) > 7/7/2010 7:59:46 AM: Log : ################ End Login Script > ################### OK. That says the final write is performed, which leaves my initial guess as the next most likely thing to try. That is, ... writelog "################ End Login Script ###################" Set objNetwork = Nothing Set objDrives = Nothing Set objComputer = Nothing Set objShell = Nothing Set objFileSystem = Nothing ' Added line of code objLogFile.close ' Set objLogFile = Nothing 'Msgbox "Logon Script Complete",,"Mapper" WScript.Quit I don't know why the CLOSE would be needed, but it can't hurt and just maybe ... _____________________ Tom Lavedas
From: Saucer Man on 7 Jul 2010 14:55 "Tom Lavedas" <tglbatch(a)verizon.net> wrote in message news:bd2c8f61-01d5-4e25-b12b-ad79c2217d02(a)w12g2000yqj.googlegroups.com... OK. That says the final write is performed, which leaves my initial guess as the next most likely thing to try. That is, ... writelog "################ End Login Script ###################" Set objNetwork = Nothing Set objDrives = Nothing Set objComputer = Nothing Set objShell = Nothing Set objFileSystem = Nothing ' Added line of code objLogFile.close ' Set objLogFile = Nothing 'Msgbox "Logon Script Complete",,"Mapper" WScript.Quit I don't know why the CLOSE would be needed, but it can't hurt and just maybe ... _____________________ Tom Lavedas I added the above line but it didn't help. Then it occured to me that it is probably Windows 7 saying "access denied" because of UAC..not because the script was not quitting. I opened Notepad as Administrator and then I was able to make changes to the log and save it without a problem. Thank you both for all your help and efforts!
From: Kenneth A. Larsen on 28 Jul 2010 18:21
"Saucer Man" <saucerman(a)nospam.com> wrote in message news:4c333e54$0$2394$cc2e38e6(a)news.uslec.net... >I have a .vbs script that maps drives and network printers. The script >lives on the network. I script is not quitting on Windows 7. It works >fine on XP and Vista. I can tell this because it writes a log file to the >root of C:/. After it has run, I try to modify the log file and save it >but I get an access denied error. > > The last lines of the script are... > > writelog "################ End Login Script ###################" > > Set objNetwork = Nothing > Set objDrives = Nothing > Set objComputer = Nothing > Set objShell = Nothing > Set objFileSystem = Nothing > Set objLogFile = Nothing > 'Msgbox "Logon Script Complete",,"Mapper" > WScript.Quit > > -- > Thanks! You're welcome! > |