Secured Shortcut & Citrix

[Guest]

I have a secured shortcut on my laptop (desktop), but while in VPN mode and
using Citrix, you can't just double click the shortcut. You have to go to
the Citrix neighborhood, Microsoft applications, and then to Access.
However, just opening the shortcut in this manner doesn't work. How can I
get this secured shortcut to work in the Citrix neighborhood. Thanks.

 

[Joan Wild]

The Citrix desktop needs to have a shortcut as well.

"path to Access on Citrix server" "path to mdb" /wrkgrp "path to mdw on
Citrix"

 

[karlroes]

Hi Joan,

I am having a slight issue with a new shortcut, using workgroup
security, in a Citrix environment.

The apps MDE opens OK and uses windows API calls to ask the user to
locate the BE database. When the BE is located and selected, the user
receives the following error:

Error 3033 You do not have the necessary permission to use the 'tblaa'
object. Have your system administrator or the person who created the
object establish the appropriate permission for you.

I figure that this cannot be an issue with the shortcut paths and
location of the MDW files as the FE opens OK to prompt for the BE.

As development was completed in a folder under C on my laptop, I ran a
test whereby I moved the BE from the folder under C to the desktop and
received the same 3033 error. On moving the BE back to the original
folder under C - all works OK.

There must be something quite simple that I am missing here. Can you or
anyone else assist please?

K.

 

[Joan Wild]

Hi Joan,

I am having a slight issue with a new shortcut, using workgroup
security, in a Citrix environment.

The apps MDE opens OK and uses windows API calls to ask the user to
locate the BE database. When the BE is located and selected, the user
receives the following error:

Error 3033 You do not have the necessary permission to use the 'tblaa'
object. Have your system administrator or the person who created the
object establish the appropriate permission for you.

What method are you using to refresh/relink to the backend. The security
FAQ outlines the permissions necessary depending on the method you choose.

It may be that all you need to do is grant full permissions on the frontend
links, and they'll be able to relink. Note that even though they have full
permissions on the links, they'll still be restricted by the permissions
they have on the backend tables.

Security FAQ http://support.microsoft.com/?id=207793

 

[karlroes]

Hi Joan,

Thanks. I'm using the Refreshlink method.

Why does this work when the back end is in the same folder as the MDE
and not work when I move the back end elsewhere?

Looking through the FAQ now.

K

 

[karlroes]

Hi Joan,

If I read the FAQ correctly, if I slip the following function into the
startup code before the refreshlink, then all should be OK.

Function faq_SetPermissions (strTable As String, strSourceDB As String,
strUsrName As String)
' This function will set permissions on the source table so that
' you can use the RefreshLink method to reattach tables. It grants
' Read Data permissions on the source table, Open/Run permissions
' on the source database and full permissions in the destination
' database on all tables and queries. You need to be a member of the
' Admins group to run this code.
'
' Parameters:
' strTable
' Name of the table for permissions to be set. Assumes the
' table named the same in both source and destination db.
' strSourceDB
' Fully-qualified name of the source database
' strUsrName
' Name of group or user you want to be able to
' use RefreshLink
'
Dim db As Database
Dim con As Container
Dim doc As Document
Dim ws As WorkSpace
Set ws = dbengine.workspaces(0)

' set default full permissions in destination
' (current) database for new tables
Set db = CurrentDB()
Set con = db.Containers("Tables")
con.username = strUsrName
con.permissions = DB_SEC_FULLACCESS

' set full permissions for the linked table
' in the destination database
Set doc = con.Documents(strTable)
doc.username = strUsrName
doc.permissions = DB_SEC_FULLACCESS

' Set open database permissions for the source database
Set db = ws.OpenDatabase(strSourceDB)
Set con = db.Containers("Databases")
Set doc = con.Documents("MSysdb")
doc.username = "Users"
doc.permissions = doc.permissions Or DB_SEC_DBOPEN

' Set read data permissions for the base table
Set con = db.Containers("Tables")
Set doc = con.Documents(strTable)
doc.username = strUsrName
doc.permissions = doc.permissions Or DB_SEC_RETRIEVEDATA
End Function

Is that a correct assumption?

K

 

[Joan Wild]

Yes that should work.

 

[karlroes]

Thanks Joan,

I tried the above code with little success.

Apparently, linked tables need a minimum of Modify Design permissions
in the frontend for the RefreshLinks method. So I set the table
properties in the FE to Modify Design and all worked fine on a local
dev machine.

On install in the TS/Citrix environ, a " You do not have exclusive
access to the database at this time" message appears. Install personell
can OK through the error 32 times ( the number of tables ) to get the
app to run.

Please, why does this occur and how can I prevent it as there will be a
total of 5 users with their own copy of the FE?

Regards

K

 

[Joan Wild]

I haven't had a problem doing this (even in a TS environment).

I didn't bother with any code to change the permissions. Just give full
permissions on the frontend links (that doesn't affect the permissions they
really have, as that is dictated by the permissions on the backend tables).

 

[karlroes]

HI Joan,

I just had a chance to try this and it worked a treat - thank you.

In my excitement at possibly repairing the problem, I've inadvertently
caused another bigger problem for myself as follows.

The first thing that happens in code behind a hidden startup form is to
call a startup function to change properties for the application.
Well, I always have this call commented out for testing and in my
haste, for one reason or another I uncommented it, tested the mdb and
now I can't use my external testproperties.mdb to change the properties
back because it is now a secured mdb made using the secured non-default
..mdw!!!

I have tried the following:
DBEngine.SystemDB = "C:\PathtoSecured.mdw"
Set wksSecure = DBEngine.CreateWorkspace("", "UserName", "Password"")
Set db = wksSecure.OpenDatabase( "C:\Pathtosecured.mdb")

and I consistantly get Error 3029 - not a valid account name or
password when both are correct.

In a nutshell, please, what is the procedure for externally changing
the startup properties of a secured mdb to enable the shift bypass key
using the developer username/password?

Regards

K

 

[Joan Wild]

Create a desktop shortcut like...
"path to msaccess.exe" /wrkgrp "path to secure mdw"

Once Access opens, open the testproperties.mdb; provide a username/password
that's a member of the Admins Group in secure.mdw.

Now run the function in the immediate window.