Solved access database runtime (1 Viewer)

[mfaisal.ce]

i have an access database but how i can make it as runtime... i want to run access database as forms only and directly main form opens, no need for design view.... how can i do that

 

[isladogs]

Save a copy of it as an .ACCDR file by changing the file extension.

 

[mfaisal.ce]

Ok but i need to run a specific form at startup... How can i can do that bro

 

[Pat Hartman]

First you need to create the interface that the user will use. The app needs to open to a menu and all the forms/reports are accessed via that menu. Use the Access options to specify which form opens when the database opens.

Once the app is working correctly and the user never needs to view a table or a query, compile it and save it as an .accde. Make sure to zip and save your .accdb because that is your source code. DO NOT LOOSE IT!!!!!. Rename the .accde to .accdr. That tells Access to pretend to use the runtime to open the application.

What I have described does not secure your app. To do that, you need to do additional things. But this is sufficient to block the average user from getting into the design view of your application objects.

 

[CJ_London]

but i need to run a specific form at startup... How can i can do that

to expand on Pats comments - with your app open, go to file>options>current database, then select the form you want from the 'display form' dropdown

 

[Gasman]

Crossposted http://www.vbaexpress.com/forum/showthread.php?68206-Access-runtime

 

[gemma-the-husky]

note that if you save the database as an .accdr the user can obtain all your code. It's only simulating a run time version. If you want to secure your design, you need to publish/save it as an .accde

you can use the startup form

I now prefer to add an autoexec macro that runs a startup code function.
This does any necessary set up validation first, and then opens my startup form.

I think this is a better way of working, as it helps insulate users from problems they aren't really equipped to deal with.

 

[isladogs]

Just adding to Dave's comments....
1. You can first save as ACCDE then rename as ACCDR. The code will be locked down and it will simulate runtime.
2. Contrary to widespread belief, a startup form specified in Access options loads BEFORE an autoexec macro. If you want the autoexec to run first, load the startup form as the final part of your autoexec...and don't specify it in Access options

 

[gemma-the-husky]

@isladogs
Interesting nuances, Colin. The second point certainly hadn't occurred to me.

 

[isladogs]

The second point was raised by a new member a few months ago. It surprised several experienced developers who responded, including me. But it really is true and very easy to test...

 

[jukos]

Do I need to install access runtime (ie AccessRuntime_x64_en-us.exe) on all pc's I run "my_access_db_app.accde" on?

 

[CJ_London]

short answer yes - they need either a full version of access or the runtime version. As to which version, that depends on the version you developed your app in. Runtime Access has to be the same 'bit' (32 or 64) as the .accde. Note the bit related to access, not windows.

 

[jukos]

Can runtime be installed on a machine with office installed sans the access part?

 

[CJ_London]

Can runtime be installed on a machine with office installed sans the access part?

yes - if they have office, depending on their version, Access comes as standard so they should be able to install a full version from their office installation. If you want then to have runtime, not sure if that is an option from office install. If you are providing them with runtime, pretty sure it needs to match the office version (or later) and the same bitness (32/64Bit)

 

[isladogs]

Users can install runtime whether or not Office or Access are installed.
If a copy of Access is installed, the runtime must be a different version and is a separate download.

Contrary to widely held belief, it is sometimes possible to install both 32-bit and 64-bit Office on the same workstation.
For this to work, install a newer 64-bit version followed by an older 32-bit version (either runtime or full)
For more info, see this lengthy thread where I investigated this in detail UtterAccess.com.
I changed my long held opinion when I finally did some detailed tests

Based partly on my results, Mike Wolfe has just written about this topic at Side-by-Side Installs of 32-bit and 64-bit Versions of Access (nolongerset.com).

I'm not suggesting you should install mixed bitnesses...but in certain circumstances you can do so...and it works without any issues.