Access Security Warning - Error loading the User Interface

[FriQenstein]

Greetings all,

I've been encountering that typical Access Security Warning message when starting up the DB with the FE.
Initially, I've separated the Front End from the Back End and just link the Tables from the Back End to the Front End and then save the Front End as a .aacde executable file.

This has been working fine, even though I still get the security warnings.

Now, After clicking the Open button to bypass the Security Warning, my Front End opens up completely shrunk to nothing and even resizing it shows absolutely nothing in the window.

I'm uncertain why this is happening or what has caused it.

Any ideas?
Pics attached to illustrate what I'm talking about.



Thanks.

[isladogs]

Ah. SIMs..... Looks like you're working in a UK school.

Four questions
Is the BE an ACCDE file?
Are you using a trusted location?
Are you using a runtime version of Access?
Have you tried maximising your shrunken window then saving?

[FriQenstein]

Howdy.
Nope, I'm not in a UK school. I'm in Texas actually. I just used that acronym for the name of the program.

Anyway, answers:
1) Yes and No. I've tried it as an ACCDE file and a regular DB file.
2) Yes, the location is trusted. I have the Back End on our NAS and each user has a copy of the Front End which is has links to the tables in the Back End as described in OP.
3) Not sure... I'm using Access 2016, so... ya. I guess so
4) Sort of... the background window opens up as full screen then that little tiny shrunken wee bit in the pic above is the Main Menu Front End GUI. That GUI isn't maximized as I've set it up to be a specific size.

EDIT:
Here is a screenshot of what it should look like when it opens...

[FriQenstein]

Note:
If I just save the Front End file as a regular Access file, and not a .ACCDE executable extension, it appears to work just fine.
I guess I could leave it as is... but the main purpose of having it saved as an executable is so that it is locked on each users machine and they can't make any 'OOPS'.

[isladogs]

The backend should only contain tables. There is absolutely no point in making it an ACCDE
The front end on the other hand should normally be an ACCDE file so the code isn't avaialble to end users.

Actually the screenshot tells me you are using the full version of Access. If it was the runtime, the menu would just show File & Home

The security dialog is being displayed because the file or the location is NOT trusted.
Go to File...Access Options...Trust Center then Trusted Locations and make sure you trust the location of the FE - if necessary do so with the BE also.

Sorry but your final answer is unclear. You seem to be saying its that size because you've made it that size. If so, enlarge it & save it.
Or if you've specified the size in code, alter the code
Or add the line DoCmd.Maximize in the Form_Load event

BTW in case you missed it - I also answered your query search criteria question earlier today

[FriQenstein]

I've gone through the Trust Center and added my NAS location where the BE is stored.
It still seems to do the same thing.

If I save the FE as an executable, it has that glitch. If I leave it as the normal file that Access creates then it appears to work accordingly.
Still trying a few different options.

Regards.

[FriQenstein]

Still trying to sort this one out.

Here are my settings in the Trust Center:
Trusted Locations: I've added the path to the Back End file located on the NAS
Macro Settings: I've enabled ALL macros

I have also tried adding the location of the FE file to the trusted locations, but that didn't seem to help either.

I'm not certain what else to check. I can leave the file as the normal Front End file (not an exe ACCDE file) which will work fine, however it is too large to send through email, so if I have to make changes while in the field, I won't be able to email it back to the office.

Still searching Google for examples and possible related scenarios, but for the most part I just keep finding things that don't quite match or reference other links I've already visited to no avail.

Regards.

[Micron]

Just to clarify, an accde or mde isn't an executable, per se. It means the file is "execute" only, and identifies a db whose code project has been completely compiled and the visual code removed. Of course, there are other characteristics, but your post isn't about those.

Since you seem to have correctly dealt with Trusted Locations for fe and be, I was wondering if you checked with an IT person to see if there's a Windows group policy set that prevents such file types from running.

[isladogs]

I would always suggest trusting the location for the FE
As a test try ticking allow trusted locations on my network though you shouldn't need to do so.

I wouldn't recommend enabling all macros or all ActiveX code

Micron's point is worth following up. Possibly a user permissions issue?

