By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
424,689 Members | 1,759 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 424,689 IT Pros & Developers. It's quick & easy.

Executing MSACCESS.EXE without a full path?

P: n/a
I've got a .BAT file that I use for executing various MS Access apps that I
wrote way back in the days of 2.0.

It's evolved over time, but it still contains a number of possible paths to
MSACCESS.EXE, tries them all, takes the first one it finds, and dies if none is
found.

Seems to me like at some time or another I was able to clone this .BAT file and
implement it with no path. Something about MSACCESS being a registered
application.

I'd like to do that now, but find that just typing MSACCESS.EXE on the command
line doesn't work....so maybe I rememeber wrong....

My agenda is to bulletproof this .BAT file a little more so it isn't dependent
on a list of paths.

Suggestions?
------------------------------------------
For the maschoistically-inclined, here's a copy of the file.
Actually, it's three files: A small "root" .BAT file, a .TXT
file that the root copies into a .BAT file, and a "Version" file
that specifiesd the latest-and-greatest version of the app.

Trets_Go1.bat:
----------------------------------------
@ECHO OFF
SET AppDirLAN=\\xxx\yyy\zzz\TRETS
SET AppDirLocal=C:\Temp

COPY "%AppDirLan%\Bat\Trets_Go_2.txt" "%AppDirLocal%\Trets_Go_2.bat"
CALL "%AppDirLocal%\Trets_Go_2.bat"
----------------------------------------
Version.txt:
----------------------------------------
:* --------------------------
:* This file is used by the 2 Trets_Go Bat files
:* to decide which version to execute and, if necessary,
:* copy down to the user's C: drive.
:*
:* The "...Refresh" parameters enable us
:* to force a re-copy of an application down
:* to each user's C: drive. Useful if a user's
:* copy of the app becomes corrupted and we do
:* not want to elevate a new version.
:*
:* Needless to say, it should be set back to "NO"
:* once the user in question has invoked the app.
SET AppVersion=019
SET AppRefresh=No
SET BatRefresh=No
----------------------------------------

Trets_Go2.txt:
----------------------------------------
@ECHO OFF
:* (Please refer to end of file for explainatory remarks)
:* ------------------------------
:* Capture script name/path into memory variables
:* Technically, this may seem redundant, but it makes
:* for a little lesss gobbeldygook in the code when we
:* want to refer to these values

SET ScriptName=%~n0
SET ScriptPath=%~f0
:* ------------------------------
:* If user asked for help, display help
:*
IF /i {%1}=={/Help} (call :Help %2) & (GOTO :ExitNormal)
IF /i {%1}=={/?} (call :Help %2) & (GOTO :ExitNormal)
IF /i {%1}=={?} (call :Help %2) & (GOTO :ExitNormal)

:* -----------------------------Begin Main Procedure ----------------------------------------
:Main

ECHO .
ECHO . --------------------------------
ECHO . Setting common variables...
ECHO .
CALL :setCommon

ECHO .
ECHO . --------------------------------
ECHO . Setting TRETS-specific memory variables
ECHO . (AppDirLocal and AppDirLan set in Trets_Go_1)
SET AppName=TretsApp
SET AppDescr=TRETS

SET IniPath=%AppDirLAN%\Bat\TRETS.ini
SET SecPath=%AppDirLAN%\Bat\SYSTEM.MDW
SET VerPath=%AppDirLan%\Bat\Versions.txt

TITLE %AppName%

ECHO .
ECHO . --------------------------------
ECHO . Verifying/creating local directory
ECHO .

IF NOT EXIST %AppDirLocal% MD %AppDirLocal%

ECHO .
ECHO . --------------------------------
ECHO . Checking for version file...
ECHO .
IF NOT EXIST %VerPath% GOTO
AbendVersionTxtMissing
:VerCopy
:* ----------------
:* Copy Versions.TXT file to .BAT and then execute it to set memory
:* variables containing latest version number for each app and whether-or-not
:* we want to force a refresh of existing app
:*
ECHO .
ECHO . --------------------------------
ECHO . Getting version numbers...
ECHO .
COPY "%VerPath%"
%AppDirLocal%\Trets_Version_Set.BAT
CALL %AppDirLocal%\Trets_Version_Set.BAT
:BatCheck
:* ----------------
:* Check for existing .BAT file in AppDirLocal
:* No sense copying it down again if it already exists...
:*
:* To make things more bulltproof, we may want to force
:* a copy anyhow by setting "BatRefresh=Yes".
:*

