Open MS Access database that is over 2GB - ms-access

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.

Related

Compacting Access files quietly

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)

MySQL Workbench crashing due to long string with raw hex(?) values

I copy and pasted a value out of a SQL table and into the editor window, I didn't realize this string had some strange values in it, it looks like this:
I can't get rid of it now without crashing MySQL Workbench. Every time I try to edit it or delete the string I get the MacOS spinner and finally the system runs out of application memory and I have to force quit the application.
I tried deleting the cache file associated with this DB connection but it did not fix the problem. Any ideas how I can fix this?
Thanks
In order to get rid of that editor content simply remove the saved workspace. Open the log folder, via the Help menu, and go up one level. You will find a workspace folder which contains subfolders, one for each connection. Remove the one that causes trouble (keep Workbench closed while doing that).

Getting at VBA/Access Source Code

I'm rewriting a legacy access / VBA application in C#. While I am limited as a VBA programmer I am under the impression that the code is minimally compiled and runs almost as a script ? Obviously no security / VBA you can just hit alt + f11 to get at the source code is there a good way to decompile / get at this code?
So I tried this: http://forums.databasejournal.com/showthread.php?t=34222
which appears to be about how to decompile .mdb files.
However the program quickly recompiled itself - or at least says it is recompiling itself in the lower left status bar. Any ideas?
Here are some suggestions (some of which I'm repeating from comments I've made above):
Alt-F11 is not my usual method of opening the VBE, because I usually want to go to the Immediate Windows. Try Ctrl-G, instead.
If both Alt-F11 and Ctrl-G fail to open the VBE, then perhaps the AllowBypassKey property of the database has been changed to False. To get code to change this, search the Access help file for AllowBypassKey (in the VBE, from the help menu, search for "AllowBypassKey"). However, you won't be able to run the code within the database you're trying to investigate if AllowBypassKey is turned OFF, so you can run this code:
//
On Error GoTo Change_Err
Dim db As DAO.Database
Dim prp As Variant
Const conPropNotFoundError = 3270
Set db = DBEngine.OpenDatabase("C:\Databases\MyDatabase.mdb")
db.Properties("AllowBypassProperty") = True
exitRoutine:
If Not (db Is Nothing) Then
db.Close
Set db = Nothing
End If
Exit Sub
errHandler:
If Err = conPropNotFoundError Then ' Property not found.
' do nothing and exit
Resume exitRoutine
End If
Then you should be able to open the database when holding down the SHIFT key (which bypasses any defined startup routines, which might have been shutting off access to the VBE).
If the file is an MDE, there is no source code. You can find out if it's an MDE by checking this property:
?CurrentDB.Properties("MDE")
If it's an MDE (the file can have any extension), this will return "T". If it's not an MDE, it will throw an error (because the property doesn't exist).
Other things to check might be how many modules there are. If you have the database open and can get to the Immediate Windows (Ctrl-G), then this will tell you if there are any modules:
//
?CurrentProject.AllModules.Count
You also might be able to see what's in the database by opening up the Object Browser in the VBE (F2) and selecting the project name in the dropdown at the top (it will say "" by default
Last of all, you may think that it could be protected by Jet ULS, but starting with Access 2000, that's not a big possible, as there's nothing but a password on the VBA project available (i.e., it's no longer covered under Jet ULS). I would expect that if it were password-protected, you'd be prompted for the password somewhere along the line, so you'd already know that.
If it's an .mde you are out of luck. You need to get hold of the .mdb containing the source VBA code that was compiled to create the .mde
HOW TO VIEW SOURCE CODE (.mdb FILE)
Select the file
Hold the 'shift' key
Then double click the file without releasing the 'shift' key
Navigate to the Program Folders on your computer.
Open the MS Office Folder
Navigate to MSAccess.exe and make a shortcut of it.
Move the shortcut to where your database resides (makes life easier and you'll need to do this for each database to decompile).
(optional) Rename the shortcut to something like "decompiler for my database whose name is...." so you know that opening it blows away your compiled code
Right-click on the shortcut to view its properties. In the Target field of the properties dialog box for the shortcut you'll see something like "C:\Program Files\Microsoft Office\Office\MSACCESS.EXE"
In the target field, right-arrow to the end of the pathname, type a space, and then, in quotes, type (or paste) the full pathname of the location of your MS Access file to decompile (easiest way is to copy from the address bar on your window where the file resides, if you have the address bar showing).
Still in the Target field, type a space, and then with no quotes, type /decompile
Click OK to accept the changes and to close the dialog box.
Hold the Shift key down and keep it down.
Wiggle your ears
Double-click on the shortcut.
Go to any module in your database.

microsoft office/access - problem with filepath using call shell from vba

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.

Issue with clipboard

I have a legacy app I am currently supporting that is having problems when people copy large quantities of data from a datasheet view.
The App is built in MS Access and the amount of rows being copied can get pretty large (sometimes in the thousands).
The funny thing about it is, you can paste the data out, but then Access keeps "rendering" the data into different formats and becomes CPU bound for LONG periods of time.
The Status message beside the progress bar at the bottom right of the MS Access Window is
Rendering Data to format: Biff5
Biff5 is a "Binary Interchange File Format (BIFF) version 5" According to Source
The app code doesn't use BIFF5 anywhere so I don't think this is an app problem.
I cannot find any data on this error anywhere on the web so I thought it would be a good question for stackoverflow.
So, can anyone help please?
Instead of trying to copy-paste, can't you just export the query to Excel?
I am not sure what the problem is but sometimes you can run into some very quirky bugs with Access. Have you tried running this on different machines? Different OS's? Would it be possible to paste the data into Excel and then import into Access using import functionality? Can you import the data directly instead of pasting it?
Try copy-paste operation through VBA:
Once user has selected data to copy, you can execute the code below when click on a button in the form, and then do a pastespecial in excel:
--- Data selected by user ---
RunCommand acCmdCopy
Dim xlApp As Object
Set xlApp = CreateObject(Class:="Excel.Application")
'New Excel Workbook
Dim xlWbook As Object 'Excel.Workbook
Set xlWbook = xlApp.Workbooks.Add
'Paste in excel
xlWSheet.Range("A1").Select
xlWSheet.PasteSpecial Link:=False, DisplayAsIcon:=False, Format:="Biff5"
We are all on the same OS here for this, I am investigating the possibility that some update sent out in the last maintenance window has caused this, as it wasn't a problem before this and there have been no new releases of the software in that time period.
Tried in on lot's of machines, same issue on them all.
The problem is actually with copying from a datasheet view in Access and pasting to Excel, not the other way around strangely.
Here is the use case
Access --> "Copy from datasheet"(Normal Ctrl+C) --> "paste into Excel" (Normal Ctrl+V)
(this works fine!)
When you then go back to Access to continue working, it is CPU bound doing the "Rendering Data to format: " thing, I mentioned above.
I'm stumped to be honest, it's all a bit strange.