MS Access Form Standalone Setup?

[zeke1]

I could really use some help here from people wiser in MS Access then I. You see my old work machine which contained MS Access 2007 met a tragic end recently and the new computer they gave me has MS Access 2013 on it and this is where my problem begins.



On my old computer I could save an MS Access form and table into a sort of stand alone, installable program that I could share with other users. And when they ran the install it would put the program on their desktop with it's own icon and everything. When you clicked the icon it would launch the form I created, not all of Access (although I suspect that behind the scenes it was using Access Runtime surreptitiously) so that to the untrained eye it would appear to be just like any other application.

Now because my old machine died suddenly I can't look back at it to reference how I did this and I have scoured the internet for 2 days trying to find the answer but everywhere I look are people asking how to do this and in every case they are being told that it can't be done. They would say Access can't create a stand-alone Access application. But it can...or at least it could. I know because I did it but I didn't do it enough for it to be second nature to me and Access 2013 is completely different looking then the 2007 version so maybe it's just changed appearances or is in a new place? I dunno.

So I come here asking you fine folk to help me understand how create a setup install file of a stand-alone Access program in Access 2013 like was possible in Access 2007?

[Micron]

Some suspect terminology here. Access cannot create an installer in the true sense, but it can come close. The thing is, if you had that level of knowledge, I really doubt you'd be saying you can't remember how you did it. So it must have been something else.

You can make an Access built database look and behave like a 'stand alone' program - it just takes work and some know-how. You could also use it to run code that would replicate itself or copy a sort of working file and install these copies of somewhere, but I have to agree that it can't make stand alone programs (especially not executables - .exe) out of itself.

There should be no reason why you cannot open the 2007 version with 2013 and modify its design. However, if you do, any design changes you attempt to make will prompt you to save it in the latest format, and you may not be able to open it with an older version later on. That's not definite AFAIK. You would have to utilize features that are not backwards compatible in order to make it so that it can't be opened by earlier versions.

I'd start with a copy of the db. When opening that, see if you can utilize the shift bypass since the behaviour you describe suggests there is either an AutoExec macro that calls code, or the db settings cause a specific form to open upon launch. Since you suggest you are the creator, you must know what I'm talking about and whether or not there is an AutoExec macro, startup form, or code. Should you have to save the db in 2013 format, you will have the original to fall back on.

[zeke1]

Some suspect terminology here.

Most likely. I'm not a MS Access expert by any means. It was something my boss tossed my way one day so it's mostly self-taught knowledge.

Access cannot create an installer in the true sense, but it can come close. The thing is, if you had that level of knowledge, I really doubt you'd be saying you can't remember how you did it. So it must have been something else.

That sounds a little accusatory. As I said - I didn't do it often. To be precise I made two such programs and the last one was problem over a year and a half ago at least. That's not exactly frequent enough to become second nature.

You can make an Access built database look and behave like a 'stand alone' program - it just takes work and some know-how. You could also use it to run code that would replicate itself or copy a sort of working file and install these copies of somewhere, but I have to agree that it can't make stand alone programs (especially not executables - .exe) out of itself.

There should be no reason why you cannot open the 2007 version with 2013 and modify its design. However, if you do, any design changes you attempt to make will prompt you to save it in the latest format, and you may not be able to open it with an older version later on. That's not definite AFAIK. You would have to utilize features that are not backwards compatible in order to make it so that it can't be opened by earlier versions.

I'd start with a copy of the db. When opening that, see if you can utilize the shift bypass since the behaviour you describe suggests there is either an AutoExec macro that calls code, or the db settings cause a specific form to open upon launch. Since you suggest you are the creator, you must know what I'm talking about and whether or not there is an AutoExec macro, startup form, or code. Should you have to save the db in 2013 format, you will have the original to fall back on.

It wasn't anything that elaborate. It was a function of Access 2007. And I can't open the 2007 version because it was lost along with most of my HDD when the machine died.

[Micron]

That sounds a little accusatory.

Sorry, I meant if you had the level of knowledge to create an installer, you'd remember how it was done. So by "something else" I meant it had to be less complicated because the level of expertise for this would be fairly high. You've rated yourself as a novice, and that's way beyond novice level. Even so, what you describe may be much more complicated in my mind than reality. I envision a design that's still quite complex for a novice, so forgive me if I sound skeptical. It may be that what you built isn't as complicated as I envision. Nor would you be the first person trying to break into someone else's app and posting in a forum to get help to do it. Not saying you are, just that I'm trying to be careful so as not to aid such an effort without consideration.

