- Local time
- Today, 10:31
- Joined
- Feb 28, 2001
- Messages
- 27,270
Here's the scenario.
Dept. of Defense site, so the peons (read contractors) do not get to set policies and such on their machines. I have a database that has been split to FE/BE configuration. Both are .MDB files right now. MDE down the road, perhaps. BE is (at the moment) pure tables. Later I'll add code to stop folks from direct-opening it, but right now, that's a future consideration. The FE has queries, forms, reports, and code. No macros. It was developed originally in Ac2003. I'm now using Ac2007, but I've never saved the DB in 2007 format. It still tells me it is Ac2000/2003 format.
So, I load up the FE and BE to a shared area, with code in the FE that if someone actually tried to run it from the share, it would detect something was wrong and would barf. (But it would TELL the user to make a local copy on his/her workstation hard drive before it barfed.) The table link manager confirms that I can see the BE just fine from the FE.
I've tested it using Ac2007. Everything works fine for me except a few forms that are still under construction. They wouldn't run correctly for anyone, me included. I'll fix that, too. I have put code in the DB to decide which version of Access I'm using, 2003 or 2007, and don't try to disable the ribbon or object panes in 2003. In 2007, this works like a champ.
OK, so prepping the FE for sharing, I define the staring form which is just a big old switchboard. When that launches, I run code behind the switchboard in its Form_Open event to query the terminal as to who is running the session. We get this info from our domain-based login so there is no dialog. I explicitly DID NOT try to implement workgroup security in this DB. Everything looks at who you are and your role code (which it gets from a lookup table: DBA, Guest, Sys-Admin, etc.) Therefore I did not try to implement stuff according to owner ID. If it weren't for the filtration code that intercepts the Form_Open(cancel) event on the switchboard and all other forms, the DB would be wide open.
I have logging code in that _Open event to tell me who is logging in by their domain ID, what is the computer name, and in what folder they were opening the FE file. It logs me perfectly whether I am using the wide-open version of the FE or the version that has been compressed, repaired, and otherwise secured with respect to things that it allows. (All the stuff that, in Ac2007, is found when you click the Windows icon, Database options, and set up "Current database." That explicitly includes "Preferred mode Open Shared")
Logging still works for me correctly if I update the tUSR table to change my role to a non-DBA. I also have digitally signed the code in the "prepared" copy of the DB just before I copy it to the shared area.
So I'm showing this to my boss. He clicks on it but he has Ac2003. He cannot get the switchboard to open automatically on his terminal even though it works for me. The window changes names according to the Title info put into the database when I prepped it. But NOTHING logs. Not even the event log that doesn't try to look up who you are in my tables, it just logs the raw event of computer name, username (from the terminal), database file name (which gives me path). That is the very first bit of my VBA code that should execute, but it does not.
After thinking about this, I checked my boss's Windows rights. Full Control, no problem there. The file will not open correctly for him. So now I'm trying to figure out what is different from his terminal to mine other than Ac2003 vs Ac2007. I'm trying to figure out why it opens for me but the same FE goes bonkers for him.
I'll revisit file-level security Friday when I get back to work. In the meantime, does anyone else have a suggestion as to where to look? This is driving me nuts because I explicitly avoided using anything related to Workgroup security. I am rolling my own security all the way and as far as I can tell, it is working correctly.
I'm open to suggestions. (Since this forum can be publicly searched from Google, keep the suggestions clean, please.)
Dept. of Defense site, so the peons (read contractors) do not get to set policies and such on their machines. I have a database that has been split to FE/BE configuration. Both are .MDB files right now. MDE down the road, perhaps. BE is (at the moment) pure tables. Later I'll add code to stop folks from direct-opening it, but right now, that's a future consideration. The FE has queries, forms, reports, and code. No macros. It was developed originally in Ac2003. I'm now using Ac2007, but I've never saved the DB in 2007 format. It still tells me it is Ac2000/2003 format.
So, I load up the FE and BE to a shared area, with code in the FE that if someone actually tried to run it from the share, it would detect something was wrong and would barf. (But it would TELL the user to make a local copy on his/her workstation hard drive before it barfed.) The table link manager confirms that I can see the BE just fine from the FE.
I've tested it using Ac2007. Everything works fine for me except a few forms that are still under construction. They wouldn't run correctly for anyone, me included. I'll fix that, too. I have put code in the DB to decide which version of Access I'm using, 2003 or 2007, and don't try to disable the ribbon or object panes in 2003. In 2007, this works like a champ.
OK, so prepping the FE for sharing, I define the staring form which is just a big old switchboard. When that launches, I run code behind the switchboard in its Form_Open event to query the terminal as to who is running the session. We get this info from our domain-based login so there is no dialog. I explicitly DID NOT try to implement workgroup security in this DB. Everything looks at who you are and your role code (which it gets from a lookup table: DBA, Guest, Sys-Admin, etc.) Therefore I did not try to implement stuff according to owner ID. If it weren't for the filtration code that intercepts the Form_Open(cancel) event on the switchboard and all other forms, the DB would be wide open.
I have logging code in that _Open event to tell me who is logging in by their domain ID, what is the computer name, and in what folder they were opening the FE file. It logs me perfectly whether I am using the wide-open version of the FE or the version that has been compressed, repaired, and otherwise secured with respect to things that it allows. (All the stuff that, in Ac2007, is found when you click the Windows icon, Database options, and set up "Current database." That explicitly includes "Preferred mode Open Shared")
Logging still works for me correctly if I update the tUSR table to change my role to a non-DBA. I also have digitally signed the code in the "prepared" copy of the DB just before I copy it to the shared area.
So I'm showing this to my boss. He clicks on it but he has Ac2003. He cannot get the switchboard to open automatically on his terminal even though it works for me. The window changes names according to the Title info put into the database when I prepped it. But NOTHING logs. Not even the event log that doesn't try to look up who you are in my tables, it just logs the raw event of computer name, username (from the terminal), database file name (which gives me path). That is the very first bit of my VBA code that should execute, but it does not.
After thinking about this, I checked my boss's Windows rights. Full Control, no problem there. The file will not open correctly for him. So now I'm trying to figure out what is different from his terminal to mine other than Ac2003 vs Ac2007. I'm trying to figure out why it opens for me but the same FE goes bonkers for him.
I'll revisit file-level security Friday when I get back to work. In the meantime, does anyone else have a suggestion as to where to look? This is driving me nuts because I explicitly avoided using anything related to Workgroup security. I am rolling my own security all the way and as far as I can tell, it is working correctly.
I'm open to suggestions. (Since this forum can be publicly searched from Google, keep the suggestions clean, please.)
Last edited: