Build an Access executable from command line?

问题

We have a legacy Access application that is still in production. I would like to at least have an automated build for it. Can you build access exe's from the command line?

Even better, there wouldn't by any chance, be an MSBuild target for Access would there?

回答1:

a = CreateObject("Access.Application")
If a.SysCmd(603, PATH_TO_BXB_FILE, PATH_TO_BXE_FILE) = 0 Then
    MsgBox("Fail to compile to MDB file")
End If

The 603 argument of syscmd is undocumented. It will fail for a number of reasons, for example, running under VBA it will fail if you do not use a separate instance of MS Access. In this, other reason to fail are given as:

when it's used in VBA code running in a separate Access database (separate from the solution database);

when the solution database is closed; and

when there are no syntax errors in the VBA code in the solution database.

Note that even if the creation succeeds, the resulting mde or accde may not work on another machine. For the most part, I have found Access 2010 to be the most tolerant, however, you will end up with a bothersome security warning.

回答2:

This works for me 2010. Needed some time to manage that.

Function makeAccde()
    Dim source, temp, target As String
    DoCmd.RunCommand acCmdCloseAll 
    source = CurrentProject.path & "\" & CurrentProject.name
    temp = CurrentProject.path & "\" & "_tmpCompile.accdb"
    target = Left(source, Len(source) - 1) & "e"  'you can also use "r"
    Dim db As New Access.Application
    DoCmd.RunCommand acCmdCompileAndSaveAllModules

    Set aFSO = CreateObject("Scripting.FileSystemObject")
    aFSO.CopyFile source, temp, True

    db.AutomationSecurity = msoAutomationSecurityLow
    db.SysCmd 603, temp, target
    db.Quit
    Kill temp
    Application.Quit ' if you do not quit current db, sometimes target file is corrupted.
End Function

回答3:

You probably could write a windows script and thus have a command line ability.

However, it is unclear why you not using the options from the tools menu anyway? It not like the build time going to be a long time here.

The option in the menu to compile the application into an access executable is found here:

Access in its 20 year history never could and did produce an .exe file, but the act of compiling the application into an access executable has been a choice and option for about 20 years.

So you seem to be confusing or mixing up the term access executable (a mde or now accde file) and that of a .exe file. They are certainly not the same thing in regards to Access. And in fact today as such the concept of an .exe file is really quite moot. The older FoxPro distribution tools simply wrapped up the runtimes and shoved an .exe in front of what was a p-code system – it really never was a true executable in the sense despite having an .exe file extension.

However, today MOST systems do require an EXTENSIVE runtime system.

So do keep in mind that just like using .net or even VB6 in the past, you will require that the compiled Access executable have the supporting runtime files installed FIRST on the target computer. However this works is no different than most of the mainstream development tools in our industry today.

. So like C#, vb.net, or VB6 or even Java much of our mainstream tools in our industry do require a set of supporting runtime files and library to be installed BEFORE a compiled application can be run on the target machine. And like VB6, vb.net, C# or even Java (note how I said Java, not JavaScript), then once the runtime and supporting library are installed on the target computer, then the application can be usually be deployed with a simple file copy (xcopy development). So once again Access is much the same as Java or .net in this regards. (you don't have to install the executable – but just copy it but such a setup only works AFTER you installed the correct supporting runtime files).

Do keep in mind that one downside of Access is that the supporting libraries are a share component of office. So the ribbon library, PDF creating, image rendering, spell checking etc. are ALL A COMMON shared library of code between Word, Excel, Access, PowerPoint etc.

As a result of the above, if ANY PART of the particular version of office (and Access) you are using is installed, then the installing of the Access runtime WILL BE FORCED to install into the SAME directory structure as the existing office install. You cannot CHANGE this install location. Note that the reverse is also true! – If you install the access runtimes into a custom directly, then the install of Excel, word and all office programs will be FORCED to install to the SAME directory as to where you placed the Access runtime files. As noted, the reason for this the rather LARGE number of shared components among the office programs and Access is part of that mix.

As result of this large dependency, then in addition to the fixed directly location for the runtime support files then some significant issues result:

Share parts = only ONE version of Excel or Word or Access of the SAME office version can be installed. As a result, then you cannot install the 64 bit version of the Access runtime if the computer ALREADY has the same release of office installed but in a different bit wise format. This means if the computer has office 32 bit 2010 installed, then you cannot install the 64 bit edition of the Access 2010 runtime. (you can install 2013 runtime or say 2007 however).

Also, if Access (full or runtime support edition) is already installed, then you cannot install a second copy of the runtime – the installer will utilize the EXISTING install.

At the end of the day the result of all of the above means that your runtime files installed for Access will have a dependency on that version of office and as such this dependency can make distribution of Access applications a real challenge. Unfortunately while Access has a compiler, it does NOT have a linker and thus cannot link + grab those dependences and create a separate dll library. Without this ability then Access executable requires those office support files to be installed along with the Access runtime system.

If you need or require to install Access runtimes on machines with a minimal disruption to the existing version of office installed, then adopting a commercial installer along with some scripts from Sagkey here is recommend:

http://www.sagekey.com/installation_access.aspx

来源：https://stackoverflow.com/questions/14464839/build-an-access-executable-from-command-line

标签

ms-access

msbuild