ECHO .
ECHO . -----------------------
ECHO . Checking latest version of .BAT file on your PC...
ECHO .
IF NOT EXIST "%AppDirLocal%\Trets_Go_2.%BatVersion%.bat" GOTO BatCopy
IF %BatRefresh%==YES GOTO BatCopy
IF %BatRefresh%==Yes GOTO BatCopy
IF %BatRefresh%==yes GOTO BatCopy
GOTO EOF
:BatCopy
:* ----------------
:* Copy the .BAT file down to user's C: drive
:*
IF NOT EXIST %AppDirLAN%\Bat\Trets_Go_2.txt GOTO AbendBatMissing
DEL %AppDirLocal%\Trets_Go.*.bat
ECHO .
ECHO . -----------------------
ECHO . Copying "%AppDirLAN%\Bat\Trets_Go_2.txt" down to
"%AppDirLocal%\Trets_Go.%AppVersion%.bat"....
ECHO .
COPY "%AppDirLAN%\Bat\Trets_Go_2.txt"
"%AppDirLocal%\Trets_Go.%BatVersion%.bat"

:* ----------------
:* Check for existance of MS Access'
:* .EXE in various and sundry locations
:*
:* We don't validate the entire directory.
:* As long as MSACCESS.EXE is there, we
:* assume everything else is OK.
:*
:AccCheck
ECHO .
ECHO . -----------------------
ECHO . Looking for a copy of MS Access...
ECHO .

set AccessPath=%AccessPath1%
IF EXIST "%AccessPath%" GOTO AppCheck

set AccessPath=%AccessPath2%
IF EXIST "%AccessPath%" GOTO AppCheck

set AccessPath=%AccessPath3%
IF EXIST "%AccessPath%" GOTO AppCheck

set AccessPath=%AccessPath4%
IF EXIST "%AccessPath%" GOTO AppCheck
GOTO AbendAccessMissing
:AppCheck
:* ----------------
:* Check for existing app version on C:
:* No sense copying it down again if it already exists...
:*
:* To make things more bulltproof, we may want to force
:* a copy anyhow by setting "AppRefresh=Yes".
:*

ECHO .
ECHO . -----------------------
ECHO . Checking latest version of application on your PC...
ECHO .

IF NOT EXIST %AppDirLocal%\%AppName%.%AppVersion%.mdb GOTO AppCopy
IF %AppRefresh%==YES GOTO AppCopy
IF %AppRefresh%==Yes GOTO AppCopy
IF %AppRefresh%==yes GOTO AppCopy
GOTO AppStart
:AppCopy
:* ----------------
:* Copy the app down to user's C: drive
:*
IF NOT EXIST %AppDirLAN%\%AppName%.%AppVersion%.mdb GOTO AbendAppMissing
DEL %AppDirLocal%\%AppName%.*.mdb
ECHO .
ECHO . -----------------------
ECHO . Copying new version of application down to your PC....
ECHO .
XCOPY "%AppDirLAN%\%AppName%.%AppVersion%.mdb" %AppDirLocal%\ /K
:AppStart
ECHO .
ECHO . -----------------------
ECHO . Starting MS Access...
ECHO .

START /B /HIGH /MAX "FIMMA Startup" "%AccessPath%"
%AppDirLocal%\%AppName%.%AppVersion%.mdb /ini "%IniPath%" /wrkgrp "%SecPath%"
/Excl

SET RET=0
GOTO :EOF
:* -----------------------------End Main Procedure ----------------------------------------

:setCommon
:* ----------------
:* Specify up to four alternatives for
:* finding standalone MS Access, ranked
:* by search order: first one found is the
:* one that's used.
:*
:* NB: Any required quotes get added when we do the "START" command

SET AccessPath1=C:\Program Files\Microsoft Office 2000\Office\MSACCESS.EXE
SET AccessPath2=c:\program files\microsoft office\office\msaccess.exe

