Self Join & Constant & Multiuser = Locked records

[vanderark1]

I have a DB where users only access one blank ("view") record, populated with a portal based on a constant that makes all other records (in the same DB) appear in the portal. This is the names of Special Projects we have open. They click on the record they want and are brought to that record. From there, they are linked to all the info for the Special Project, portals to stores involved, vendors involved, etc.

Works perfectly when it was me developing it. However, I just discovered that when anyone is scrolling the portal, the "view" record is locked, so no one else can scroll.

I then replaced the "view" record with 10 "view" records, and each user is sent to their specific view record, based on CurrentGroups (each user is also a unique group).

This is better, everyone can access their "view" record. However, only one person can scroll the portal at a time.

So the constant relationship is the problem that is locking the record? It is almost as if the portal is a identical record, regardless of the record it is sitting on. This is probably obvious to most of you, but really surprised me.

So, I need to let everyone scroll thru the list and pick the record they want. How do I accomplish this? Is it possible, or do I need to go to a new "View" DB, altoghether? Thanks in advance!!

[vanderark1]

I also tried creating a new DB - "Special_Projects_Viewer". I created a record for each user to access exclusively. Each record has a field that is entered with:"Open". And I created a portal matching each record to all the records in the original Special_Projects file that are also marked "Open".

Again, all the Special_Projects show up in the portal (if open) just like the should. But, even though I am in one reocrd in the Viewer and another user is in a different record in the viewer, only on of us can access the portal (scroll).

Do I need a compound key, based on users (CurrentGroups)? Do I need a new sign in (not part of FM password system) and base the relationship on that?

Sorry, but I am stumped!

[vanderark1]

Sorry for the 3rd post, but here is one more thing I tried:

I changed the key for both sides of the portal to be dynamic based on the CurrentGroups. Everything appears in the portals as they should. The problem still exists however. I thought changing the relationship to dynamic, would eliminate the problem, becuase the relation for user one is different than the relationship for user two (that is the data in the fields the relation is using).

Here is my temporary solution:

If I eliminate the scroll bar in the portal, the issue all but goes away. Each portal row is a button going to the related record. Without the scroll bar, the user goes immediately to the related record. The only time we have been able to generate a "modifying record" error, is if we hit the same portal row at the exact same moment. Which I can live with. However, not being aboe to scroll is a big, big issue as the Special_Projects DB grows.

[Ugo DI LUCA]

Building a Single File Interface may indeed lead to these issues...

You may try a single file with no records in it too, with each user having its own global, or one file where one record is created and then got deleted as soon as the user leave the session.

Other than that, a fixed portal technique would allow you to scroll even a "locked share" portals.

Finally, are the files served ?

[vanderark1]

Yes, the files are served. Do you have suggestions on example files that do what you suggest? I have quickly tried one record files, where each user has a record created and then delted when leaving, but I run inot the same problem scrolling. I have shut off users ability to edit the records, so now scrolling works. This is only a temp answer.

Finally, what do you mean by a "fixed portal technique"? Thanks for helping!!

[Ugo DI LUCA]

Well, I started re-building my new solutions with a SFI structure, but as I couldn't really test it in the whole development process, I got back to the standard tabbed interface.

But though, the solution which consist to make sure each user has its own record should work. At least, it did when I tested it . Now you could run with other mixed bugs in a shared environment.

About fixed portal, you may have a look to a demo I've made here in the Sample section (OSX Portal ScrollBars ) that appart from the look, explains the basics.

As voices announced that FM's current 64,000 character will be increased in version 7, this could be an opportunity.

Scripted though.

HTH

[Ugo DI LUCA]

vanderark1 said:

I have quickly tried one record files, where each user has a record created and then delted when leaving, but I run inot the same problem scrolling.

Ok, I went back to that set of files I had made, and checked the script that was launched and which worked.

Enter Browse Mode

#Create a new record

New Record Request

Exit Record/Request

Set Field [gUserKey, ID]

Go To Related Record [selfgUserKeyToID, Show Only]

Now, in such a solution, the Status Area should be locked and no Show All records allowed, so that the user really stays locked in this record only.

Now, I'm not pretty sure what you're referring to is really a Single File Interface as you're triggering GTRR script steps from the portal row, while in a Single User Interface you'd just grab the related ID into a global and view the data through related fields and portals.

Or is it my bad interpretation of what I've started and not finished (but surely will end up as soon as I can test it for real), that the portal belongs to the user in a SFI, as long as each user is in a different record and use his own set of globals..?

[vanderark1]

I thought I had a Single User Interface in a test I tried, but I am having trouble figuring out the correct relationships.

If I have users log in, grab their ID in a global, create a new record (and delete when they sign out, their global id becomes my left side relationship key. Whatdo I use on the right side? Do I need a field where I hard code in all the IDs, since I can't put a global as the relationship key on the right side? Or am I totally confused?

[Ugo DI LUCA]

The GTRR I use in the script is just a way to force the user to stay in his record in this new database, in this pretty new record. That's all. It's not related at all to any User ID.

[vanderark1]

I was right, I am getting totally confused. Rather than take up your time, I am going to leave it with the EDIT ability shut off. Meanwhile, I will research the Single User Interface concept more in depth.

Thanks for your help!