Can Access 2010 and runtime 2010 both run on Office 365? (1 Viewer)

Emily

Registered User.
Local time
Today, 00:02
Joined
Jul 16, 2010
Messages
45
Hi,

I am currently running Access 2010 on Win10. Users are using Access runtime 2010 to open the App because they don't have ms Access on their pc.
We are planning to switch from Win 10 to Office 365. My questions are

1. Can Access 2010 runs on Office 365 without problems

2. Office 365 comes with Access App, but I don't want the to users to have access to tables and accidentally change data when opening the app, so I assume I would need to install runtime in Office 365, will the old 2010 runtime works in Office 365 or do I have to use the Office 365 runtime instead?

3. Can you turn off or disable the Access app from Office 365?

Any info will be greatly appreciated !!
thanks,
Emily
 

theDBguy

I’m here to help
Staff member
Local time
Today, 00:02
Joined
Oct 29, 2018
Messages
18,992
1. Can Access 2010 runs on Office 365 without problems
I think Access 2010 can run with Office 365, but the "without problems" part would be the key words here. Depending on environment settings, you could potentially run into some issues.

2. Office 365 comes with Access App, but I don't want the to users to have access to tables and accidentally change data when opening the app, so I assume I would need to install runtime in Office 365, will the old 2010 runtime works in Office 365 or do I have to use the Office 365 runtime instead?
Is your database properly split? Whether you use 2010 or O365, it's hard to prevent users from accessing the tables. To make sure only the Runtime version runs on a machine, you'll have to remove the full version of Access. You should be able to use either a 2010 or O365 runtime to run your 2010 database.
 

Pat Hartman

Super Moderator
Staff member
Local time
Today, 03:02
Joined
Feb 19, 2002
Messages
36,352
If the users have the full version of Access installed, there is no point in installing the runtime. They can just open Access and open your app. You need to lock down the app if you have medlers. Otherwise, just compile to accde and rename to accdr. That keeps people from accidently doing damage.

Secure the BE by placing it in a hidden folder that the users can't see.
Distribute a new FE every time the user opens the application.
 

isladogs

CID VIP
Local time
Today, 08:02
Joined
Jan 14, 2017
Messages
16,241
Yes. Access 2010 & 365 can co-exist.
As already stated, there is no point installing both runtime and full Access for the same version and if you try, you will be unsuccessful.

For detailed information, see my article
 

Emily

Registered User.
Local time
Today, 00:02
Joined
Jul 16, 2010
Messages
45
My DB is properly split into FE and BE. I normally compile the App into ACCDE when deploying new version.
However with Office 365, users will get full version of Access, meaning they can click on the left pane and open tables to change data. How can I prevent that?
 

isladogs

CID VIP
Local time
Today, 08:02
Joined
Jan 14, 2017
Messages
16,241
See my article
 

Emily

Registered User.
Local time
Today, 00:02
Joined
Jul 16, 2010
Messages
45
Thank You Pat! I just tried renaming from accde to accdr. It works !! thank very much!
 

Emily

Registered User.
Local time
Today, 00:02
Joined
Jul 16, 2010
Messages
45
Thank you everyone who have replied to my post. I learn a lot from you all. You are all my lifesaver ! thanks!
 

isladogs

CID VIP
Local time
Today, 08:02
Joined
Jan 14, 2017
Messages
16,241
I wouldn't rely on renaming as ACCDR alone. Anyone can easily rename as ACCDE or ACCDB and all security is 'lost'
 

Emily

Registered User.
Local time
Today, 00:02
Joined
Jul 16, 2010
Messages
45
oh my source is in a different drive which the users have no access to it. I have to manually move the compiled version to the user's drive, so there is no way the user will have access to the accde. thanks
 

isladogs

CID VIP
Local time
Today, 08:02
Joined
Jan 14, 2017
Messages
16,241
You misunderstood my point. Renaming a file as ACCDR is easily reversible.
So, if the user has a full version of Access, they will be able to rename your file again and regain the ability to do anything they want to do.
Did you read my article - see link in post #6
 

theDBguy

I’m here to help
Staff member
Local time
Today, 00:02
Joined
Oct 29, 2018
Messages
18,992
My DB is properly split into FE and BE. I normally compile the App into ACCDE when deploying new version.
However with Office 365, users will get full version of Access, meaning they can click on the left pane and open tables to change data. How can I prevent that?
Only way I can think of preventing users from directly accessing the table is to uninstall the full version app and only install the runtime version (that will eliminate the "left pane" from the equation).
 

