michele Posted November 30, 2001 Posted November 30, 2001 This is the message I often get in the network application: "This record is currently being modified by "name". The record isn't being modified by another user and according to what I found in the forum it has something to do with portals. What is exactly happening? How do you solve this problem? The answer (=1) I found in the forum isn't quiet clear to me. Thankyou for reading and eventually answering my question.
mattlight Posted December 4, 2001 Posted December 4, 2001 check to see what the relationship is based upon for your portal. Is it a portal displaying information within the current database. (A Portal to itself) If so, you might be displaying your current record within the portal and so when trying to edit it, it might be telling you that you can't edit it because you are already in that record - any record that is open already cannot be edited. Example, if someone else was using that record on a multi user network - you can cause the program to believe it is being edited by someone else by you yourself viewing it twice on the same screen. Is this explainatory enough? Good luck
michele Posted December 5, 2001 Author Posted December 5, 2001 I will check that, it sounds like a logical explanation. Thanks for your help. [ December 05, 2001: Message edited by: michele ]
Steven H. Blackwell Posted December 5, 2001 Posted December 5, 2001 If user #1 is scrolling a portal it will lock the first related record under a variety of circumstances. This can also lock the parent record. This may be what is happening here. Old Advance Man
mikerobertson Posted December 7, 2001 Posted December 7, 2001 michele, i think maybe your problem is because filemaker locks user "b" out of the portal row "x" when user "a" has portal row "x" selected already to keep her portal from scrolling to the top of the list. if you have scripts that search through your portal line by line, they will always fail if anyone is holding their portal from returning to the top by having it selected. the solution then is to not let anyone select a portal row. if they don't have to modify any data in the portal row, this is pretty easy to fix...but if they do, its a little trickier. i have a way to do it, but its really involved, so i won't post an explaination unless you you think it sounds like this is your problem. hope that helps!
Steven H. Blackwell Posted December 8, 2001 Posted December 8, 2001 Of course if users can not edit records in a portal, they can't lock them and that may solve the problem. Old Advance Man
Matt Klein Posted December 8, 2001 Posted December 8, 2001 quote: Originally posted by michele: This is the message I often get in the network application: "This record is currently being modified by "name". The record isn't being modified by another user and according to what I found in the forum it has something to do with portals. What I have found is that if user #1 is scrolling in the portal and user #2 tries to access any of the records in the portal, you will receive the record in use error unless user#2 is sitting on a different record. For example: I had a solution with a Main Menu. Originally I used a single file with a single layout and a single record to do the Main Menu which consisted of buttons and a portal to a certain subset of records in a seperate database. Regardless of the number of users, there was only one record in this database. If someone was currently scrolling in the portal, no one else could use the portal without getting the record in use error. The solution is to create a record for each user in the Main Menu database. I did this by creating a record when the Main Menu database is opened and I set a global field(Global_RecordID) to the RecordID of the newly created record. Then I defined a calculation field(RecordID) as Status(CurrentRecordID). Then I defined an internal relationship(User_Record) with the Global_RecordID on the left and RecordID on the right side of the relationship. Then I defined a script that gets run anytime a user returns to the Main Menu that is pretty much one step: Go to Related Record[user_Record]. That's it. It works really well and it's a pretty easy setup. I also run a script on close of the Main Menu database that has the following steps: Go to Related Record[show, User_Record] Delete Record/Request This is just to keep the record count in the database to a minimum. Hope that helps
michele Posted December 8, 2001 Author Posted December 8, 2001 Thankyou Old Advance man, Matt x2 and Mike I will check every solution you offered me. It might take me some time to figure out what exactly is going on as the error message never seems to occur when I'm around. I did get another kind of message concerning tcp/ip, it said something like the data access companion couldn't access a file because of + some number. I know my customer has plenty of licenses so I thought this couldn't happen (or maybe that has nothing to do with tcp/ip). Anyway tcp/ip is a riddle to me.
Anatoli Posted December 8, 2001 Posted December 8, 2001 RE: data access companion ... -------------------------------- Do you use sharing over that plugin? If not disable it!
michele Posted December 9, 2001 Author Posted December 9, 2001 Dear Anatoli, What plugin are you talking about?
Recommended Posts
This topic is 8387 days old. Please don't post here. Open a new topic instead.
Create an account or sign in to comment
You need to be a member in order to leave a comment
Create an account
Sign up for a new account in our community. It's easy!
Register a new accountSign in
Already have an account? Sign in here.
Sign In Now