Access App (1 Viewer)

Joy83

New member
Local time
Today, 05:48
Joined
Jan 9, 2020
Messages
22
Hi,
I completed an app in access and I wonder how can I have the file in other PCs.
the database is centralized in sharepoint where 5 users have access to it.
I don't have authority to make it executable as EXE file.
so I want to know if there is anyway to have it as a access file only hiding the form design and the code.

any ideas?
 

Gasman

Enthusiastic Amateur
Local time
Today, 13:48
Joined
Sep 21, 2011
Messages
7,144
Create a accde file after splitting the dB. Give each user their own copy of the accde file
 

Ranman256

Registered User.
Local time
Today, 08:48
Joined
Apr 9, 2015
Messages
3,640
here is a Lock app.
select db from list, click LOCK.
users cant design, nor view code, nor see tables.
 

Attachments

  • LockController.accdb
    1.1 MB · Views: 22

Joy83

New member
Local time
Today, 05:48
Joined
Jan 9, 2020
Messages
22
Create a accde file after splitting the dB. Give each user their own copy of the accde file
if I do this ... they still can change the code and view it ...


also ... can I make a default form to open automatically once I open the file?
 

Gasman

Enthusiastic Amateur
Local time
Today, 13:48
Joined
Sep 21, 2011
Messages
7,144
if I do this ... they still can change the code and view it ...


also ... can I make a default form to open automatically once I open the file?
Not that I am aware of?

Set the form for startup in options
 

Isaac

Lifelong Learner
Local time
Today, 05:48
Joined
Mar 14, 2017
Messages
2,734
the database is centralized in sharepoint
Let's backup. What does that actually mean? You attached an Access (.accdb, etc) file onto a Sharepoint list or library? And people are currently opening it directly from the list?

Or do you just mean, I've created Sharepoint lists and linked them as linked table objects in my MS Access database..
 

Joy83

New member
Local time
Today, 05:48
Joined
Jan 9, 2020
Messages
22
Let's backup. What does that actually mean? You attached an Access (.accdb, etc) file onto a Sharepoint list or library? And people are currently opening it directly from the list?

Or do you just mean, I've created Sharepoint lists and linked them as linked table objects in my MS Access database..
It is only linked with access
 

Isaac

Lifelong Learner
Local time
Today, 05:48
Joined
Mar 14, 2017
Messages
2,734
Ok. Assuming you don't have any Access tables, just Sharepoint linked tables, then , as others mentioned, you want to consider your database file a "front end". (we sometimes talk about FE and BE, but there is no back end access file in this case, because there are no access tables - if there were, then you would put all the tables - and only tables - in the BE and retain a single copy of that on a network folder, with each FE linked tables to that single BE).

Give all your users a copy of the front end. They should use it from their local machine. Start > Run > %appdata% is one place that often works well for me to put files like this - maybe in their own subfolder, with a desktop shortcut or something.

As soon as you begin this "distributed FE" method, the next thing you're going to want right away -- or maybe do this before distributing them -- is a fully automated versioning/version distribution system. This means you want a method whereby, each time you make a change to your private "master" development copy of the FE, and place that copy somewhere out in an obscure network folder, ALL of your users automatically GET a copy of that updated FE--without either you or them having to do anything.
Because who knows - sometimes you may need to make changes weekly, daily, or even more often, depending on what happens. The last thing you want is to have to email each person all of these files...etc. An auto version distribution system empowers you to continually improve and respond to requests re: the database without any sweat.

This sounds much harder than it is...See here for some ideas, & review the whole thread for more.

In my opinion, don't move to the fully-distributed-front-ends approach until you've solved for auto versioning, else you'll just have created an un-maintainable scenario. And use Gasman's suggestion for accde/locked. Another solution that might feel easier if you want is to just change the extension from accdb to accdr. Doing this forces the database to open in Runtime (100% locked down). Two things to understand IF you just change the extension to accdr.
1) People could just change it back to accdb if they were that knowledgeable and curious. One more reason to give them a desktop shortcut, rather than putting the file on their desktop--"security by obscurity", as is often the case with Access.
2) Any time your code produces an unhandled error, like a runtime error, say, "Type Mismatch"--and if you don't have an error handler--the application will shut down. This may be true in accde too...I'm not sure, because I always have error handlers in code procedures.

HTH
 
Last edited:

Joy83

New member
Local time
Today, 05:48
Joined
Jan 9, 2020
Messages
22
Ok. Assuming you don't have any Access tables, just Sharepoint linked tables, then , as others mentioned, you want to consider your database file a "front end". (we sometimes talk about FE and BE, but there is no back end access file in this case, because there are no access tables - if there were, then you would put all the tables - and only tables - in the BE and retain a single copy of that on a network folder, with each FE linked tables to that single BE).

Give all your users a copy of the front end. They should use it from their local machine. Start > Run > %appdata% is one place that often works well for me to put files like this - maybe in their own subfolder, with a desktop shortcut or something.

As soon as you begin this "distributed FE" method, the next thing you're going to want right away -- or maybe do this before distributing them -- is a fully automated versioning/version distribution system. This means you want a method whereby, each time you make a change to your private "master" development copy of the FE, and place that copy somewhere out in an obscure network folder, ALL of your users automatically GET a copy of that updated FE--without either you or them having to do anything.
Because who knows - sometimes you may need to make changes weekly, daily, or even more often, depending on what happens. The last thing you want is to have to email each person all of these files...etc. An auto version distribution system empowers you to continually improve and respond to requests re: the database without any sweat.

This sounds much harder than it is...See here for some ideas, & review the whole thread for more.

