Run time error 3033

[Knicks]

I have just gone through the long process of setting up a security file for an Access database. I need to do this because our office will be using sensitive data on laptops. I know it is not full proof but we need to cover our rear.

The problem I am having is that when using the Opendatabase method in dao I am getting a run time error 3033, permissions on the table that I am trying to open. It is basically just a linked table that uses the same workgroup security file as the front end. I have full rights to the database object and tables. The error seems to be at the db object level.

The strange thing is that if I hit 'refresh' after the error - the code is calling the opendatabase method at the last stage of my form's BEFORE UPDATE event. The refresh will clear it and allow the procedure to run. I can always access the linked tables.

Why would this just occur on the 1st call to the database and table? Then clear??


Here is a snippet of the code:
As you can see I've tried a couple of different methods to opening this table, from the simple CurrentDB to the more compelx dbengine and referencing the linked database and table.

Any suggestions would be helpful. I'm wondering if the security file may be corrupt only because it works on the 2nd attempt.

Dim dbs As DAO.Database, nextrec As Recordset, strSelect, NextNbr As String, dataname As String
Dim alreadyexists As Variant, NextInteger As Long
Dim ws As Workspace

DBEngine.SystemDB = "C:\dental sealant\DENTAL2.mdw"
DBEngine.DefaultUser = "dentaladmin"
DBEngine.DefaultPassword = "molar"


Set ws = DBEngine.Workspaces(0)


'Set dbs = CurrentDb
Set dbs = ws.OpenDatabase("C:\dental sealant\sealant_beLAP.mdb")



Set nextrec = dbs.OpenRecordset("tblClientSource", dbOpenDynaset, dbSeeChanges)

 

[lameid]

So is tblClientSource in a separate file than the running code? If not, opening a recordset off the currentdb should have the same credentials.

If it is different try...

Set WS = Currentdb().Parent
Set dbs = ws.OpenDatabase("C:\dental sealant\sealant_beLAP.mdb")


Set nextrec = dbs.OpenRecordset("tblClientSource", dbOpenDynaset, dbSeeChanges)

Without doing the research, I think that will preserve the same user context.

 

[Knicks]

I will try that.

The tblClientSource is linked to a back-end database. But I tried just importing it in and seeing if that was the issue and I got the same error 3033 - the object it claims I don't have permissions for is the current db or the one I am in at the time (the front end).

 

[lameid]

In the immediate window try

? currentuser()

That will validate you are who you think you are.

 

[Knicks]

Thanks.

Yes I am who I expected to be. The strange part in this permission problem is that it is not a hard stop. I get the permission error but once I clear it I can then work just fine. The error pretty much starts when you attempt to open the current db (the one you are in), it saids you don't have permissions to the FILE. I go into security and I have admin over everything, database, tables, ect.. I'm sure if I didn't, then it would be a hard stop.

I have looked at some other databases with security files and I did not notice any necessary tricks to using the DAO.Database OpenDatabase method. I ended up putting both the front end and the back end databases on the security file...the backend of course is linked to the front end. Could the error have to do with both files being attached to the security file...maybe I shouldn't link the table I am trying to open (I did bring it in as a local just to test and no luck).


I tried to capture the error and perform a resume and loop through again but there is no work around that way. I have to generate the error once - and then I can continue. I tried using some sendkeys to close the error msgbox but no luck. Because once the error is generated once, it doesn't cause anymore problems.

 

[Knicks]

Oddly,

I can open the secured back-end no problem using the dao opendatabase method. The tables are all linked anyway so I guess I have no reason to open currentdb.

That solves my problem but not the mystery....
Thanx for your help

 

[lameid]

I wonder if you make the server a trusted site if the problem would go away... Check out
thread181-1545476

The trusted site solution is pretty far down the list but you may find something else there illuminating too.