Close Openquery in Runtime version of Access Program

[Gail]

I have an Access program that I convert to an Accdr version for the Users to use.


The program contains many Queries that I open using a Form.
I would like the Users to be able to use this Form and be able to open the Queries.

When I open the Query in the Accdr version, there isn't an X to close the Query.
The only way I can close the query is to close the program.

Does anyone know how to close an open query in the Accdr version?
Thanks

[CJ_London]

It is considered bad practice to enable users to view queries (or tables) directly, on forms and reports, even if you rename your file .accdr users can easily rename it back again.

Is your app using tabbed documents rather than overlapping windows? If so, I seem to recall an issue that in runtime the X does not appear, but there is a possible fix.

1. Open your app
2. change the window options (File>Options>current database) to overlapping
3. save and exit database
4. open database again to check windows is overlapping
5. if they are go back to windows options and change back to tabbed
6. save and exit database
7. reopen should be fixed

[Gail]

Thank you so much for your reply.
I should probably have explained things better.
When I create the executable (accde), I secure the database. I hide the tables, and change properties for specialkeys, bypasskey etc. No one is able to get to the Navigation Pane, whether they are using accde or accdr.
I’m not using tabs. I want the users to exit the forms through an exit button I created so I can use an event procedure to validate data.
The queries I want to open from the form are based on complicated select Stored Procedures in SQL Server and they are not updatable. They are for analytical purposes and only the manager has permission for that form.
There are over 100 of these analytical queries and I would open them from the source code and send the data to the manager at her request. I thought it would be much better to create a form where she can open the queries when she wants.
Since there are over 100 of them, I didn’t want to create a report for each one, as I know she would never print them anyway, she just wants to view the data. So, I thought it would be easiest to open the queries, as they don’t allow the manager to directly update data.
She uses the accdr and there is no way to close the query except by closing the program.

[Gicu]

How do you open the queries, do you have a list where you select it then open it? If yes why not just the reverse, add a new button to close the queries and use:

On error resume next ' in case the query is not open
Docmd.Close acQuery, Me.lstBoxQueries 'replace with your control name holding the query list

Cheers,

[davegri]

Try ALT+F4 to close the query

[Gail]

thank you for your reply
I have several option groups to choose which query to run.
in the option group afterupdate event, I use the Docmd.openquery command to open the correct query.
When the query opens, it is the focus.
I'm not able to go back to the form without closing the query, and I can't close the query in the runtime version of the program.
I'm not sure where I would put the button.

[CJ_London]

So to be clear you are using overlapping windows. I've just tested on my system and the X is there - however you said ' I want the users to exit the forms through an exit button I created so I can use an event procedure to validate data.' so sounds like you have turned off that functionality - perhaps need to turn it on when opening queries.

Another way might be to create a blank form with just your exit button and a subform control.

Instead of the user opening the query, they open this form and you pass the name of the query in the openarg parameter

in that forms open event have some code

me.subformname.sourceobject="query." & me.openargs

you may also want some code in the resize event to ensure the subform resizes with the form (or use the vertical and horizontal anchor properties)

I secure the database. I hide the tables, and change properties for specialkeys, bypasskey etc. No one is able to get to the Navigation Pane, whether they are using accde or accdr.

just so you are aware, these are easily overcome if someone has some basic access knowledge.

[Gail]

thank you so much for your suggestions.
I will try them

[davegri]

In regards to post #5,

CTRL+F4 will close the query
ALT+F4 can close the database, so avoid this

If you hit CTRL+F4 twice, it will also close your open form, perhaps leaving you with a blank screen and no way to get the form back.
A workaround for this is to create an AutoKeys macro with a key combination to load the necessary form. I like to use CTRL+M.
As a reminder to the user, you can define the form caption to be 'CTRL+M will recall this form', and hope they remember it.

In the macro below, both the = prefix and the () suffix are required for the function callout

Option Compare Database
Option Explicit


Public Function fcnAutoKeys_OpenMain()
    DoCmd.OpenForm "FormFirst"
End Function

[Gail]

Thank you so much, davegri
That works perfectly.

[davegri]

You're welcome. Glad to help.

[Gail]

just so you are aware, these are easily overcome if someone has some basic access knowledge.

Hi, I've just noticed this.
I have a basic access knowledge, but obviously not enough.
Could you please let me know what I'm missing or point me in the right direction of where to find it?
Thanks

[CJ_London]

Could you please let me know what I'm missing or point me in the right direction of where to find it?

It is a wide open subject. You need a defined security policy defining what you are trying to protect, from whom, from doing what and by what means. Then you can start to put in place the appropriate protection. Your app will be safe enough from users who only have runtime installed as they do not have the ability to create new objects/forms/queries etc. But anyone with a full version can easily find what you are hiding. No application can be 100% secure. At the moment your forms/reports and modules are protected from being changed by virtue of the fact you have compiled to .accde, but that is all. All your security can be easily overcome by opening your app from a different access app. As an example, create a new application and use the linked table manager to link to your .accdr tables

Or copy this sql into a new query - change the path\dbname to suit

SELECT * FROM MSysObjects IN 'c:\path\dbname.accdr'

what do you see?


@isladogs has a website demonstrating different levels of security - see this link https://mendipdatasystems.co.uk/secu...594398127.html. I reckon you are not quite at level 1 at the moment

So back to your security policy

What are you trying to protect? - data? code? etc
from whom - authorised users? hackers? unauthorised users?
from doing what? - deleting data? changing something not controlled by the app? copying data to take to a competitor? using without permission/authorisation?
by what means? app in location? app copied somewhere else? etc

'everything' is not an answer. each 'what' will have different whoms, doing whats and means

you might also want to google/bing terms like 'sql injection'

[Gail]

Thank you for this information

[isladogs]

Hi Gail
As already mentioned, I have a number of articles on improving security in Access.
You might find this two part article particularly relevant https://www.isladogs.co.uk/improve-security/index.html
The second part includes an example app you can use for testing.

Whilst you're already aware of some of the info covered, I hope you will learn some new info you can use.

Returning to the original question, consider using a form and subform. The form has a combo or listbox for users to select the query.
The selected item is then used as the source object for the subform. Would that work for you?

Apologies if that idea has already been suggested by someone else as I've only just skimmed this lengthy thread