[AccessD] Error 70 - Permission Denied

*** in line

R 

-----Original Message-----
From: accessd-bounces at databaseadvisors.com
[mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Stuart McLachlan
Sent: Sunday, March 24, 2013 10:56 AM
To: Access Developers discussion and problem solving
Subject: Re: [AccessD] Error 70 - Permission Denied

Permission denied can mean all sorts of things, from user rights to
attempted concurrent access to locked files.

Is thins installation using the same FE directory as the others, if so - are
they on the same OS version (MS got stricter about users creating/modifying
files in locations such as Program Files)/
*** Will check but I believe the answer is Yes.  They use my install script
and is unlikely that they changed the install directory.

What sort of operations trigger it?   (You may need to put create a debug
version with 
additional  code to tell you exactly where the error is occuring) 
*** Haven't found a pattern.

Can you tell/find out whether it is on read or write operations?
*** Not positive but appears to be writes.  But I'll check closer tomorrow.

Are you creating/using extraneous disk files at all?
*** No.

Are you creating temporary tables or otherwise modifying the FE during any
operations?
*** No mods.  I use temp tables for reports but don't re-create - just
delete all records before generating the report.

--
Stuart


On 24 Mar 2013 at 10:17, Rocky Smolin wrote:

> Dear List:
>  
> I have a user using an app compiled in A2K3, using run-time from
> Wise/Sagekey.  Back end is on the server, front end with run-time is
> installed on each client.
>  
> All clients have been running fine.  One does not - many operations in the
> app generate an error 70 - Permission denied.  The error is trapped by my
> error trapping and a message box is displayed with options to email or fax
> the error to me.  Then the app closes and must be restarted.  
>  
> An oversight - I left the control box on the message so the user has just
> been minimizing the error box and carrying on (gotta fix that toot sweet).
> The user finds that the transactions she was doing when the error is
raised
> are all complete and correct.  
>  
> They can't tell me exactly how long this has been going on or what might
> have changed right before this problem started.  
>  
> I had them copy the back end to the client and relink the tables locally
to
> see if it was a problem on the server.  Still had the problem.  
>  
> Then I had them relink the tables to a local demo database to see if the
> problem was in their back end.  Same problem.
>  
> All clients are running the same version of the app.
>  
> So I think I've eliminated the back end, the front end, and the server as
> problems.  It would perhaps seem to be a question of the user account.
But
> I really don't know where to look.
>  
> Any guidance on what might be causing the problem and where to begin
> looking?
>  
> MTIA
>  
> Rocky Smolin
> Beach Access Software
> 858-259-4334
> www.bchacc.com <http://www.bchacc.com/> 
> www.e-z-mrp.com <http://www.e-z-mrp.com/> 
> Skype: rocky.smolin
>  
>  
>  
> -- 
> AccessD mailing list
> AccessD at databaseadvisors.com
> http://databaseadvisors.com/mailman/listinfo/accessd
> Website: http://www.databaseadvisors.com
> 


-- 
AccessD mailing list
AccessD at databaseadvisors.com
http://databaseadvisors.com/mailman/listinfo/accessd
Website: http://www.databaseadvisors.com