I think I've really designed a bad database structure! I've been asked to create a database to store confidential information on students. The district already had a student management database which is structured so the data is stored in an admindata file and the user interface is accessed through a separate file.

Following this structure, and not wanting to be responsible for making modifications another developers databases, I created a new file called Student_Info. This file contains one table and all of the fields are globals. There is only one record in the file.

On the opening layout, the user sees a portal related to the admindata file which displays all of the students from the student table (constant set to 1 both databases). Clicking on a student sets a global userID field in my Student_Info database.

This global establishes a relationship in a second portal on the same layout. This portal displays a list of related records in a table I created in the admindata file called student_info.

Clicking on one of the student_info records sets a global called recordID. This establishes a relationship in a third portal on the layout which just displays the details for one record in the student_info table. The information in this portal can be edited by the user.

This all worked great until more than one user accessed the database. Only one person can be clicked in a field the 3rd portal (it doesn't matter which student's information is being displayed). The second user get "....is modifying this record".

Is this caused by having only one record in my database, even though all of the fields are portals? Is this caused by some weird portal locking? HELPPPPPPP!

One way of doing it is running a simple script to create a new record whenever a user navigated to that layout, and obviously, due to the speed these would build up, also deleting all the records aswell.

Or you could assign each user one individual record, i.e. they're accountname, do a find for that when they get to the layout, if it doesn't exist, create a new record, and store the accountname for future use.

So for example:

Set Error Capture[on]

Freeze Window

Go To Layout[YourLayoutWithLotsOfPortals]

Enter Find Mode[]

Set Field[AccountReserved ; Get(AccountName)]

Perfom Find[]

If[Get(LastError) = 401 //i.e. no records could be located to match the request]

Create New Record / Request

Set Field[AccountReserved ; Get(AccountName)]

End If

One little addition. After setting the AccountReserved field add the step Commit Records [no dialog]. You do not need to, or want to leave that record "open."

Similar applies to your script to set a global field to the StudentID. Commit Records. Makes relationships using globals more reliable.

I'm going with Genx on this - it's exactly what I did recently. Create a new record for each user on demand by whatever form of user recognition you have.