Smart questions
Smart answers
Smart people
INTELLIGENT WORK FORUMS
FOR COMPUTER PROFESSIONALS

Member Login




Remember Me
Forgot Password?
Join Us!

Come Join Us!

Are you a
Computer / IT professional?
Join Tek-Tips now!
  • Talk With Other Members
  • Be Notified Of Responses
    To Your Posts
  • Keyword Search
  • One-Click Access To Your
    Favorite Forums
  • Automated Signatures
    On Your Posts
  • Best Of All, It's Free!

Join Tek-Tips
*Tek-Tips's functionality depends on members receiving e-mail. By joining you are opting in to receive e-mail.

Donate Today!

Do you enjoy these
technical forums?
Donate Today! Click Here

Posting Guidelines

Promoting, selling, recruiting, coursework and thesis posting is forbidden.
Jobs from Indeed

Link To This Forum!

Partner Button
Add Stickiness To Your Site By Linking To This Professionally Managed Technical Forum.
Just copy and paste the
code below into your site.

ejhemler (Programmer) (OP)
15 Nov 04 14:53
I have created some software where multiple users need to access the data at the same time and make changes to the same table.  I have all the files open shared so that multiple people can use see the data at the same time, but if someone tries to write to the file by modifying a record or adding a new record the the file, the error File is in Use by Another User will come up every once in a while.  It does not happen always.  But I thought that if the files were open shared, that this was not supposed to happen.  

I am using VFP 6.0 and the data and software is on a windows 2000 server environment.  It seems like this happens when there are a lot of people on it and making changes at the same time.  Am I missing something here?  Please help.

Thanks,
Erik
audiopro (Programmer)
15 Nov 04 14:59
Could it be that two users are accessing the same record at the same time. Two users will be able to read the same record but the second user to access it will be prevented from writing to it as it will be locked by the first user.

Hope that makes sense.

Keith
www.studiosoft.co.uk

ejhemler (Programmer) (OP)
15 Nov 04 14:59
And if it's not that error, it will be File Access is Denied.  
ejhemler (Programmer) (OP)
15 Nov 04 15:01
Yes, I thought about that, but wouldn't that give the error Record is in use by Another User?
ejhemler (Programmer) (OP)
15 Nov 04 15:19
Plus it wouldn't make sense that people are in the same records because all the users are limited to accessing only the records they are responsible for and should not be in the records they are not responsible for.  I hope this is making sense.  If not let me know and I will try to explain better.

Erik
MikeLewis (Programmer)
15 Nov 04 15:21
Erik,

Is it possible that one user is trying to write to the file while another is trying to append a new record to the same file? The append operation locks the file's header, which might give rise to the error you mentioned.

Mike

Mike Lewis
Edinburgh, Scotland

My Visual Foxpro web site:   www.ml-consult.demon.co.uk
My Crystal Reports web site:   www.ml-crystal.com

audiopro (Programmer)
15 Nov 04 15:21
Some VFP commands lock a record and some lock the whole table Have you been able to track down where the actual 'clash' is?
You can be sure the app will run without a glitch if you are stood next to it.

Keith
www.studiosoft.co.uk

ejhemler (Programmer) (OP)
15 Nov 04 15:31
Wow, I didn't realize the append command would lock the file's header.  Is there a way to do it so that append does not lock the header file?  If not, maybe I will have to look into using the INSERT command, but that will be a pain to rewrite.  Oh well.
audiopro (Programmer)
15 Nov 04 15:38
Maybe one of the gurus can explain the correct use of RETRY. I have never had to use it and am always wary that this type of command can lock up the app. in some circumstances.

Keith
www.studiosoft.co.uk

ejhemler (Programmer) (OP)
15 Nov 04 15:42
I've actually set up an event handler that will let the user execute a "Retry" command on there own so that if they get this message, they can hit Retry until it goes through.  But I want this to only be temporary until I figure this out.

Erik
ramani (Programmer)
15 Nov 04 16:07
Hi Erik

The problem could be the way you are making additions to records.

If the table has PRIMARY index and you use APPEND BLANK command, this can create a conflict when more than one person simultaneously try to add a record. Because, two blank records cannot exist with a primary index. The resolution for this is use the command.. INSERT with a key value for primary key field. This will not create a conflict.

Another is the buffer method or locking method you use. Read on SET MULTILOCKS and SET REPROCESS commands.

I am sure you can fix that.

____________________________________________
ramani - (Subramanian.G)
http://winnersoft.coolfreepages.com/

ejhemler (Programmer) (OP)
15 Nov 04 16:15
I think I will just clean up the code with replacing the append blank command's with INSERT command's.  I never liked that command in the first place and could never understand why they wrote it like that.  Well, thanks for helping me get to the bottom of this everyone.
MikeLewis (Programmer)
16 Nov 04 3:15
Erik,

In general terms, the usual approach to locking problems is to use buffering. You could choose to adopt buffering with pessimistic locking, in which case locking conflicts shouldn't cause a problem. Read up on buffering in the Help.

Having set the buffering, you could SET REPROCESS to, say, two seconds.That way, if two people hit the table at almost exactly the same time, VFP will simply wait until the first one finishes before letting the second one proceed.

You should also write an error handler that traps for errors 108 and 109. These errors will arise if, despite the delay initiated by SET REPROCESS, one user tries to edit the record or table while another user has it locked. Your error routine should advise the second user of the situation, and suggest that they try again later (obviously your user interface will have to handle this).

The other approach is to use buffering with optimistic locking. That means that you will never lock anyone out just because someone else is editing the record, and you should never get errors 108 or 109. But you run the risk of the second user overwriting the first user's edits, so your code will have to test for this and take some appropriate action.

All this is explained in the Help, under the heading "programming for multi-user access" (or something similar).

Mike

Mike Lewis
Edinburgh, Scotland

My Visual Foxpro web site:   www.ml-consult.demon.co.uk
My Crystal Reports web site:   www.ml-crystal.com

Reply To This Thread

Posting in the Tek-Tips forums is a member-only feature.

Click Here to join Tek-Tips and talk with other members!

Close Box

Join Tek-Tips® Today!

Join your peers on the Internet's largest technical computer professional community.
It's easy to join and it's free.

Here's Why Members Love Tek-Tips Forums:

Register now while it's still free!

Already a member? Close this window and log in.

Join Us             Close