Pat Hartman

Super Moderator
Staff member
Local time
Today, 03:02
Joined
Feb 19, 2002
Messages
36,352
I didn't mean to imply that renaming to .accdr is a security measure. It is a way to keep people from ACCIDENTALLY messing things up. Colin sells his app to the public. He has a very different problem from what most of us face with internal distribution and requires significant security.

Using a few additional precautions is always a good idea and reading Colin's writing on security will be a big help. But, you also need to know your userbase and you need to make sure that they know that attempting to get around the user interface is grounds for dismissal.

With O365, you don't really have control over what gets installed and what doesn't. The user can just log into his O365 account and install whatever apps are available. You can ask the IT department to not distribute Access but they may need it for other reasons.

You could install an older version of the Access runtime than what is current with O365 and you could have your app check its version and refuse to operate with a newer version but that still wouldn't stop them from using the full version of Access to open the database. Access can be hacked. That's its biggest weakness.

WHY would people open the app and change the tables directly? Most people wouldn't even think of it. Is the BE ACE or SQL Server? If it is SQL Server, you can not leave the tables linked but instead link them in your start up code. That will make the database useless and as long as you distribute an .accde (renamed to .accdr), they can't look at the code to figure out how to get around this.

One of the things you can do with SQL Server et al, is to use custom logins rather than Windows logins. It's more work for you and the DBA but it prevents a user from creating a new, empty database and just linking to the tables in SQL Server because Windows authentication will allow that. You can either obfuscate the userLogin or the password using a local table which you should always hide. OR, even do it with code. An easy idea is to just reverse the login he uses to log into your app and you use that to log into SQL Server manually when the app opens. So his login is myname and you convert that to emanym and that is what is used along with his windows password. Or reverse the name and use a fixed password that you and the DBA agree on. Obviously you need to document this type of strange stuff so if you or the DBA gets hit by a bus, it doesn't lock up the whole app forever.
 
Last edited:

gemma-the-husky

Super Moderator
Staff member
Local time
Today, 08:02
Joined
Sep 12, 2006
Messages
14,835
One problem with .accdr is that the user won't get tools such as filter and sort that they would get with full access. You can code them, but it's a lot of bother, especially when your company had paid for the full package. Surely you can train them not to fiddle with the data. (besides the other suggestions).
 
Last edited:

Pat Hartman

Super Moderator
Staff member
Local time
Today, 03:02
Joined
Feb 19, 2002
Messages
36,352
All the .accdr does is to tell Access to pretend to be the Runtime engine and I agree with Dave, it suppresses integrated features because it hides them the same way the Runtime does.

I complain to MS on a regular basis but they ignore me. The right-click menus combine design options with user options and so the Runtime just suppresses the right-click menus rather than just suppressing the design options. Maybe if all of you also complain we could make some traction. Use the Feedback option. It also lets you send images. I just sent another one yesterday. I was working on the Relationships diagram and the schema is pretty large and so takes 4 pages to print. I create shadow copies of some tables so I can eliminate all the crossing lines that causes. So, tblCustomer is in three places. The shadows have suffixes of _1 and _2 so you know what they are. The problem is that although the relationship lines show on the diagram, they do not print!!! Very annoying.
 

Pat Hartman

Super Moderator
Staff member
Local time
Today, 03:02
Joined
Feb 19, 2002
Messages
36,352
Thanks Colin. I'll take a look at it.

It doesn't excuse MS for breaking their report though. They really need better testers and they need to learn about coupling and cohesion so when they change procedureA they can stop breaking procedureB because of some forgotten dependency.
 

isladogs

CID VIP
Local time
Today, 08:02
Joined
Jan 14, 2017
Messages
16,241
What exactly is the problem with the MS relationships report?
I know its clunky but the relationship lines are visible for me, both on screen & on the printed report (not something I do very often though ...

What I dislike about it is that whilst you can drag the tables around in report view, the lines & RI symbols don't move at the same time.
To do it properly, you need to arrange the items in the relationships window
 
Last edited:

Pat Hartman

Super Moderator
Staff member
Local time
Today, 03:02
Joined
Feb 19, 2002
Messages
36,352
I tried Allen's report and it has the same bug although it seems to recognize some problem and displays a message. But, it also works sometimes, just as the MS version does. It doesn't ignore ALL shadow tables, just some????
ErrRelRpt1.JPG
ErrRElRpt2.JPG
errRelRpt3.JPG
 

Users who are viewing this thread

Top Bottom