I have a multi user database and users were created by user level security
wizzard - as I mentioned in message before. Everything works fine for those
users, but now I have another problem. I have another database with linked
tables from secured database.
How can I approach secured database from the unsecure one?
Thx
"zdenko"
news:fj6jo5$b5$1@ss408.t-com.hr...
>I have a multi user database and users were created by user level security
>wizzard - as I mentioned in message before. Everything works fine for those
>users, but now I have another problem. I have another database with linked
>tables from secured database.
> How can I approach secured database from the unsecure one?
>
You can't, otherwise security wouldn't be much use. You'd need to open your
*unsecured* database whilst joined to your custom workgroup so that the
linked tables would work.
Keith.
www.keithwilby.com
OK, but how can I join workgroup from unsecured database to secured?
> You can't, otherwise security wouldn't be much use. You'd need to open
> your *unsecured* database whilst joined to your custom workgroup so that
> the linked tables would work.
>
> Keith.
> www.keithwilby.com
"zdenko"
news:fj79tt$qc0$1@ss408.t-com.hr...
> OK, but how can I join workgroup from unsecured database to secured?
>
>
Use a desktop shortcut to open your unsecured mdb using the "/wrkgrp"
switch:
"Full path to MSACCESS.EXE" "Full path to your unsecured database.mdb"
/wrkgrp "Full path to your workgroup file.mdw"
including quotation marks.
Keith.
www.keithwilby.com
Thanks for correct answer. It crosses my mind before and I've tried it but
shortcut was misspelled.
I have billing application whitch conists of two databases. Employers are
entering data in first and the other
database should be triggered once a day and make some file for delivering.
Idea is triggering by scheduler.
Now I have issue concerning security of "usecured" database because every
time it's triggered username / password dialog pops up.
Is there a way to avoid this pop up window?
"Keith Wilby"
news:4757aff0$1_1@glkas0286.greenlnk.net...
> "zdenko"
> news:fj79tt$qc0$1@ss408.t-com.hr...
>> OK, but how can I join workgroup from unsecured database to secured?
>>
>>
>
> Use a desktop shortcut to open your unsecured mdb using the "/wrkgrp"
> switch:
>
> "Full path to MSACCESS.EXE" "Full path to your unsecured database.mdb"
> /wrkgrp "Full path to your workgroup file.mdw"
>
> including quotation marks.
>
> Keith.
> www.keithwilby.com
Your problem is that you are trying to perform Enterprise operations
with a Micro database system (Access).
Access is quite remarkable for a Micro database system, but it is still
a Micro database system and does not have Enterprise capabilities. For
that you need to step up to an Enterprise system like MS Sql Server.
Rich
*** Sent via Developersdex http://www.developersdex.com ***
"zdenko"
news:fj980r$fa5$1@ss408.t-com.hr...
> Thanks for correct answer. It crosses my mind before and I've tried it =
but=20
> shortcut was misspelled.
> I have billing application whitch conists of two databases. Employers =
are=20
> entering data in first and the other
> database should be triggered once a day and make some file for =
delivering.=20
> Idea is triggering by scheduler.
> Now I have issue concerning security of "usecured" database because =
every=20
> time it's triggered username / password dialog pops up.
> Is there a way to avoid this pop up window?
>=20
If I understand you correctly you want to open the database scheduled, =
but you need passwords and a login ??
You can avoid the pop-up by providing the password and user with =
switches in your shortcut like /user "Username" /pwd "Password"
BUT of course security might be ALL gone now .... (everyone can read the =
shortcut)
BUT maybe this helps ...
Arno R
I will try your suggestion tomorow. Second database has linked tables to
secure one and
this database/application is on secured computer. All I need is starting
application/database when
computer is locked.
Just tried and it works! That's all I want this application to do. Thank's
very much!
On Dec 10 2007, 10:33 am, Fester Bestertester
wrote:
> Keith Wilby wrote:
> > Are you really the same poster as the one who posted security advice in
> > the "Thinking about going multiuser with user security,..." thread?
>
> I deeply appreciate all the technical feedback actually answering my
> question. Since it's now so obvious that I'm an incompetent fool who
> shouldn't be anywhere near a computer, let's review.
>
> Let's say for the sake of discussion that I have a multi-user database
> that's split between a back end (data only) and a front end
> (application). The back end resides on a server and the front end is on
> the user's machine.
>
> Let's further say for the sake of discussion that I've already added and
> tested a set of modules triggered by an AutoExec macro that verifies
> that the link from front to back is valid, and, if not, raises a File |
> Open dialog that allows the user (or a sysadmin) to point the front end
> to the correct path if necessary.
>
> Now let's suppose that I want security which is specific to that
> application only, and does not affect any other instances of Access on
> the local machine, even though, in that same thread, "Thinking about
> going multiuser with user security..." one "Lyle Fairfield" posted,
> "Many developers do almost none of the above, with the exception of
> splitting their applications. I am one of them."
>
> To accomplish this, I would perform the following steps:
>
> 1. Open an empty session of Access.
>
> 2. Select Tools | Security | Workgroup Administrator...
>
> 3. Select Create...
>
> 4. Give the new security file an ID, note the User, Organization, and ID
> information, and click OK.
>
> 5. Browse to the appropriate location where I wish to store the mdw file
> and name the file, i.e., MyApp.mdw.
>
> 6. Select Tools | Security | Workgroup Administrator, select Join, and
> navigate to the new mdw file.
>
> 7. Select Tools | Security | User and Group Accounts, and create the
> users and groups I wish to have.
>
> 8. Select Tools | Security | User and Group Permissions, and configure
> the permissions for the groups.
>
> 9. Select Tools | Security | Workgroup Administrator, select Join, and
> re-join the default System.mdw file.
>
> 10. For distribution, copy the backend database file to a shared
> directory, copy the front end application file to the user's machine,
> and copy the security file to a shared directory.
>
> 11. At this point, according to MSKB article 305542, "Understanding the
> role of workgroup information files in Access security":
>
> "To associate specific secured database files with their workgroup
> information files, you must create desktop shortcuts. Each desktop
> shortcut must have the Command-Line option set to start a specific
> database and use the specific workgroup information file secured with
> that database.
>
> "To start a secured Access database named MyApp.mdb in a folder named
> MyAppFolder with the workgroup information file used when establishing
> security on MyApp.mdb, the command-line syntax must include the /WrkGrp
> command-line switch, for example:
>
> "C:\Program Files\Microsoft Office\Office\MSAccess.Exe"
> "C:\MyAppFolder\MyApp.MDB" /wrkgrp "C:\MyAppFolder\System.MDW"
>
> "You can create a shortcut and enter this syntax as the target of the
> shortcut."
>
> 12. The result is that there is now security which is specific to this
> particular application and does not affect other sessions of Access on
> the user's machine.
>
> The user can still run Access, with the default System.mdw, file to open
> or create mdb files, but if the user double clicks the desktop shortcut
> to the "MyApp.MDB" application, they will get a password prompt using
> the security file that is specific to that application.
>
> Unfortunately, this security does not apply if the user opens an empty
> session of Access, or opens Windows Explorer, and navigates directly to
> the MyApp.mdb file. So it appears that the only way to defeat this would
> be to turn off Windows Explorer and/or remove all Access-related icons
> from the desktop except the shortcut to MyApp.mdb.
>
> Or, is there something unrelated to desktop lockdown, and specific to
> Access security, that I'm missing? It's already been effectively pointed
> out that I'm incompetent, so what, exactly, was so obvious about Access
> security that anyone should have been able to see it?
I had the same problem securing my database. The work-around that I
used to prevent unauthorized access to the original database was to
remove permissions for the admin user, the default user for any access
database, in the database I secured and linked the private
Security.MDW to.
I then inserted a little chunk of code that executes on startup that
checks the username. If the username is "admin", the code displays a
message telling the user that they must open the database using the
designated shortcut. The code then closes the database.
This method has worked for me. It's not pretty but it works.
-- Enoch Norton
I heard Access-Vista does not use MDW files or security, and Microsoft now
expects the security to be based on User Access Rights. If you want
security then they expect you to use SQL Server.
Is that a vicious rumour?? I know I might have some facts wrong, but I'm
sure security has changed in some way.
Dominic
news:1d7ca0b9-3646-4a18-a70d-e18bd72999e3@h11g2000prf.google groups.com...
> On Dec 10 2007, 10:33 am, Fester Bestertester
> wrote:
>> Keith Wilby wrote:
>> > Are you really the same poster as the one who posted security advice in
>> > the "Thinking about going multiuser with user security,..." thread?
>>
>> I deeply appreciate all the technical feedback actually answering my
>> question. Since it's now so obvious that I'm an incompetent fool who
>> shouldn't be anywhere near a computer, let's review.
>>
>> Let's say for the sake of discussion that I have a multi-user database
>> that's split between a back end (data only) and a front end
>> (application). The back end resides on a server and the front end is on
>> the user's machine.
>>
>> Let's further say for the sake of discussion that I've already added and
>> tested a set of modules triggered by an AutoExec macro that verifies
>> that the link from front to back is valid, and, if not, raises a File |
>> Open dialog that allows the user (or a sysadmin) to point the front end
>> to the correct path if necessary.
>>
>> Now let's suppose that I want security which is specific to that
>> application only, and does not affect any other instances of Access on
>> the local machine, even though, in that same thread, "Thinking about
>> going multiuser with user security..." one "Lyle Fairfield" posted,
>> "Many developers do almost none of the above, with the exception of
>> splitting their applications. I am one of them."
>>
>> To accomplish this, I would perform the following steps:
>>
>> 1. Open an empty session of Access.
>>
>> 2. Select Tools | Security | Workgroup Administrator...
>>
>> 3. Select Create...
>>
>> 4. Give the new security file an ID, note the User, Organization, and ID
>> information, and click OK.
>>
>> 5. Browse to the appropriate location where I wish to store the mdw file
>> and name the file, i.e., MyApp.mdw.
>>
>> 6. Select Tools | Security | Workgroup Administrator, select Join, and
>> navigate to the new mdw file.
>>
>> 7. Select Tools | Security | User and Group Accounts, and create the
>> users and groups I wish to have.
>>
>> 8. Select Tools | Security | User and Group Permissions, and configure
>> the permissions for the groups.
>>
>> 9. Select Tools | Security | Workgroup Administrator, select Join, and
>> re-join the default System.mdw file.
>>
>> 10. For distribution, copy the backend database file to a shared
>> directory, copy the front end application file to the user's machine,
>> and copy the security file to a shared directory.
>>
>> 11. At this point, according to MSKB article 305542, "Understanding the
>> role of workgroup information files in Access security":
>>
>> "To associate specific secured database files with their workgroup
>> information files, you must create desktop shortcuts. Each desktop
>> shortcut must have the Command-Line option set to start a specific
>> database and use the specific workgroup information file secured with
>> that database.
>>
>> "To start a secured Access database named MyApp.mdb in a folder named
>> MyAppFolder with the workgroup information file used when establishing
>> security on MyApp.mdb, the command-line syntax must include the /WrkGrp
>> command-line switch, for example:
>>
>> "C:\Program Files\Microsoft Office\Office\MSAccess.Exe"
>> "C:\MyAppFolder\MyApp.MDB" /wrkgrp "C:\MyAppFolder\System.MDW"
>>
>> "You can create a shortcut and enter this syntax as the target of the
>> shortcut."
>>
>> 12. The result is that there is now security which is specific to this
>> particular application and does not affect other sessions of Access on
>> the user's machine.
>>
>> The user can still run Access, with the default System.mdw, file to open
>> or create mdb files, but if the user double clicks the desktop shortcut
>> to the "MyApp.MDB" application, they will get a password prompt using
>> the security file that is specific to that application.
>>
>> Unfortunately, this security does not apply if the user opens an empty
>> session of Access, or opens Windows Explorer, and navigates directly to
>> the MyApp.mdb file. So it appears that the only way to defeat this would
>> be to turn off Windows Explorer and/or remove all Access-related icons
>> from the desktop except the shortcut to MyApp.mdb.
>>
>> Or, is there something unrelated to desktop lockdown, and specific to
>> Access security, that I'm missing? It's already been effectively pointed
>> out that I'm incompetent, so what, exactly, was so obvious about Access
>> security that anyone should have been able to see it?
>
> I had the same problem securing my database. The work-around that I
> used to prevent unauthorized access to the original database was to
> remove permissions for the admin user, the default user for any access
> database, in the database I secured and linked the private
> Security.MDW to.
> I then inserted a little chunk of code that executes on startup that
> checks the username. If the username is "admin", the code displays a
> message telling the user that they must open the database using the
> designated shortcut. The code then closes the database.
> This method has worked for me. It's not pretty but it works.
>
> -- Enoch Norton
Dominic Vella wrote:
> I heard Access-Vista does not use MDW files or security, and
> Microsoft now expects the security to be based on User Access Rights.
> If you want security then they expect you to use SQL Server.
>
> Is that a vicious rumour?? I know I might have some facts wrong,
> but I'm sure security has changed in some way.
Access 2007 utilizes user level security if you stay with the MDB file format.
If you use the new Accdb file format then it does not. None of which has
anything to do with Vista.
ULS security was never very secure anyway so (IMO) it's no big loss.
--
Rick Brandt, Microsoft Access MVP
Email (as appropriate) to...
RBrandt at Hunter dot com
Rick Brandt wrote:
> Dominic Vella wrote:
>> I heard Access-Vista does not use MDW files or security, and
>> Microsoft now expects the security to be based on User Access Rights.
>> If you want security then they expect you to use SQL Server.
>>
>> Is that a vicious rumour?? I know I might have some facts wrong,
>> but I'm sure security has changed in some way.
>
> Access 2007 utilizes user level security if you stay with the MDB file format.
> If you use the new Accdb file format then it does not. None of which has
> anything to do with Vista.
>
> ULS security was never very secure anyway so (IMO) it's no big loss.
>
One should never invoke ULS only GLS. Give groups the permissions you
want them to have, then assign users to your groups.