If you are able to upload a stripped down copy of both FE & BE here, I'll be happy to look at it.

[FriQenstein]

@Colin,

I'll look into those. The thing is, when I first deployed the DB, the locations of the files are in the exact same place as they are now. And it worked with no issues.
Other than changes that I've made to the FE GUI or the Tables in the BE, I've not changed anything else... this is what baffles me. It worked previously but now has issues.

Like you've mentioned, unless one of the other guys has semi-recently changed something on the network permissions, theoretically everything should still be working as it once was.

[FriQenstein]

I still cannot seem to get this issue resolved.
I'm going to try and setup a new temporary DB and split it like I did this existing one to see if it generates the same type of error/glitch.
I will post the results here.

Hopefully I can find some discrepancy between the two which will allow me to sort out the issue.

[FriQenstein]

I would always suggest trusting the location for the FE
As a test try ticking allow trusted locations on my network though you shouldn't need to do so.

I wouldn't recommend enabling all macros or all ActiveX code

Micron's point is worth following up. Possibly a user permissions issue?

If you are able to upload a stripped down copy of both FE & BE here, I'll be happy to look at it.

@Colin, I'd appreciate that. What exactly would I need to do to 'strip it down' for you?

Regards.

[isladogs]

Make a backup copy of your db.
Remove everything that's not needed to observe this issue. Remove most of the data and change anything confidential.
If its a split database, if possible convert any remaining tables to local tables unless that make the issue unobservable.
Debug...compile and fix any errors.
Check the issue still occurs
Compact and zip. It needs to be less than 2MB.

When you upload tell me exactly what to do to reproduce the issue.
Are you using 32-bit or 64-bit Access. Access 2016/365?

[FriQenstein]

Make a backup copy of your db.
Remove everything that's not needed to observe this issue. Remove most of the data and change anything confidential.
If its a split database, if possible convert any remaining tables to local tables unless that make the issue unobservable.
Debug...compile and fix any errors.
Check the issue still occurs
Compact and zip. It needs to be less than 2MB.

When you upload tell me exactly what to do to reproduce the issue.
Are you using 32-bit or 64-bit Access. Access 2016/365?

I'm using the following:
OS: Win10
Access: 2016 32-bit
I have removed the data from the main inventory Table, and imported the tables so the FE & BE are now together as one.

What I've been doing, initially, was splitting the FE & BE. When I import the tables I import them as a link so as to keep FE & BE separated accordingly.
Then, I usually make the FE an ACCDE executable file. This is where the issue starts.
That's pretty much it... aside from the BE being stored on a NAS and the FE on my laptop, connected via local LAN to the NAS.

I have zipped up the DB to make it small enough to upload... so here goes.

Cheers.

[isladogs]

I thought you were going to strip it down - 20MB after unzipping.
Did I really need all those forms & reports?

Converted to ACCDE & got the same behaviour as you described.
There are some important things you need to do before I try & identify the issue
Its also going to be tricky for me to identify an issue in an ACCDE so you need to make it as easy as possible to minimise the time needed

Things to do...

You have ticked Require Variable Declaration in VBE Options - GOOD!
BUT you haven't amended existing code modules - BAD!

Go through each code module & make sure each starts with the following two lines

Option Compare Database
Option Explicit

Most modules only have the first line - at least one item has neither line
Once you've done that Debug...compile again and fix errors

You also have empty events in various modules e.g.

Private Sub Command66_Click()

End Sub

Delete all of these

You have record source errors in at least forms e.g. Acoustic_Inv_Input_Form ; Acoustic_Owned_Full_Inv-Rpt
In design view, you'll see a green triangle where controls have issues - look at the SQL and you'll see why - Expr1; Expr2 etc
Similarly in several reports
Fix all of these as well

After that check it all works correctly in ACCDB. Debug AGAIN.
Next make a backup then DECOMPILE. See http://www.fmsinc.com/microsoftacces.../decompile.asp and then compact
Now create an ACCDE
With luck doing all the above will fix the issue BUT if not copy ALL items into a new database and COMPACT again
Create an ACCDE again
Does it work now?

Strip down removing all irrelevant items and upload again if it still doesn't work.
Do I actually need anything other than form SAM?