Automation & Workgroup Security

[Mike Jackson]

Trying to run a 2nd instance of Access while workgroup security is enabled.
Works fine for the initial logon to the database using command line args.
The generic user logon has no password and I'm only using security to
prevent anyone from messing around with parts they shouldn't.

When I need to start another instance of Access from within Access is when I
get the problem. I can't find a way to bypass the Access logon to keep this
process as transparent as possible.

Any suggestions?

Post here or mail to hit...@csi.com.

Thanks in advance

[Valera]

Hi Mike!

You can use /user and /pwd command line option.

--
Valera
val...@mbh.ru
Mike Jackson wrote in message ...

[Mike Jackson]

That works fine for starting an initial instance, but doesn't work with
CreateObject or GetObject, unless I'm missing something.

Valera wrote in message <#ZnNwUyq...@uppssnewspub05.moswest.msn.net>...

[mary chipman]

no, you're not missing anything -- it's tricky when you use
automation. the following is some sample code i demo'd at the Advisor
DevCon -- it's VB5, but it works the same in access:

Dim lngReturn As Long
Dim objAccess As Access.Application

lngReturn = Shell("C:\Program Files\Microsoft
Office\Office\MSACCESS.EXE " _
& "/wrkgrp c:\sectalk\secsys.mdw /User moi /Pwd mypwd
/Nostartup")
DoEvents
Set objAccess = GetObject(, "Access.Application")
objAccess.OpenCurrentDatabase "c:\sectalk\secapp.mdb", False
objAccess.DoCmd.OpenReport "rptTopTenCustomers", acViewPreview
Set objAccess = Nothing

On Thu, 9 Jul 1998 08:30:08 -0700, "Mike Jackson" <hit...@csi.com>
wrote:

[Mike Jackson]

Thanks - wouldn't this (Shell) start a DOS box that won't close automatically unless you make it like:

 

lngReturn = Shell("command.com /c C:\Program Files\Microsoft

>Office\Office\MSACCESS.EXE " _
>     & "/wrkgrp c:\sectalk\secsys.mdw /User moi /Pwd mypwd
>/Nostartup")

 

I've found another possible way around (assuming, I think, that none of the clients are already using the full version of Access and a secure workgroup setup).  I've built a security file with the app which I don't show by using command line switches in the shortcut.  This makes it easy for the generic user to get in, where they can only do/see what I want.  At the same time, since I've not had them join my workgroup, I can fall back on the vanilla system.mdw to start a non-password required instance of access.

 

The only hole I see in this approach is that if the user already has a secure system.mdw on the machine, I'll be back where I started.

 

I'm also exploring some options with the Windows Scripting Host - I think there might be some possibilities there.

 

 

 

mary chipman wrote in message <35a62e2...@207.68.144.15>...

[Valera]

Hi Mike

I think you are right here. Do you realy need to open new instance of
access, may be working with workspace will be enought for you. Check
workspace in help.

--
Valera
val...@mbh.ru
Mike Jackson wrote in message ...

[Valera]

[mary chipman]

Shell() is how you run other apps from inside VBA. it won't call a DOS
box unless you use command.com.

On Thu, 9 Jul 1998 21:17:12 -0700, "Mike Jackson" <hit...@csi.com>

[Mike Jackson]

Sorry, got stupid there. On a somewhat related topic (security).....

If I start an instance of access from within Access (started via command
line options joined to a secure workgroup), export an object to this 2nd
instance (a form), are there any useable permissions attached to that form
in the second instance?

I'm trying to put a form with a timer event in the 2nd instance, then close
the first instance before the timer expires in the 2nd. Once the timer
expires in the 2nd (now only) instance of access, the original .mdb is
compacted, after which I restart the main app.

I know all this works fine in a non-secure environment, but I'm not sure if
the current user's permissions will be in effect in the second instance.

I have a feeling I'm going to have to manipulate the workgroup and user for
the second instance before this works???

Thanks..

mary chipman wrote in message <35a7d8df...@207.68.144.15>...

>Shell() is how you run other apps from inside VBA. it won't call a DOS
>box unless you use command.com.
>

>On Thu, 9 Jul 1998 21:17:12 -0700, "Mike Jackson" <hit...@csi.com>
>wrote:
>

[mary chipman]

compacting requires the open exclusive permission on the database
container. as far as the rest of your scenario, i guess you just have
to build it and test it and see if it works or not.

On Mon, 13 Jul 1998 19:08:01 -0700, "Mike Jackson" <hit...@csi.com>
wrote:

>Sorry, got stupid there. On a somewhat related topic (security).....

>
>If I start an instance of access from within Access (started via command
>line options joined to a secure workgroup), export an object to this 2nd
>instance (a form), are there any useable permissions attached to that form
>in the second instance?
>
>I'm trying to put a form with a timer event in the 2nd instance, then close
>the first instance before the timer expires in the 2nd. Once the timer
>expires in the 2nd (now only) instance of access, the original .mdb is
>compacted, after which I restart the main app.
>
>I know all this works fine in a non-secure environment, but I'm not sure if
>the current user's permissions will be in effect in the second instance.
>
>I have a feeling I'm going to have to manipulate the workgroup and user for
>the second instance before this works???
>
>Thanks..
>
>mary chipman wrote in message <35a7d8df...@207.68.144.15>...
>>Shell() is how you run other apps from inside VBA. it won't call a DOS
>>box unless you use command.com.
>>

>>On Thu, 9 Jul 1998 21:17:12 -0700, "Mike Jackson" <hit...@csi.com>
>>wrote:
>>