I created a script that compacts .mdb files on a schedule.
It works great when I call msaccess.exe with the /compact argument, except when it finds an mdb file that has been corrupted.
Instead of compacting it, it stops processing and shows this message until I click OK, and only after that does it start the compacting: microsoft access has detected that this database is in an inconsistent state
How do I avoid this window? Is there a /quiet or /nogui equivalent argument that shows no GUI and just does the compact commmand?
This script would run at night and I can't be there to click OK every time.
JETCOMPACT is not an option, because it freezes when I try to compact one of our mdb files.
There isn't an easy way in terms of a /quiet command switch but various options are described here:
https://answers.microsoft.com/en-us/msoffice/forum/all/is-there-a-way-to-do-a-quiet-command-line-ms/fe22a76e-3e45-4716-884c-1641ef75d3cf
I solved it myself in PowerShell. This compacts and repairs mdb files without confirmation or messageboxes interrupting:
$ObjectAccess = New-Object -ComObject "Access.Application"
$ObjectAccess.CompactRepair($MDBFilePathSource, $MDBFilePathDestination)
$ObjectAccess.Quit()
[System.Runtime.Interopservices.Marshal]::ReleaseComObject($ObjectAccess)
Related
Hi there hopefully there is a fix for this but I my ms access program crashed before it could finish a clean up of the data. Its now hit its 2GB maximum and wont open anyone know what do here? I just need it to drop all the data in the columns the thing of value are the queries and what order they are in.
Just get the error Cannot Open database''. It may not be a database that your application recognises, or the file may be corrupt. It gives me that twice.
its in an .accdb format so that shouldnt be a reading issue
Cheers.
Try running a compact and repair directly from the DAO database engine without opening the file in Access
You can use the following code from any VBA-enabled application or a VBScript file (it's designed for VBScript files, but you have to match bitness with your Access application, see this post, but should run fine from Excel as well)
Dim wShell, oExec, sFileSelected
Set wShell=CreateObject("WScript.Shell")
Set oExec=wShell.Exec("mshta.exe ""about:<input type=file id=FILE><script>FILE.click();new ActiveXObject('Scripting.FileSystemObject').GetStandardStream(1).WriteLine(FILE.value);close();resizeTo(0,0);</script>""")
sFileSelected = oExec.StdOut.ReadLine
CreateObject("DAO.DBEngine.120").CompactDatabase sFileSelected, Left(sFileSelected, Len(sFileSelected) - 6) & "Compacted.accdb"
That should copy over everything from your corrupt database while compacting it. It creates a new file, with your current filename and Compacted appended to it.
I had a bunch of unsaved scripts open. Today I restarted MySQL Workbench, there was an error message and now the scripts are gone. Is there a way to restore them somehow?
You can try to find your script in History Output. Check this answer: MySql workbench query history ( last executed query / queries ) i.e. create / alter table, select, insert update queries
If the save snapshot option is enable (this can be done by --> Edit>Preferences>SQL Editor>Save snapshot of open editors on close) then you can find the data in \%APPDATA%\MySQL\Workbench\log\sql_actions_unconnected.log. It is a log file, you can copy your code and paste it in a code editor which would put the code in the right format
This just happened to me and thankfully it turns out MySQL Workbench does actually autosave tab contents to disk. You can find them starting at your base configuration file path which is described here. The path to the scratch files is something like this:
{BASE_CONFIG_PATH}/sql_workspaces/{CONNECTION_NAME}.autosave/
Inside that folder is a bunch of .scratch files, looks like one per tab you had open for that connection. They're named with UUIDs, but just drop them all in a text editor and you should be able to find your lost tab contents pretty quickly.
If they're gone, they're gone, unfortunately. You should save them before you exit WorkBench (CTRL+S), since it has been very prone to errors like that, at least to me.
I'm running Windows 8. I have a file named "test.tcl".
If I open a shell, type "wish", then 2 windows open. In one of them, I can type Tcl code and open the file test.tcl. If I open this file, its code is executed.
If I double click on test.tcl to open the file with "Wish Application", then 1 blank window open, and nothing happens.
Do you know why please?
On Windows, Wish is built as a GUI-only application; it has no real standard output available. Tk fakes one for you though; just put this in your script to show the fake console:
console show
The fake console shows up by default when you launch without a script file, but launching with a script file doesn't show it (so your script file can implement an application, of course).
This can catch people out when they produce a lot of output on stdout. Tk may well be keeping it all faithfully just in case the code does console show later on, though it looks and smells a lot like a memory leak if you're not prepared for it…
I have the following set up on a server
Two MS-Access queries
Exported the data from the queries and saved the export steps
Created a macro to run these export steps then exit MS-Access
Created a batch file to open ms-access and run the macro
This works fine and dandy if I log into the server and double click the batch file, but if I set up a scheduled task to "run even if not logged in" then the ms-access macro doesn't seem to run....so it seems like access is never ran.
Does anyone have any ideas? Can you do this sort of process when "not logged in"? Is there something else I need to do? I am really stuck and need to have this automated.
Thanks!
My best guess is that you are trying to access a mapped network location that is not available.
Many networks have logon scripts that map network drives to local drive letters. These logon scripts are not run when you set up a scheduled task to "run even if not logged on."
So if you either:
A) are exporting your query results to a file on a mapped network drive (ie, N:\MyExport.txt) or,
B) have one or more tables in the source of your query that are linked to .mdb's on mapped network drives (ie, CurrentDb.Tables("MyTable").Connect = "N:\MyBackend.mdb")
then the process will fail.
If you are expecting to see an error message when you log on, you won't see one because the Access process is not visible when run through a scheduled task. However, if you go to Task Manager you should see an MSACCESS.EXE process listed.
If this is the problem there are two possible workarounds:
Use UNC paths (ie, \\fileserver\folder\MyExport.txt instead of N:\MyExport.txt)
Set up your scheduled task to run a batch file that:
maps the network drives using NET USE commands
opens your MS Access program with the appropriate command line arguments
I have the following vba-code in an MS-Access97-frontend which opens a word-document stored on a server:
Call Shell("winword ""\\Fileserver\Contabilita\Crucial deadlines\Bonifico97.doc""", 1)
The document is a merge-document (getting data from a query and populates the document from the data retrieved)
Now, I have put the database-frontend on another computer (still using MS-Access 97 but with MS-Word 2003 installed on the PC - MS-Access 97 is still working nicely since it was installed in a different directory) but now when above code, using call shell, is being executed, I always get "Document not found". If I launch above shell command in Start/execute, the document is being opened correctly.
What could be the problem? The file-path? Did any anything change in VBA 97 and VBA2003 what regards file-paths? I am aware of the fact that there is a folder in the file-path with a space but it works nicely on the PC with office97 installed.
I would appreciate any help I can get. Thank you.
You will need to use the full path for Word.
Alternatives to using SHELL with the full path specified for Word would be:
Application.FollowHyperlink
ShellExecute
In either case, you'd be opening the file with the application associated with the file association of the file you're opening. The only reason to stick with Shell() is if you're using the PID returned by the Shell() function to control the application after it's run. But your original code used Call Shell... so that wasn't an issue.