Using .Connect to relink fails! Really need help with this!

[kiln]

I'm stymied by an apparent permissions issue. I'm using the code in the
SecFaq, item 14.3, with a secured Access 2000 sp3 db.

Backend has all table perms revoked for all but admin users. Queries are
used by reg users at the front end to gain access to data (via forms,
rwop, etc). Well there is one table that all users have full persm to.

The front end grants all users all perms on all tables.

The code in 14.3 is supposed to delete each linked table and then relink
to it using the values passed in. As soon as I'm running as a ordinary
user (not User, rather a member of one of the custom groups that have
limited perms) each line of the .connect relink routine errors out -
Error 3012 (Object '|' already exists) for the single table that all
users have full rights to and Error 3110 (Could not read definitions; no
read definitions permission for table or query '|') for all the rest.

The first error must indicate that the one all perms ok table link
wasn't deleted like the routine is supposed to do.

The second error I'm not sure what the issue is. Using .connect is
supposed to obviate the perms issue but here it is

I've spent lot of time on this and have to solve is soon, so I hope
someone can point me to the problem. I'm sure the technique works but I
must be misapplying it.

 

[TC]

I suggest you show your actual lines of code. Lots can happen between the
code as written in a document (eg. the secfaq), & as implemented by specific
programmers!

When you say the front end grants all users all permissions on all "tables",
I assume you mean on all *links*? If so, then, I can't see why a user
wouldn't be able to delete those links, regardless of what permissions he
had (or did not have) on the linked-to tables.

HTH,
TC

 

[kiln]

I'd made a mistake; the secfaq listing for 14 (faq_SetPermissions())
where perms are managed has a strUserName variable that should be the
name of user or group that needs to do the relinking. I'd first set it
to the siteadmin user (this is a dual mdw setup)

So, some improvment but a new problem. All of the queries have been set
to rwop as mentioned. The owner is an admins group member. But, all
queries in the front end are read only. I've never seen this before.

 

[TC]

If an RWOP query is non-updatable, this would mean that:

- the query is inherently non-updatable (eg. a UNION query), or

- the owner of the query does not have Edit Data permission (or whatever
it's called) to the tables referenced by the query.

If the query references other queries, you'd have to trace the chain of
referenced queries to check the points above.

HTH,
TC
(off for the day)

 

[TC]

Further to this, you should check the query owner to make certain that it is
who you think it is!

? dbengine(0)(0).querydefs![BLAH].owner
or somesuch.

HTH,
TC
(really off for the day!)

 

[kiln]

Well, another alternate is that something just got whacky in Jet or the
files. I did check all of that so many times. Finally imported the data
file tables into a new mdb and redid the perms on it as before. It works
fine now, but can't explain it. I redid the perms on the data file and
the front end file 10x each so I know I did it all the same on the new
data file.

Further to this, you should check the query owner to make certain that it is
who you think it is!

? dbengine(0)(0).querydefs![BLAH].owner
or somesuch.

HTH,
TC
(really off for the day!)

If an RWOP query is non-updatable, this would mean that:

- the query is inherently non-updatable (eg. a UNION query), or

- the owner of the query does not have Edit Data permission (or whatever
it's called) to the tables referenced by the query.

If the query references other queries, you'd have to trace the chain of
referenced queries to check the points above.

HTH,
TC
(off for the day)

 

[TC]

Hi kiln

If you imported the tables into a new database, that could well have changed
their ownership. So even though you did the other steps the same as before,
you could easily get different results.

At least it's working now

TC

Well, another alternate is that something just got whacky in Jet or the
files. I did check all of that so many times. Finally imported the data
file tables into a new mdb and redid the perms on it as before. It works
fine now, but can't explain it. I redid the perms on the data file and
the front end file 10x each so I know I did it all the same on the new
data file.

Further to this, you should check the query owner to make certain that it is
who you think it is!

? dbengine(0)(0).querydefs![BLAH].owner
or somesuch.

HTH,
TC
(really off for the day!)

If an RWOP query is non-updatable, this would mean that:

- the query is inherently non-updatable (eg. a UNION query), or

- the owner of the query does not have Edit Data permission (or whatever
it's called) to the tables referenced by the query.

If the query references other queries, you'd have to trace the chain of
referenced queries to check the points above.

HTH,
TC
(off for the day)


I'd made a mistake; the secfaq listing for 14 (faq_SetPermissions())
where perms are managed has a strUserName variable that should be the
name of user or group that needs to do the relinking. I'd first set it
to the siteadmin user (this is a dual mdw setup)

So, some improvment but a new problem. All of the queries have been set
to rwop as mentioned. The owner is an admins group member. But, all
queries in the front end are read only. I've never seen this before.

I suggest you show your actual lines of code. Lots can happen between
the
code as written in a document (eg. the secfaq), & as implemented by
specific
programmers!

When you say the front end grants all users all permissions on all
"tables",
I assume you mean on all *links*? If so, then, I can't see why a user
wouldn't be able to delete those links, regardless of what

permissions