 |
 | Home | Contact Us | FAQ | Search & Site Map | Link to Us |
 | Sign In | Join | Other 45 Sites in Network |
MS Access Forum / General 1 / December 2005Any reason to favor calling a batch file VS running a CMD directly in A97 VBA?
I have a batch file named GetConf.bat. It contains a line like this: ipconfig /all >c:\MyAppDir\IPdata.txt I believe I could run the line with something like ShellWait by Terry Kreft. Any reason I should run the procedure via a batch file call as opposed to launching the command string directly? No reason that I can think of. What are you trying to accomplish, by the way? It may be that you can retrieve whatever you want without having to resort to those contortions. Take a look at what Randy Birch has at http://vbnet.mvps.org/code/network/index.html (ObWarning: Randy's site is aimed at VB programmers, not Access programmers. There are significant differences between the controls available on forms in VB vs. those available on forms in Access. Consequently, not all of the GUI-related code on Randy's site will port into Access)  SignatureDoug Steele, Microsoft Access MVP http://I.Am/DougSteele (no e-mails, please!) >I have a batch file named GetConf.bat. > It contains a line like this: [quoted text clipped - 6 lines] > call as opposed to launching the command > string directly? Thanks, Doug. Regarding the Randy Birch site, I thought you might have been referring to the section on using INI files??? I found nothing there though. Which part exactly were you talking about? BTW, I seem to have run into a snag with ShellWait... Call ShellWait("ipconfig /all >c:\IPdata.txt") DID NOT WORK!!! ShellWait ("ipconfig /all >c:\IPdata.txt") DID NOT WORK!!! #AND# Call ShellWait("c:\Program Files\TPSCG\GetConf.bat") WORKED! ShellWait ("c:\Program Files\TPSCG\GetConf.bat") WORKED! I don't understand. The batch file GetConf.bat contains the same CMD string ipconfig /all >c:\IPdata.txt but I've tested and the file "IPdata.txt" is not being created using the syntax in the first two cases. xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx >No reason that I can think of. > [quoted text clipped - 7 lines] >VB vs. those available on forms in Access. Consequently, not all of the >GUI-related code on Randy's site will port into Access) Two possible reasons why 1) The environment (particularly the PATH) may be different in the cmd shell as opposed to the windows shell 2) As ipconfig is a dos program it may just not like being run in this way. You could have tried Call ShellWait(environ$("comspec") & " /C ipconfig /all >c:\IPdata.txt") SignatureTerry Kreft > Thanks, Doug. Regarding the Randy Birch site, I thought you might > have been referring to the section on using INI files??? I found [quoted text clipped - 26 lines] >>VB vs. those available on forms in Access. Consequently, not all of the >>GUI-related code on Randy's site will port into Access) >Two possible reasons why > 1) The environment (particularly the PATH) may be different in the cmd >shell as opposed to the windows shell Thx Terry. I checked the path this way: Click Start, Run, "CMD" and typed Path. C:\WINDOWS\System32\ was in the path and IPconfig.exe is there. > 2) As ipconfig is a dos program it may just not like being run in this >way. You're probably right with this one. >You could have tried > Call ShellWait(environ$("comspec") & " /C ipconfig /all >c:\IPdata.txt") I would like to explore this, but am unsure what's meant by environ$ and comspec. Environ$ is a VBA function which returns the values of environment strings. So Environ$("Path") returns the Path environment string Comspec is the environment string which holds the path to your command line interpreter, so on my current machine Environ$("comspec") returns C:\WINDOWS\system32\cmd.exe The /C is a switch to cmd.exe to say run the command and then close. Therefore on my machine environ$("comspec") & " /C ipconfig /all >c:\IPdata.txt" translates as C:\WINDOWS\system32\cmd.exe /C ipconfig /all >c:\IPdata.txt SignatureTerry Kreft >>Two possible reasons why >> 1) The environment(particularly the PATH) may be different in the cmd [quoted text clipped - 12 lines] > I would like to explore this, but am unsure what's meant by environ$ > and comspec. YES! It worked like a charm. Many, many thx. Its also worth mentioning the following... Shell("ipconfig /all >c:\IPdata.sys") does not work from VBA Click Start, Run then ipconfig /all >c:\IPdata.sys doesn't either Nor does Start, Run c:\windows\system32\ipconfig /all >c:\IPdata.sys Now the batch file, on the other hand, seems to have no problems... Shell("c:\Program Files\TPSCG\GetConf.bat") works Click Start, Run then c:\Program Files\TPSCG\GetConf.bat works And of course Call ShellWait("c:\Program Files\TPSCG\GetConf.bat") works too (obviously) All produce the desired file... Directory of C:\ 12/13/2005 11:52 AM 877 IPdata.sys 1 File(s) 877 bytes 0 Dir(s) 9,338,142,720 bytes free The page I sent you to doesn't have anything about INI files. It has a number of different code snippets to get you information about IP addresses, MAC addresses, DNS and DHCP servers and the like. Since that's typically the type of information I'm looking for when I run ipconfig /all, I thought you might be able to get the information you were looking for directly. SignatureDoug Steele, Microsoft Access MVP http://I.Am/DougSteele (no e-mails, please!) > Thanks, Doug. Regarding the Randy Birch site, I thought you might > have been referring to the section on using INI files??? I found [quoted text clipped - 26 lines] >>VB vs. those available on forms in Access. Consequently, not all of the >>GUI-related code on Randy's site will port into Access) You're absolutely right. When I first hit the page, I clicked some of the links at the top, rather than scrolling downward. Thank-you. The information on that page is quite helpful. I even found some VB code for sync'ing with time servers I found interesting. In some conditions, I prefer to use a batch file. Like starting a database with a workgroup and switches using the "start" command. Benefit? You don't need to know the full path of msaccess.exe on each workstation on a network. application.followhyperlink is an alternative I use to open PDF files. > I have a batch file named GetConf.bat. > It contains a line like this: [quoted text clipped - 6 lines] > call as opposed to launching the command > string directly? Good points. > Like starting a database with a workgroup and switches using the > "start" command. Benefit? You don't need to know the full path > of msaccess.exe on each workstation on a network. > application.followhyperlink is an alternative I use to open PDF > files. The START command doesn't always work on all machines. I have never been able tofigure out why, though. The Access Web has ShellExecute API code that would be equivalent and could be run from Access. SignatureDavid W. Fenton http://www.bway.net/~dfenton dfenton at bway dot net http://www.bway.net/~dfassoc > I have a batch file named GetConf.bat. > It contains a line like this: [quoted text clipped - 6 lines] > call as opposed to launching the command > string directly? I only write a batch file for this kind of thing when the SHELL commands need to be executed in order. An example of this was where I was concatenating two files with COPY and then renaming them. I found it easier to do it all in DOS with a single batch file than to do multiple SHELLANDWAIT statements in VBA. I also sometimes write the batch file in code and then call it in cases where it gets too complicated to pass arguments to the batch file. Basically, I think it's better to minimize the number of your SHELL commands, but that's really only a personal preference. Using even 1 exposes you to the possibility of failure of outside processes, so there's no difference in kind, just a difference in quantity. SignatureDavid W. Fenton http://www.bway.net/~dfenton dfenton at bway dot net http://www.bway.net/~dfassoc |
Reply to this Message |
 Sign In
 Join
 My Latest Posts My Monitored Threads My Blog My Photo Gallery My Profile My Homepage Start New Thread Enable EMail Alerts Rate this Thread
|
©2008 Advenet LLC Privacy Policy - Terms of Use
This website includes both content owned or controlled by Advenet as well as content owned or controlled by third parties.