And I can't open the 2007 version because it was lost along with most of my HDD

I gather this wasn't stored on a network and you never backed up the database.

Your last sentence of your first post suggests you want to be reminded of how to do one of two things (not sure which). Either way, the knowledge required is way more than what a novice with the experience you describe is capable of, so I must be misunderstanding what it is you want or had. Access has no feature you can use to create installers as though it were some button click thing. The closest would be to publish a db to the web, which isn't what you're describing - installing on desktops. What I envision requires a robust level of Access vba and probably how to code in the CLI (Command Line Interface) i.e. write batch or command files. I say that because you'd have to know how to write code to navigate to network folders and download a copy of a front end (which means the db has to be split) onto a pc and place this file in the user's desktop, or programmatically create a shortcut there. Sorry for not getting the right drift.

[CJ_London]

only thing I can think of is to create a .accde or perhaps package and sign. The latter creates an exe which the user executes to install - but they need access or access runtime to open the installed app. However to hide the access window, have its own icon in the taskbar etc so it appears as a 'non access' program requires a certain level of skill and a high awareness of the environment in which the app is being run.

Both are available under File>Save and Publish>Save Database As, then just follow the prompts

To use your own icon in the window bar when the app is open, go to File>Options>Current Database and select your icon. Ensure you include in your package if using package and sign.

[Missinglinq]

Reading this, creating an .accde file was my first thought as well...especially when reading the line "It was a function of Access 2007."

Linq ;0)>

[zeke1]

I gather this wasn't stored on a network and you never backed up the database.

Not the source code no but you did give me an idea - since I did send the install to a number of users via email I was able to pull a copy of that from my sent box at least and run that install for illustration purposes. Here it is but I still don't know how to duplicate it again.

[zeke1]

only thing I can think of is to create a .accde or perhaps package and sign. The latter creates an exe which the user executes to install - but they need access or access runtime to open the installed app. However to hide the access window, have its own icon in the taskbar etc so it appears as a 'non access' program requires a certain level of skill and a high awareness of the environment in which the app is being run.

Both are available under File>Save and Publish>Save Database As, then just follow the prompts

To use your own icon in the window bar when the app is open, go to File>Options>Current Database and select your icon. Ensure you include in your package if using package and sign.

I've been trying alternate means to "simulate" the behavior of a standalone program including create an ACCDE file but it's proving difficult to hide all of Access's control options. I was able to use the command

DoCmd.ShowToolbar "Ribbon", acToolbarNo

To remove the ribbon/menu bar across the top.

But removing the navigation pane from view on the side is proving more difficult. I keep seeing posts from people that suggesting use this

DoCmd.NavigateTo "acNavigationCategoryObjectType"
DoCmd.RunCommand acCmdWindowHide

But when I do this my following command

DoCmd.GoToRecord , , acNewRec

(which previously worked fine) now gives me a:
Run-time error 2046
The command or action 'GoToRecord' isn't available now.

None of these were problems I had previously when I could create install packets

[CJ_London]

was your packaged file sent as a .accde or .accdb? Or perhaps it has the .accdr extension (which forces full versions of access to run in runtime mode). If sent as a .accdb you should just be able to open it in design view with a full version of Access. If sent as a .accdr, try changing the extension to .accdb and opening it with a full version of access

[zeke1]

was your packaged file sent as a .accde or .accdb? Or perhaps it has the .accdr extension (which forces full versions of access to run in runtime mode). If sent as a .accdb you should just be able to open it in design view with a full version of Access. If sent as a .accdr, try changing the extension to .accdb and opening it with a full version of access

It was a setup.exe file bundled with a setup.ini file and an accessruntime.exe

[CJ_London]

but once you have run the setup, you will have an access file - which you can find by looking at the target property of your desktop 'Siev Resource' shortcut

[zeke1]

but once you have run the setup, you will have an access file - which you can find by looking at the target property of your desktop 'Siev Resource' shortcut

Oh, I see. It creates an ACCDR file

[CJ_London]

so as previously advised, change it to .accdb and try to open it with a full version of access. If it opens OK you are good to go, otherwise it is a .accde which cannot be edited, but you should be able to see the various settings in File>Options