SET AccessPath3=C:\Microsoft Office\Office\MSACCESS.EXE
SET AccessPath4=E:\Program Files\Office.2K\Office\MSACCESS.EXE
GOTO :EOF
:Help
:* This routine is redundant since we have no parms that need to be supplied
:* on the command line. We left it in in case we add parms some day.

ECHO .
ECHO .
ECHO . ----------------------------------------
ECHO .
IF NOT "%BadParam%"=="" COLOR E0 & ECHO . Uh-Oh! Bad or missing parameter.
ECHO .
ECHO . The syntax of this command should be:
ECHO .
ECHO . "Trets_Go_2"
ECHO .
ECHO . ----------------------------------------
ECHO .
PAUSE
GOTO :EOF
:AbendAccessMissing
ECHO OFF
COLOR E0
ECHO .----------- Cannot Run %AppDescr%
ECHO .
ECHO . Could not find MS Access in any of these paths:
ECHO .
ECHO . %AccessPath1%
ECHO . %AccessPath2%
ECHO . %AccessPath3%
ECHO . %AccessPath4%
ECHO .
ECHO . Please notify supervisor or LAN manager.
ECHO .
ECHO . %ScriptPath\%ScriptName%
ECHO .--------------------------------------------
PAUSE
GOTO :ExitNormal

:AbendAppMissing
COLOR E0
ECHO .----------- Cannot Run %AppDescr%
ECHO .
ECHO . %AppDirLAN%\%AppName%.%AppVersion%.mdb not found.
ECHO .
ECHO . Please notify supervisor or LAN manager.
ECHO .
ECHO . %ScriptPath\%ScriptName%
ECHO .--------------------------------------------
PAUSE
GOTO :ExitNormal
:AbendBatMissing
COLOR E0
ECHO .----------- Cannot Run %AppDescr%
ECHO .
ECHO . %AppDirLAN%\Bat\Trets_Go_2.txt not found.
ECHO .
ECHO . Please notify supervisor or LAN manager.
ECHO .
ECHO . %ScriptPath\%ScriptName%
ECHO .--------------------------------------------
PAUSE
GOTO :ExitNormal
:AbendVersionTxtMissing
ECHO OFF
COLOR E0
ECHO .----------- Cannot Run %AppDescr%
ECHO .
ECHO . %VerPath% not found.
ECHO .
ECHO . Please notify supervisor or LAN manager.
ECHO .
ECHO .
ECHO . %ScriptPath\%ScriptName%
ECHO .--------------------------------------------
PAUSE
GOTO :ExitNormal
:ExitNormal
GOTO :EOF

:* ================================================== ===========================
:* (these remarks are so lengthy that they were actually slowing down the execution
:* when they were up in the beginning of the file - so we moved them here)
:*
:* PURPOSE: To download the latest version of one of several applications
:* and start it up under MS Access.
:* ACCEPTS: (nothing)
:* NEEDS: - A text file named 'Versions.txt'. Refer to the 'VerPath'
:* parameter below. A sample file is appended in remarks at the end
:* of this .BAT file.
:*
:* NOTES: 0) Remarks slow execution too much when a .BAT file is run over the LAN.
:* Therefore we have a little root .BAT file on the lan ("Trets_Go_1.bat")
:* that copies this .TXT file down to C:\TEMP and renames it to .BAT.
:* This speeds up execution a *LOT*.
:*
:* 1) This is all dependent upon a three-level naming convention for your app
:* that begins with the app name, includes a three-digit version number,
:* and ends with ".MDB".
:* e.g. TimeTrackerApp.016.mdb would be version 0.16 of the Time Tracker application.
:*
:* 2) This is intended to be called from a shortcut with a command line that
:* reads something like: D:\TimeTracker\Bat\AccessApp.bat TimeTracker
:*
:* 3) Quite a few memory variables are set within this procedure.
:* If you create an NT 3.51 shortcut, make sure it's "Environment"
:* is maxed at 4096 or this procedure may run out of environment
:* space and die.
:*
:* 4) Memory variables that you need to peruse and set when customizing
:* this procedure for a given LAN situation are:
:*
:*
:* IniPath - The full DOS path or UNC to the .INI file used by the application
:* This is the one we put on the Access command line.
:* NB: Each app should try to use the same .INI file, but we do it
:* this way in case somebody wants their very own....
:* SecPath - The full DOS path or UNC to the .MDA file we use for security
:* VerPath - The full DOS path or UNC to the little .TXT file that contains
:* latest version number of each app.
:* AccessPath1 - A full DOS path or UNC to someplace where we can find
:* a complete install of MS Access 8.0
:* AccessPath2, 3, 4 - Ditto AccessPath1. This means that different users
:* can have different installs of Access as long as each is
:* represented here
:*
:* Scroll down to procedure ":setCommon" to see these variables.
:*
:* 6) Memory variables that need to be set for each application are:
:*
:* AppName - The name of the application as it appears in the .mdb file name.
:* SB exactly the same as the parameter for that app.
:* AppDescr - User friendly short description for error messages
:* AppVersion - The version of the application. Set from the .TXT file.
:* AppRefresh - Whether-or-not we want to force-feed a new copy of the app
:* to the user's C: drive even though one is already there.
:* AppDirLAN - The DOS path or UNC that points to the directory where
:*
:* Scroll down to a given applications ":set[AppName]" procedure to see
:* these variables.
:*
:* 7) Last, but not least, is the "Version File" - currently named "Versions.txt".
:* It loads two variables for each application:
:* ....Version (e.g. "TimeTrackerVersion", "FimmaVersion") which tells what version of the app to run
:* ....Refresh (e.g. "TimeTracker", "FimmaRefresh") which tells whether-or-not
:* we want to download the app even though it is already on the user's PC
:*
:* ================================================== ===========================

