Sorry... couldn't wait, as I've got to get this thought down while the kids are in bed or I'll lose it in the midst of that thing called life :)
Now I'm sure that there's something I'm WAY over simplifying, and I know that I am way oversimplifying some things here, and
I may even be just flat out wrong about this approach AND there's bound to be some sort of performance hit with this method.
I expect and Would like the other Experts to read and comment as this is just a "Proof of Concept," well, not even really a "Proof" at this stage; however, I lack a better word at this point.
However,
Here's something that just popped up in an old thread that I had read about years and years ago however, I'd forgotten it was even a possibility until I saw it again:
Link to an ACCESS query in another ACCESS database I had dismissed this as being useful for any reason whatsoever in V2003 and earlier. Maintaining queries in the front-end was easy enough and so was/is rolling forward updates. However, the method for getting at the queries along with this question... the old brain went... hmmmmmmm
Now I haven't tried this yet on anything of any size of significance; however, my thoughts are to build your main database and all of the queries and forms that you'll need. This should be the main administrative portion of the database.
Split the database into frontend and backend.
Now As forms can be based on queries, open a second database that we'll build to be the kiosk frontend.
Using the method above, "Remote Link" to the queries that will restrict your user's information that you've built in the administrative front end...
You can build a form that takes the user name and password, feed that to your remote queries and so forth.
You can build the reports in the kiosk frontend too.
Now what I did try just now is two separate databases. TestDB1 which will serve as the Kiosk frontend and TestDB2 - This will be our backend/admin.
Now I didn't split TestDB2 as I've suggested above as I'm only looking at POC
In TestDB2 I created a parameter based query (qry_1), and an open query (qry_2) on a very simple table of 26 made-up names and an autonumber field.
Then in my TestDB1 I used the method as given in the thread above to "remote link" to the queries TestDB2.Query1 and TestDB2.Query2. I also built two bound forms, one for each query. When ran, qry_1 prompted for the parameters... couldn't get it to look at the form; however, I didn't try too hard either as this is just POC. qry_2 ran as expected returning everything; however, within the form I could set the filters etc...
Main thing, is when I tried to get at the underlying tables, it wasn't quite easy to do... I knew the path; however, with a Kiosk the user shouldn't have rights to the file explorer. You can remove the Ribbon, QAT, and close the navigation pane down so they wont have access to the queries; thus, making it very difficult to open the backend
I'm thinking that using this method along with the links to secure the database as given before, would make things much more difficult for your end-users to muck about... even making the frontend a ACCDE file after design using this method would keep the user from modifying anything...
Just a thought for the security side.
- The networking side will still need to be addressed by your IT department. That is well beyond the scope of this forum.
- SQL would be for a different thread me thinks.