Query has always been a ‘tricky’ area to get right.
One the one hand, we need to give users an ability to access data as part of their job, and to conduct ‘new’ queries we don’t know we need yet. OTOH, data has to be kept away from prying eyes, and especially so in the financial sector, where we even ban cellphones because the camera can walk away with screen shots.
So, you can’t control access to the file objects, you can’t limit functionality of Query itself..
You *could* start by chanelling all use of query tools through a menu item. You mention menus, so you could also set up a menu page of the queries routinely used, and limit access to them, if you still use Query/400 then allow runqry *select only. If you use QM queries, STRQMQRY and use variables to allow you to prevent the query from being changed.
Only users with suitable training and authorities get to use the query menu itmes.
You can go further – I’ve worked with and on some moderatly sophisticated user level front ends which resolve to
1) a few tables which define fields, files, and joins
2) some tables to define query namesand run time options, selected field values within query names, valid users etc
and the clever bit
a user selects which fields they are interested in, and the values they are selcting on, the system works out the joins, and constructs the query, output to a library or outQ of *our* choosing for a given user. Keeps the query definition, and allows a user to select to use it or change it next time they are in there.
Lots of work of course, but you get to control the data that can be accesses, the fields on the files the user can ‘see’, who can run them, and where and what type of output is produced.