----------------------------------------
--
PeteCresswell
Nov 12 '05 #1
Share this Question
Share on Google+
15 Replies


P: n/a
RE/
Suggestions?


Got it!

The magic word, in this case, is "START".

e.g.

C:\ START MSACCESS
--
PeteCresswell
Nov 12 '05 #2

P: n/a
x@y.z ((Pete Cresswell)) wrote in
<g3********************************@4ax.com>:
RE/
Suggestions?


Got it!

The magic word, in this case, is "START".

e.g.

C:\ START MSACCESS


And that doesn't work on all installations of Windows.

--
David W. Fenton http://www.bway.net/~dfenton
dfenton at bway dot net http://www.bway.net/~dfassoc
Nov 12 '05 #3

P: n/a
On Fri, 21 Nov 2003 00:52:17 GMT, "(Pete Cresswell)" <x@y.z> wrote:

Other suggestion: step into the 21st century and use a shell script
file. You can write it in VBScript, execute it using the Windows
Script Host (wscript.exe). Now you can use CreateObject to create an
MsAccess object.

-Tom.

I've got a .BAT file that I use for executing various MS Access apps that I
wrote way back in the days of 2.0.

It's evolved over time, but it still contains a number of possible paths to
MSACCESS.EXE, tries them all, takes the first one it finds, and dies if none is
found.

Seems to me like at some time or another I was able to clone this .BAT file and
implement it with no path. Something about MSACCESS being a registered
application.

I'd like to do that now, but find that just typing MSACCESS.EXE on the command
line doesn't work....so maybe I rememeber wrong....

My agenda is to bulletproof this .BAT file a little more so it isn't dependent
on a list of paths.

Suggestions?

<clip>

Nov 12 '05 #4

P: n/a
to*****@no.spam.cox.net (Tom van Stiphout) wrote in
<5d********************************@4ax.com>:
Other suggestion: step into the 21st century and use a shell
script file. You can write it in VBScript, execute it using the
Windows Script Host (wscript.exe). Now you can use CreateObject to
create an MsAccess object.


You can't count on the WSH being available, as it is so
horrendously insecure that wise system adminstrators completely
remove it from client PCs.

It's too bad Microsoft wasn't thinking about security when they
created the WSH.

--
David W. Fenton http://www.bway.net/~dfenton
dfenton at bway dot net http://www.bway.net/~dfassoc
Nov 12 '05 #5

P: n/a
dX********@bway.net.invalid (David W. Fenton) wrote in
news:94***************************@24.168.128.86:
to*****@no.spam.cox.net (Tom van Stiphout) wrote in
<5d********************************@4ax.com>:
Other suggestion: step into the 21st century and use a shell
script file. You can write it in VBScript, execute it using the
Windows Script Host (wscript.exe). Now you can use CreateObject to
create an MsAccess object.


