I have noticed some professional database designers create a special file that takes a networked database and copies the "front end" portion of the database to the computer's local hard drive, as opposed to running the database over the network itself. Apparently, this has its own advantages. The database runs faster, it is less likely to get corrupted with many in it at the same time, and therefore it improves performance. Below, I detail how to create such a file.
Create a notepad file called update.bat or similar. (Save it as a TXT file and then use a file-manager program to rename the extension to a .BAT extension.) Type in it the following (modifying to suit your environment):
@ECHO OFF cls c: cd \MANUAL\ copy d:\larry_restore_jan_6_2002\databases\unsecure\shipping_unsecure.mdb "D:\Program Files\Microsoft Office\Office\msaccess.exe" "C:\MANUAL\shipping_unsecure.mdb" cls |
The 1st line sets it up so that the BAT file closes down after it's done. The 2st line clears the screen. The next 2 lines establish the DESTINATION folder (the location where you want to file to be copied to). The 5th line is the line that executes the actual copy; the path specifies the SOURCE location of the file to be copied. The 6th line tells the computer to load Access and execute the file. The 7th line closes the BAT file to reduce clutter.
In this case, the BAT file is copying a file located in the d:\larry_restore_jan_6_2002\databases\unsecure folder. It copies this file to the C:\MANUAL folder, then executes it.
Below, I've copied & pasted an article I found on a newsgroup which gives MUCH more information about BATs, more than even I understand at this time:
====Closing a Batch process window automatically
====Applies to Windows 95/98/ME series OS
This article discusses the seven situations that we've found can affect automatic closure of a Batch process window. They're discussed starting with the most common ones first.
The general principle is that: when a Batch process finishes,
and any text generated by the process remains viewable,
Windows re-titles the DVM (Dos box) window so it reads:
"Finished - ScriptName"
and _keeps_ it open. This is so that the text can be read.
If you want the DVM process window to close automatically at the end of the run, work through these seven solutions:
==1) Scripts run with the initial command @ECHO OFF
Many scripts use @ECHO OFF to prevent the script commands
echoing during the run. For these scripts, if you make sure the
process window is clear of text as the batch script terminates,
Windows will normally close the DVM automatically. The typical
way to do this is to make sure that:
CLS
is used to clear any text before the script finishes. It doesn't have
to be the last command, but there should be no other commands
writing any text display and/or colour changes to screen afterwards.
==2) Scripts run with command echoing left ON
If you are not running the script with @ECHO OFF, Windows leaves the process window open (re-titled "Finished ScriptName") even if you end the Batch script with an unechoed clear-screen command: @CLS
Typically you'll be running a script this way for debugging purposes, and the reason the DVM isn't closed is the assumption that you'll want to see any debug results, even a _null_ result.
If you _don't_ want to use @ECHO OFF to turn off command
echoing, but you _do_ nevertheless want the DVM window to
close automatically, you need to end such scripts with the
_two_ commands:
@CLS
@EXIT
(in each case, the @ turns off command echoing for one line only)
==3) Scripts that set coloured backgrounds (usually with ANSI.SYS)
Windows treats coloured backgrounds remaining as a reason not to close the DVM. To close the DVM process window automatically, you will normally need to clear the coloured foreground/background to standard light-grey on black, and, if necessary, follow the steps for either case (1) or case (2) above
==4) Scripts run from a .PIF shortcut
Right-click the .BAT script and click "Create shortcut" then right-click the shortcut and click Properties, Program Tab, and make sure the check-box "Close on exit" _is_ checked. When run from the shortcut, the script should now close on exit even when text remains or coloured backgrounds are still set when the script finishes (such script windows _won't_ normally close when _not_ run from the shortcut).
==5) Scripts where all the above techniques appear to fail
If the DVM process window remains despite using all the appropriate methods above, it's normally because the script hasn't actually "finished". Typically due to a script error. Check the process window title, and you should find it doesn't have "Finished" as the initial word, and when you close the window manually you'll normally see the "Windows cannot shut down this program automatically...etc" dialogue box.
The script fault needs to be removed. Check the window title, and it should show the name of the uncompleted sub-process, which will give clues. Often, a complex script that uses child shells will fail to close them all - in this case COMMAND or similar will remain in the process window title.
In these cases, you need to debug the Batch script and get it working properly. Windows will only close a DVM process window if the process has genuinely completed, and control has been returned to the Windows Operating System.
==6) Script apparently fine, but: "Windows cannot shut down etc"
Sometimes, you find that a DVM window occasionally, but not always, hangs and gives the: "Windows cannot shut down this program automatically...etc" dialogue box when you try to close it manually. But you're sure the script has finished properly.
This can sometimes happen when you've started other GUI processes (with the START command - with or without the /wait switch). If you've used the /wait switch, the DVM will, of course, wait for the GUI thread it started to finish. However, when this happens without the /wait switch, it may be due to delays in passing inter-process messages (particularly on a heavily-loaded system) This leaves the START command unresolved. Usually, a delay inserted into the script near the end, or a re-working of the point at which the START command is used will fix it.
==7) "Your Pop-Up Program Is Ready to Run"
Occasionally, even when your script fulfils _all_ the
requirements above, the process window fails to close
and you see the message:
"Your Pop-Up Program Is Ready to Run"
displayed in the window.
This is caused by uncompleted TSR (terminate and
stay resident) software actions. Typically:
a) You're loading a TSR in AUTOEXEC.BAT or your
script which is incompatible with VMM32 memory
management of the DVM
b) You're loading DosKey with the undocumented /APPEDIT
switch, probably in AUTOEXEC.BAT or CMDINIT.BAT in WinME
(this extends DosKey functionality inside some commands,
such as Debug). This often interferes with closure of DVM windows.
c) You're using the undocumented feature
[386Enh]
LocalLoadHigh=1
in SYSTEM.INI (this setting slightly increases the simulated
"real-mode" sub 640K memory available to DVM processes).
Obviously, if you're doing any of the above, then try _not_ doing it. However, the problem can sometimes be fixed, without the need to stop doing (a), (b) or (c). Try altering any upper memory optimisation strategy you're using in AUTOEXEC.BAT or CONFIG.SYS (loading individual commands high, MEMMAKER loading locations, change the value of LASTDRIVE, etc). The idea here is that it can alter memory usage and possibly remove the conflict. Also read the Microsoft Knowledge Base Article: Windows Msg: Your Pop-Up Program Is Ready to Run
http://support.microsoft.com/support/kb/articles/Q85/6/43.ASP