I have an Access database application and I would like to know the proper way of decompiling and recompiling it.
To Decompile an Access database you'll need to create a shortcut with the following elements:
Path to the MS Access Executable (MSACESS.exe)
Path to the database you would like to decompile
The /decompile flag
All together, then, the shortcut would look something like the following:
"C:\Program Files\Microsoft Office\Office\MSACCESS.EXE" "C:\users\tim\documents\Mydatabase.mdb" /decompile
Obviously, the paths will be different on your system.
I'd recommend making a backup of your database before running this command.
If you have any startup code in your database you should hold down the shift key to bypass the startup code execution.
Once the database opens, you can compact and repair the database to ensure optimal performance.
After the compact and repair, you can recompile the VBA code by opening any module and using the Debug Compile [DatabaseName] command.
If this is something you want to do frequently, you can create an "Access Decompile" shortcut in your SendTo Menu. Once you have this shortcut in the SendTo Menu you'll be able to right-click on any Access database and select "Send To --> Access Decompile", which is much easier than having to create a shortcut to the specific database.
Follow these steps to customize the Send To menu with an Access Decompile shortcut
Create a shortcut to the Access executable.
Append the /decompile flag in the Target for the shortcut. The shortcut will look like this:
"C:\Program Files\Microsoft Office\Office\MSACCESS.EXE" /decompile
Open Windows Explorer and paste the following into the address bar:
%APPDATA%\Microsoft\Windows\SendTo
Copy the shortcut you created into the SendTo Folder.
The Access Decompile Shortcut will now be available for use.
To invoke the Access Decompile shortcut, right click on an Access Database in Windows Explorer and select "Send To --> Access Decompile". Be sure to hold the shift key down to bypass any startup code in the database.
#Tim Lentine's practical instructions are good, but he leaves out the actual steps required for a decompile to be worth doing:
backup your database.
compact your database.
using the shortcut created with Tim's instructions, open your database.
close that instance of Access.
open a new instance of Access and open the database you just decompiled, but BE SURE YOU BYPASS ALL STARTUP CODE (i.e., hold down the shift key). If you don't do that, then you might as well go back to step 3 and try again, since if the startup code runs, your code will recompile before you are ready to do so.
compact the decompiled database (and be sure you hold down the shift key so that it bypasses the startup code; see #5).
open the VBE and on the Debug menu, choose COMPILE [name of project].
on the file menu, save the project.
compact again.
Why are all these steps necessary?
Because you want to not just decompile the VBA, you want to make sure that all the data pages where the compiled p-code was stored are completely discarded before you recompile.
I also recommend:
in VBE options, turn off COMPILE ON DEMAND
in the VBE, add the COMPILE button to your toolbar.
compile often with that button on the toolbar, after every two or three lines of code.
Decompile is not something you should use all the time, but during heavy-duty coding, I might do a decompile a couple of times a day. And I generally decompile/recompile as the last step before releasing an app into production use.
Last of all, read Michael Kaplan's article on the subject to understand it better.
The accepted answer is great, but it's a little impractical to create a shortcut for every database.
You can save this as a powershell module.
#for use with MSAccess 2010
Function Decompile-AccessDB{
param ([string]$dbFileName)
[string]$argument = '"' + $dbFileName + '"' + "/Decompile"
Start-Process -FilePath 'C:\Program Files (x86)\Microsoft Office\Office14\MSACCESS.EXE' -ArgumentList $argument
}
Then call it like this:
Decompile-AccessDB -Path "C:\Path\to\some.accdb"
This allows you to quickly and easily decompile any db from the power shell command line.
Note that you still need to hold down the Shift key when you run this to bypass the application startup.
I wrote a VBS script to automate the process of decompiling. It's silly that Microsoft hasn't integrated this into Access, considering it is a necessity when developing VBA-heavy applications.
The script locates MSACCESS.exe and runs Access with the decompile flag on a database located in the parent directory of the script, whose name is given in the code.
Option Explicit
Dim MSAccPath
Dim RegKey
Dim WSHShell
Dim currentDirectory
' Get MSACCESS.exe directory
RegKey = "HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\" _
& "CurrentVersion\App Paths\MSACCESS.EXE\Path"
Set WSHShell = WScript.CreateObject("WScript.Shell")
' Get parent directory
MSAccPath = WSHShell.RegRead(RegKey)
currentDirectory = WSHShell.CurrentDirectory
' Decompile
WSHShell.Run Chr(34) & MSAccPath & "MSACCESS.EXE" & Chr(34) & " " & Chr(34) & currentDirectory & "\..\testdb.accdb" & Chr(34) & " /decompile"
' Clear shell var
Set WSHShell = Nothing
Simply paste this text into a document with a .vbs extension and double-click it to run. Access will launch, decompile the compiled P-code ("packed" code), and automatically recompile the VBA source back into P-code.
The other answers here all seem a little complex to my taste.
To decompile an Access database:
Open the Run dialog from the start menu, or hit Win + R
Type in: MSACCESS.EXE /decompile (a proper installation should open up the Access application, you could also provide the full path to MSACCESS.EXE), and press OK.
Access now opens. Open up your DB in the Access window that just opened. That will decompile it.
Or simply you can create a shortcut on your Desktop (with the /Decompile Flag) and drag drop your Access application holding SHIFT to bypass any code
Related
I've already done this for the icon that appears on the taskbar while the application is running. Now I'm trying to do this for the shortcut icon or application icon on windows (the icon you see when looking at all Windows programs/apps.)
I've read that this can be done with a .dll file, but I'm not interested in that.
My intuition is that this is not actually possible to do with VBA inside the .mdb. Hopefully I'm wrong. Looking for a discussion on possible solutions.
Thanks.
If you're looking for a way to create a shortcut from VBA you can use the CreateShortcut method of a WshShell object, e.g.,
Option Compare Database
Option Explicit
Sub CreateDesktopShortcutWithIcon()
' ref - https://msdn.microsoft.com/en-us/library/xsy6k3ys(v=vs.84).aspx
Dim WshShell As Object
Set WshShell = CreateObject("WScript.Shell")
Dim strDesktop As String
strDesktop = WshShell.SpecialFolders("Desktop")
Dim oShellLink As Object
Set oShellLink = WshShell.CreateShortcut(strDesktop & "\My Shortcut.lnk")
oShellLink.TargetPath = "C:\Users\Public\UCanAccessTest.accdb"
oShellLink.WindowStyle = 1
'oShellLink.Hotkey = "Ctrl+Alt+f"
'oShellLink.IconLocation = "notepad.exe, 0" ' for embedded icon
oShellLink.IconLocation = "C:\__tmp\MIME\foo.ico" ' for .ico file
oShellLink.Description = "My shortcut created by VBA"
oShellLink.WorkingDirectory = strDesktop
'oShellLink.Arguments = "C:\myFile.txt"
oShellLink.Save
End Sub
A windows shortcut does and can have a ico file specified for that shortcut. While "often" they point the shortcut to the .exe and the shortcut pulls out the ico contined INSIDE of the .exe, OFTEN you will and can specify the ico for the shortcut. And since in ALL cases your shortcut will actually point to msaccess.exe, then you have to create a custom shortcut with a ico specified. You could even manually build the shortcut, specify the ico and then just use VBA to copy that shortcut to the desktop (assuming the path name to your application is ALWAYS the same - often it will not be - if path name will change from user to user, then a installer is really the only practical way to solve this problem).
I not sure if you can set/create the shortcut in VBA, but I would suggest that you adopt a windows installer (or a free one like Inno). These installers will create shortcuts on your desktop, and allow you to specify the icon.
one free and popular installer (inno) can be found here:
http://www.jrsoftware.org/isinfo.php
Setting up icons and shortcuts on your desktop via VBA code and Access makes little sense since the user will not have yet run your application/VBA code to setup the shortcut in the first place!!! So use a installer for this purpose.
In my Visual Basic Application, I have an access database file that I am using. It shows up in the solution explorer window. Everything works great until I install. The database file doesn't go with the installation for some reason. I guess I need to edit the connection string during runtime, but I am not sure. I have not done anything like this before, and I cannot find the information about it.
If someone could send me to a tutorial or give a brief explanation of how to use an access database once the application has been installed.
When my program runs, it creates a directory in
User\App Data\Roaming\CreatedFolder\Resources\DatabaseFile.accdb
So how do I set this path without knowing the full path up to App Data?
You can use
Environment.GetFolderPath(Environment.SpecialFolder.ApplicationData)
or
Environment.GetEnvironmentVariable("APPDATA")
They both should return something similar to
C:\Users\Gord\AppData\Roaming
so you can build your connection string like this:
Dim dbPath = _
Environment.GetFolderPath(Environment.SpecialFolder.ApplicationData) & _
"\CreatedFolder\Resources\DatabaseFile.accdb"
Dim connStr As String = "Provider=Microsoft.ACE.OLEDB.12.0;Data Source=" & dbPath
The way I would do this would be to:
Select Add New Data Source . . . from the Data Source window in Visual Studio
Select Database from the list that appears, and click next
Click next
In the Choose your data connection page of the wizard, click New connection
Choose Microsoft Access Database File from the listbox and click next
Choose a copy of the database file that is not in your directory and enter any login information
Click OK
Now Visual Studio will ask you:
The connection you selected uses a local data file that is not in the
current project. Would you like to copy the file to the project and
and modify the connection?
If you copy the data file to your project, it will be copied to the project's
output directory every time you run the application. Press F1 for
information on controlling this behavior.
Click "Yes," and Visual Studio will add the database to your project and make a connection string that points to the copied database.
Now you will probably want to save the connection string in App.Config so that you don't have to rebuild it every time you want to use the database. Most likely this will save a connection string that uses |DataDirectory|. Modify the contents of this page as you see fit.
Procede through the rest of the wizard and configure your database as you need it.
The wizard should configure the connection string and build information such that your application will work no matter where you take it.
EDIT - My connection string as it is saved in App.config looks like
<connectionStrings>
<add name="SOAccessDatabase.My.MySettings.Students_2000formatConnectionString"
connectionString="Provider=Microsoft.Jet.OLEDB.4.0;Data Source=|DataDirectory|\Students_2000format.mdb"
providerName="System.Data.OleDb" />
</connectionStrings>
I also have the database file's Build Action set to "Copy Always."
I notice in VS2010's Tools > Options dialog, there is a section on how to format the SQL:
I am working with a very large stored procedure on our server that is not formatted well at all. I was thinking it would be great to create a new SQL File in my project, copy and paste the text from the stored procedure in there, and have the text editor apply auto formatting to all of the SQL.
When I call "Add > New Item" and get that dialog, there does not seem to be any Installed Template with the .sql extension.
I see the SQL Server Database template, but that is not what I need. The LINQ to SQL Classes is not right, either.
What template do I need to use to use the auto formatting built into the VS2010 interface?
Judging from your screenshot, you have a C# project (e.g. a library dll) open. This won't show an option to add a .sql file as those files are not normally associated with a C# kind of projects.
One way around it is:
In VS2010 main menu, go to File -> New -> File. In General tab, there's a SqlFile file type.
Add a file and save it to the disk in the location of your project.
Right-click on your project and select Add -> Existing Item. In the open file dialog, change the extension to *.* to show your .sql file.
Add file to the project. If needed, change "Build Action" and "Copy to Output Directory" properties to control how it behaves during the build.
What you are looking for shows up when you create a SQL Server Database project.
File > Add > New Project
Then when you add items you see options that should work:
*Note my screenshots are from VS2012 - but I think it is the same.
I hate Visual Studio's T-SQL designer, even with SQL Data Tools installed. I opt to open my project's .sql files in Management Studio.
Right-Click any .sql file in VS.
Navigate to "Open-with"
Choose "Add"
In the Program dialog type "explorer.exe"
Type whatever you want for the friendly Name, I use Management Studio
Click "OK"
Highlight the new record and choose "Set as default".
Now double clicking any .sql file in VS will open up whatever program opens when you double click a .sql file outside of VS. Using this method, I'm able to edit, add, and modify my sql files in management studio and save them back to the project seamlessly.
Hope this helps.
In Visual Studio VSTO, how can I specify the document to open each time I run the project to debug it?
By default, it always opens a blank document and of course I want to test against features that would already be present in a document.
I tried as Cor_Blimey suggested but it opens only the specified when something changes (haven't figured what yet). In addition breakpoints don't work at least in VS2013 implementing the upper solution.
So what I did is to open the specific debugging/testing file each time the add-in is started up.
It works excellent, breakpoints are functional, no blank workbook is loaded and changes in a sheet a available in the next debugging session.
In order to avoid that the file is opened in the released add-in I put it in #if DEBUG.
More information about that method are here but it has as to be used with precaution as described here.
private void ThisAddIn_Startup(object sender, System.EventArgs e)
{
#if (DEBUG)
this.Application.Workbooks.Open("C:\\Users\\c563368\\Documents\\Visual Studio 2013\\Projects\\...\\debug.xls");
#endif
}
But there is one disadvantage, as long as you debugging environment (visual studio) is running, Office will always open the add-in build from the debug folder.
You can avoid this by running an the office application as external program, as described here.
You need to use the command line you can set to run on a successful build (there is no way to only get it to run on Debug (as in F11) and you cannot set it on a per Configuration basis. However, there is a good workaround to get it to only do things on the Debug configuration etc.
The basic behaviour is:
Open the solution. Open the project's properties. Go to Build Events. In Post-Build Event Command Line enter in the path to Word (e.g. "C:\Program Files (x86)\Microsoft Office\Office14\Winword") (or if it is in your %Path% then just Winword) and pass in the path to the document you want opened as an argument. This will open Word and the document on every successful build (you can set the trigger to being all builds, whether successful or otherwise etc)
What I prefer to do, however, is simply point it to a batch file, passing in the details about the build event as arguments to the batch file. Then, within the batch file, I run the logic to decide if it should launch Word, open a document etc.
For example, you can point it to
$(ProjectDir)buildScript.bat "$(ConfigurationName)"
Then within the batch file have something like
if %1=="Debug - Excel" "C:\Program Files (x86)\Microsoft Office\Office14\excel.exe" "%~dp0\testbook.xlsx"
This will run a batch file called buildScript in the project directory. The first argument (%1 to access in the batch file) will be the configuration. You can therefore set the batch file to launch Word and pass in the document as the argument if the config is e.g. "Debug" but not if it is "Release", thereby sidestepping the limitation within VS2012 Post-Build Event command line.
Edit:
A list of switches for Word can be found at http://support.microsoft.com/kb/210565
What you need to instruct Word to do will depend on the type of addin you are making:
If it is a standard COM addin then, so long as the DLL is registered and you have set the registry entries (or selected it in the Word addin settings) to open the addin then it should open when Word opens.
If it is an addin document, however, then the procedure is different -> try playing with the commnd switches to instruct Word to open the particular addin document.
I am more familiar with Excel COM addins, so you will have to experiment with the specificities of a Word addin. But the basic principles are to use the post-build event commnd line, coupled with the right switches and arguments to Winword.
Hope that helps.
The simpliest way to achive it is to replace .docx / .xlsx file in solution location
I had a VBA project in outlook with a few email macros - but after a PC crash they are all gone and all I see is a fresh 'Project1' when I hit Alt+F11
I'm not a VBA programmer, but had a collection of handy macros for email sorting etc. I would not like to have to code them again. Anyone know where the code files should be on the filesystem so that I might rescue the code?
This page has some really good insight on where Outlook keeps all its stuff. It suggests the following:
All Outlook macros are stored in a single file named VbaProject.otm in the user's %appdata%\Microsoft\Outlook folder, which will be a hidden folder on most systems.
Now, the problem is that if you do not see them now, then you probably won't be able to restore them from that location: there is probably either an "empty" project there or no project at all, but if that folder is being backed up, you might be able to restore it.
Moving forward, you might consider exporting your macros periodically in case this happens again, either through the VBA IDE (right-click and select Export File...) or using one of the tools mentioned in the linked article (like the Office Profile Wizard).
Ok. things to try to fix this...
I assume after the problem occured you tried logging back into the same windows user account, and the same Outlook profile.
Create a new windows login to the machine in question.
Login to this account and open Outlook, this will create a new outlook profile. make note of the profile name (to find this: Control Panel > Mail applet > Show Profiles...)
Now Exit Outlook, and make sure it is not running (check for outlook.exe in task manager).
Open Windows Explorer.
Copy (don't cut) the existing VbaProject.OTM file. (if it has any other name than that, first rename it to VbaProject.OTM, then copy).
Navigate to C:\Documents and Settings\USERNAME\Application Data\Microsoft\Outlook
(or use the environment variable notation %appdata%\Microsoft\Outlook for vista/win7)
Rename the existing VbaProject.OTM to VbaProject.OTM.OLD
Paste the VbaProject.OTM from step 5 into this folder.
Reopen Outlook and test (i.e. Alt + F11).
Good luck with recovery.
If this doesn't work do you remember adding self signing certificate at all? If so have you got a copy of the cert? you can try reinstalling it into the certificate manager (certmgr.msc)
copy/install it to the Certficiates - Current User\Personal\Certificates hive.
I just found this note from Sue Mosher (outlook VBA guru):
"AFAIK, once an .otm file is corrupted, it can't be recovered. That's why I recommend that people who rely on VBA code export their modules or backup the entire file. "
All macros are embedded into an OTM file, under the following location:
C:\Users\(***Your User Name***)\AppData\Roaming\Microsoft\Outlook\VbaProject.OTM
To restore, replace this file with the older one, it should work
Ran into this same problem.
First reviewed the .otm file mentioned by #Anonymous Type and #Dave DuPlantis
Not corrupted... hmm
I checked my Ribbon in Outlook for the Developer tab. It was missing and simply re-adding it to my Ribbon fixed my problem.