You can't count on the WSH being available, as it is so
horrendously insecure that wise system adminstrators completely
remove it from client PCs.

It's too bad Microsoft wasn't thinking about security when they
created the WSH.


David is right; all code, scripts, and executabulls are horrendously
insecure and should be expunged from every PC.

--
Lyle
(for e-mail refer to http://ffdba.com/contacts.htm)
Nov 12 '05 #6

P: n/a
> David is right; all code, scripts, and executabulls are horrendously
insecure and should be expunged from every PC.


I think David is right indeed!
Never heard of vbs-virusses and the like?

Every nitwit can create extremely dangerous vbs-scripts (WSH is powerful).
Without any other program needed (just hit Enter) such a script can destroy your data completely.
I know some system adminstrators that actually remove WSH from their PC's.
I heard some others who rename the executable in order to prevent disasters.

Arno R


Nov 12 '05 #7

P: n/a
"Arno R" <ar****************@tiscali.nl> wrote in news:3fbe30e6$0$36112
$5******@dreader2.news.tiscali.nl:
David is right; all code, scripts, and executabulls are horrendously
insecure and should be expunged from every PC.
I think David is right indeed!


Then we agree, I think.
Never heard of vbs-virusses and the like?
Gee, who could remember something like that?
Every nitwit can create extremely dangerous vbs-scripts ...


I will yield to your superior knowledge of the capability of nitwits.

--
Lyle
(for e-mail refer to http://ffdba.com/contacts.htm)
Nov 12 '05 #8

P: n/a
RE/

And that doesn't work on all installations of Windows.


Am I OK banking on it working with all installs of Win 2000 Pro?

--
PeteCresswell
Nov 12 '05 #9

P: n/a
RE/
Other suggestion: step into the 21st century and use a shell script
file. You can write it in VBScript, execute it using the Windows
Script Host (wscript.exe). Now you can use CreateObject to create an
MsAccess object.


What advangages would that have over a .BAT file? (if it's interactvely
debuggable, that would be one...)
--
PeteCresswell
Nov 12 '05 #10

P: n/a
On Fri, 21 Nov 2003 14:55:22 GMT, dX********@bway.net.invalid (David
W. Fenton) wrote:

I think a VBS file is just as secure as a .bat file.
Namely: not at all.

-Tom.

to*****@no.spam.cox.net (Tom van Stiphout) wrote in
<5d********************************@4ax.com>:
Other suggestion: step into the 21st century and use a shell
script file. You can write it in VBScript, execute it using the
Windows Script Host (wscript.exe). Now you can use CreateObject to
create an MsAccess object.


You can't count on the WSH being available, as it is so
horrendously insecure that wise system adminstrators completely
remove it from client PCs.

It's too bad Microsoft wasn't thinking about security when they
created the WSH.


Nov 12 '05 #11

P: n/a
to*****@no.spam.cox.net (Tom van Stiphout) wrote in
<4o********************************@4ax.com>:
On Fri, 21 Nov 2003 14:55:22 GMT, dX********@bway.net.invalid
(David W. Fenton) wrote:
to*****@no.spam.cox.net (Tom van Stiphout) wrote in
<5d********************************@4ax.com>:
Other suggestion: step into the 21st century and use a shell
script file. You can write it in VBScript, execute it using the
Windows Script Host (wscript.exe). Now you can use CreateObject
to create an MsAccess object.


You can't count on the WSH being available, as it is so
horrendously insecure that wise system adminstrators completely
remove it from client PCs.

It's too bad Microsoft wasn't thinking about security when they
created the WSH.


I think a VBS file is just as secure as a .bat file.
Namely: not at all.


That issue is orthogonal to the problem.

The question is whether the method you choose is supported on the
machine where it is going to run. There is no way to prevent the
execution of batch files, but lots of system administrators
prohibit the use of scripts that depend on the WSH.

And the issue I was pointing out at the end was that MS could have
made the WSH safer than batch files, but they didn't do so, which
is a great loss to all of us.

--
David W. Fenton http://www.bway.net/~dfenton
dfenton at bway dot net http://www.bway.net/~dfassoc
Nov 12 '05 #12

P: n/a
x@y.z ((Pete Cresswell)) wrote in
<ql********************************@4ax.com>:
RE/

And that doesn't work on all installations of Windows.


Am I OK banking on it working with all installs of Win 2000 Pro?


Nope -- it doesn't work on my Win2K Pro workstation.

--
David W. Fenton http://www.bway.net/~dfenton
dfenton at bway dot net http://www.bway.net/~dfassoc
Nov 12 '05 #13

P: n/a
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

I worked on a client's network that did not allow the running of .bat
files. I believe it had to do with the command.exe program - they did
not allow that to run, either. But, strangely, the cmd.exe program
could run, but, still, not the .bat file inside the cmd window.

====

orthogonal: x - y

diagonal: x
\
y

;-)

Rgds,

MGFoster:::mgf
Oakland, CA (USA)
-----BEGIN PGP SIGNATURE-----
Version: PGP for Personal Privacy 5.0
Charset: noconv

iQA/AwUBP8AYVIechKqOuFEgEQLjvQCgoNjK958U5UqFU5RqhUHOKo wvxXsAnRKU
km87EnjRI4ArkWjMvntyS2II
=OZ13
-----END PGP SIGNATURE-----

David W. Fenton wrote:
That issue is orthogonal to the problem.

The question is whether the method you choose is supported on the
machine where it is going to run. There is no way to prevent the
execution of batch files, but lots of system administrators
prohibit the use of scripts that depend on the WSH.

And the issue I was pointing out at the end was that MS could have
made the WSH safer than batch files, but they didn't do so, which
is a great loss to all of us.

Nov 12 '05 #14

P: n/a
I believe the setting of the PATHEXT environment variable is what you are
referring to....
--
MichKa [MS]
NLS Collation/Locale/Keyboard Development
Globalization Infrastructure and Font Technologies

This posting is provided "AS IS" with
no warranties, and confers no rights.
"MGFoster" <me@privacy.com> wrote in message
news:aL*****************@newsread2.news.pas.earthl ink.net...
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

I worked on a client's network that did not allow the running of .bat
files. I believe it had to do with the command.exe program - they did
not allow that to run, either. But, strangely, the cmd.exe program
could run, but, still, not the .bat file inside the cmd window.

====

orthogonal: x - y

diagonal: x
\
y

;-)

