Jump to content
Claris Engage 2025 - March 25-26 Austin Texas ×

This topic is 8271 days old. Please don't post here. Open a new topic instead.

Recommended Posts

Posted

You're almost there.

To finish this with the technique you're using you'll need to also make the user's name (or some other ID unique to each user) part of the relationship.

In your main database, create a global text field. This field should be set to something like "1" & UserID where UserID is a unique identifier for each user that can long into a database. If each user has a unique user name entered, you can use Status( CurrentUserName ) instead of UserID. The only requirement is that it's unique for each user.

Once you have the found set of records in your organization database, use replace or a loop to see a field over there to the same thing, "1" & UserID.

Then a portal looking at a relationship between those two fields will only show the records found by that user. The reason this works is that global fields are unique to each user logged onto a served system, so if at startup a script sets a global field, that global field is only set for that user, not for the whole system.

The other way to do this, which would require backing up a bit and starting over, is to forego the search entirely, and have the user edit a key field (which is a global field) in the main database upon which a relationship to the organization database is based. For instance, if you have a global text field called gOrganization that the user can edit in the main database, and this field is the basis for a relationship to the Organization field in the organization database, editing this field will filter the portal down to just those records that have the same name in it. The downside to this is that the match must be exact. With find, you can search on "App" and it will bring up "Apple", but this technique won't do that. You can get around this limitation with calculated multi-key fields, but it gets pretty complex at that point, requring that you use the Left function to calculate all of the different combinations that the user might search on. It would look something like this:

Left( Organization, 1 ) & "

  • Newbies
Posted

Hey,

Im creating a database and one of the fields is "organization". The organizations are located in another database and is linked to the main database through a text field, which is called "constant" and is equal to 1 for all records ("constant" exists in both the main and the related organization database). What im trying to do is to be able to search the organization database from the main database and display the search results in a portal located in the main database. So, right now, i have a global field "gSearchOrg" where the users will enter the organization name they want to search. When they click on the search button the field named "constant" in the main db is set to 1, and then an external script from the organization db is performed. In this script im basically just going to find mode, then i set the field "org name" to gSearchOrg from the main db, and then i perform the find. It finds the correct records, but in the portal, which is located in the main db, it displays all the records not just the ones i searched for. The other thing ive tried was to set the field "constant" in the related db to nothing ("") for all organization records, and then set it equal to "1" for the found records. This does work, but only if one user is using the db. If more than one user is going to be using it and they'll perform searches at the same time, they'll get the wrong records displayed in the portal.

Any ideas on how i could set this up? Sorry if i post is a bit long, and i hope i explained it well enough for u to understand.

Thanks in advance.

  • 4 weeks later...
Posted

Correct me if I am wrong, but wouldn't the creation of a relationship based on the organization field work just fine?

I beleive it would. Why try to edit the relationship field, if you are linking to the organization table?

Posted

As glaser noted, it would make the most sense to just use a global_organization::organization relationship, IF you're only looking at one org at a time. But if you're searching for, e.g., "Airlines," you'd no doubt find more than one organization that matches.

Here's how you can work it with a bit of scripting:

1. Once the records are found, go to a layout with ONLY the org. id's on it.

2. Copy All Records

3. In your main database, Paste into a global field, and show a portal based on globalFoundIDs::org.ids

This method will not cause any problems for multiple users.

This topic is 8271 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 account

Sign in

Already have an account? Sign in here.

Sign In Now
×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.