In my opinion, don't move to the fully-distributed-front-ends approach until you've solved for auto versioning, else you'll just have created an un-maintainable scenario. And use Gasman's suggestion for accde/locked. Another solution that might feel easier if you want is to just change the extension from accdb to accdr. Doing this forces the database to open in Runtime (100% locked down). Two things to understand IF you just change the extension to accdr.
1) People could just change it back to accdb if they were that knowledgeable and curious. One more reason to give them a desktop shortcut, rather than putting the file on their desktop--"security by obscurity", as is often the case with Access.
2) Any time your code produces an unhandled error, like a runtime error, say, "Type Mismatch"--and if you don't have an error handler--the application will shut down. This may be true in accde too...I'm not sure, because I always have error handlers in code procedures.

HTH
This is helpful .. many thanks
 

Joy83

New member
Local time
Today, 05:48
Joined
Jan 9, 2020
Messages
22
Is there any code to hide the top menu Such as “create” “external data”
If there is a code that hide them and unhide them. It will be good
 

isladogs

CID VIP
Local time
Today, 13:48
Joined
Jan 14, 2017
Messages
14,018
here is a Lock app.
select db from list, click LOCK.
users cant design, nor view code, nor see tables.

@Ranman256
The API conditional compilation is incorrect so it doesn't compile in 64-bit.
It should be #If VBA7 instead of #If Win10

I didn't look any further but the dropdown to select a database has no row source.
Why not just have a browse button instead?
 

Joy83

New member
Local time
Today, 05:48
Joined
Jan 9, 2020
Messages
22
@Joy83
You might find it useful to read my article on Improving security in Access databases.
This covers all the different steps you can take with an example app you can use to try out the different methods.
This post is really helpful. It’s comprehensive

in one of the item yo said NEVER put the file in share folder and let users use it from there.

may I know why?
And is it possible that more than one user can use it at the same time.

as I mentioned the only challenge I faced is that I can’t run exe file due to permission issue
 

isladogs

CID VIP
Local time
Today, 13:48
Joined
Jan 14, 2017
Messages
14,018
Each user needs their own copy of the FE on their own local hard drive.
NEVER allow users to run the FE from a shared drive as when more than one user does so, you WILL get corruption at some point.

BTW you cannot make a standalone EXE file from Access. An Access 'executable' is an ACCDE file and still needs Access so it can be used..
Installer applications can package Access files as part of an EXE file for distribution purposes. However, when the file is run, the file(s) are expanded back to separate ACCDB/ACCDE databases.
 

Isaac

Lifelong Learner
Local time
Today, 05:48
Joined
Mar 14, 2017
Messages
2,734
Just adding to what isladogs has well said.
Sometimes I think when people say "I want an exe for my database", most of the goals they are wanting to achieve can be achieved by simply using Runtime without an Access install. Just another option to look into. If your users don't have the full Access installed, and you distribute a [free] Runtime install + a Runtime app, you get a boost in terms of 1) yes you can distribute your file without them having full Access license/installed, 2) there's some security there..
At least I think this is still an option in current versions? It's been a while since I used runtime actually.
If the "full version Access installed" is NOT a concern, and it's just bundled/security, then the ACCDE pretty much solves it, I would think.
Lastly,
in one of the item yo said NEVER put the file in share folder and let users use it from there.
... The most important thing is that you never allow more than 1 user to use a FE file at any time. If, for some reason, you had a reason you couldn't put the application on their machines (I have no idea what this would be, but hypothetically if this were the case), you could probably survive by giving each user their own designated copy of a FE, in network folders. Perhaps validate that, for example, "Username1" is the only person using "Username1.accde" by adding some code to check the network username vs. who that database is designated for in startup. If a developer were doing this--insisting on having the FE on a network, but then including a method to ensure each user's FE was unique--it would most likely just be a symptom of them not having an auto version/distribution system, and therefore wanting all users' FE's to be accessible to him/her...and of course solving for that would, also, solve for any perceived need to have the FE on the network.
Just throwing that in.

Still always preferable to just put it on their local machine. But 75% of the reason not to put a FE on a network is because the implication is that you are allowing people to share a FE...which may or may not actually be the case.
 
Last edited:

Gasman

Enthusiastic Amateur
Local time
Today, 13:48
Joined
Sep 21, 2011
Messages
7,144
I would put a test in my apps. If the file was not in the 'designated' location, I gave a warning and exited the app.
I also did the same if the file was not an accde, though I only tested the actual extension.
 

Isaac

Lifelong Learner
Local time
Today, 05:48
Joined
Mar 14, 2017
Messages
2,734
I would put a test in my apps. If the file was not in the 'designated' location, I gave a warning and exited the app.
That's a great idea. Reminds me of something I do in Excel workbooks w/vba. After being burned a few times with a user having opened them directly from an email, (then complained that they "lost their work"), I learned to include some code that would disable it if the workbook's full name included "outlook".
 

Gasman

Enthusiastic Amateur
Local time
Today, 13:48
Joined
Sep 21, 2011
Messages
7,144
When I worked for Bull on a DPS7, the O/S had 4 libraries you could use.
Three were input only and the other output.

The line editor looked in each library in turn, IL1, I2, I3 and then Lib.

We used to impress this on the students in the class, as they would read a subfile from IL1 perhaps, edit it and save, so the modified version would end up in lib.

They would then close the editor, reopen and issue the same command and lo and behold, their changes had disappeared. :D

One student was a DPS8 person and said 'I know how to solve that 'problem', make IL1,IL2,IL3 & LIB to be the same library.

'True', I said, that could be done, but it defeats the object of giving you all those libraries, just for not learning something simple.? :(

Then when they brought out the Full Screen editor, that always defaulted to LIB, and you had to specify an input library if needed. :D
 

Users who are viewing this thread

Top Bottom