Rgds,

MGFoster:::mgf
Oakland, CA (USA)
-----BEGIN PGP SIGNATURE-----
Version: PGP for Personal Privacy 5.0
Charset: noconv

iQA/AwUBP8AYVIechKqOuFEgEQLjvQCgoNjK958U5UqFU5RqhUHOKo wvxXsAnRKU
km87EnjRI4ArkWjMvntyS2II
=OZ13
-----END PGP SIGNATURE-----

David W. Fenton wrote:
That issue is orthogonal to the problem.

The question is whether the method you choose is supported on the
machine where it is going to run. There is no way to prevent the
execution of batch files, but lots of system administrators
prohibit the use of scripts that depend on the WSH.

And the issue I was pointing out at the end was that MS could have
made the WSH safer than batch files, but they didn't do so, which
is a great loss to all of us.


Nov 12 '05 #15

P: n/a
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Yeah, thanks michka. Found reference in MS Knowledge Base article
KB246766.

My client's sysadm said they "burned" the same O/S image on all user
workstations - so they must have changed the Registry to prevent users
running stuff sysadm doesn't want run.

- --
MGFoster:::mgf
Oakland, CA (USA)
-----BEGIN PGP SIGNATURE-----
Version: PGP for Personal Privacy 5.0
Charset: noconv

iQA/AwUBP8GTCoechKqOuFEgEQIVUwCg4UYWzp/OXMu+L73zPa5d2NgXO5sAoOs/
2eL8fG3scgAUICB6pk+NhQpn
=kbp9
-----END PGP SIGNATURE-----

Michael (michka) Kaplan [MS] wrote:
I believe the setting of the PATHEXT environment variable is what you are
referring to....


Nov 12 '05 #16

This discussion thread is closed

Replies have been disabled for this discussion.