chrispy_be Posted June 24, 2008 Share Posted June 24, 2008 Hi, I would like to create a portal which dispays the find results instead of the List View, easy..., but how can i do this for more than one user at a time? Thanks, Chris Link to comment Share on other sites More sharing options...
AHunter3 Posted June 24, 2008 Share Posted June 24, 2008 Use a global field in a relationship to the portal records; the Find requests go in the global field (no actual FIND is performed of course). Since it's a global field it will have a different value for each user each of whom will have their own "found set". It has its limitations; nowhere near as flexible as true Find Mode, you can't do multiple requests and whatnot that way (at least not easily) but for a finite number of fields you can store requests in the global and have the relationship match occur. By far the easiest is a single-field match, if the FIND you had in mind is searching a single request in a single field. Link to comment Share on other sites More sharing options...
Josh Ormond Posted June 30, 2008 Share Posted June 30, 2008 Don't know if this helps or not...while it isn't true portal filtering, visually it works for what I needed. I am sure there are more efficient ways of handling, but left on my own, this was what I could come up with in short order. I made this a while back, because I wanted the power of the find, but the look, size, control of a portal. Type in the word or phrase and click go. It can also be a partial word and in any field you include in the script. It just uses a script that generates the actual find requests for each field, then grabs the ID's of each record in the found set and places it in a global field to generate the portal list using the relationship between the search table and the customer table. It throws the search text into the find fields with * before and after, to find that string anywhere in the fields. (That can be handled anyway you want to give more Find like results) This works well with small found sets...very slow for large find sets. NOTE: The larger the found set, the longer this script takes. I tested it with 30,000 records. A found set of 400 takes roughly 1-2 secs...1000 about 5 secs...8000 about 2 mins. EDIT: The attached file has been moved. See updated file below. Link to comment Share on other sites More sharing options...
chrispy_be Posted July 1, 2008 Author Share Posted July 1, 2008 Thanks to you for taking the time to help me! Much Appreciated Chris Link to comment Share on other sites More sharing options...
extensitech Posted July 1, 2008 Share Posted July 1, 2008 This is quite interesting. Have you considered using the "List" function, instead of looping for keys? For large found sets, perhaps a limit to the retreived records might be in order, with pages? Like, showing 1-100 of 1000, and when you click "more" the script does the same finds, but gets the next 100 keys? This is quite thought-provoking. Thank you for sharing. Chris Cain Extensitech, Inc. Link to comment Share on other sites More sharing options...
Josh Ormond Posted July 1, 2008 Share Posted July 1, 2008 Yes, I am actually getting ready to extend it further. I made this about 4/5 months ago. It solved a minor problem on a relatively small solution, one that you never end up with more than a handful of records in the found set. Until now, I hadn't had a reason to make it more powerful or efficient. Hopefully I can get to it in a couple weeks. I will re-post then...unless someone else gets there first. Thanks for the Feedback. Link to comment Share on other sites More sharing options...
Josh Ormond Posted July 1, 2008 Share Posted July 1, 2008 I saw another thread from Ahunter3 that prompted me to try a different method. 1. Created another layout to show just the ID from the found set. 2. Used the "Copy All Records" script step to put all the IDs on the clipboard. 3. Back to the Search layout...Pasted it into the gID field on the search layout. 4. Commit Records!!! Tested it on a database with 32000 records, and it returns a Found Set of 14000 records in about 3 sec. Much faster than it was... Edit: Updated file below... Link to comment Share on other sites More sharing options...
Josh Ormond Posted August 29, 2008 Share Posted August 29, 2008 Thanks to David Head for his superior wisdom... Simple and smooth (and probably not new), here is an update sample file that eliminates the copy and paste. It uses a custom function from Ray Cologon to create a unique "Search ID". Used to tag the found set and create the relationship for the results portal. Here is an updated sample file... Link to comment Share on other sites More sharing options...
aislinn Posted September 1, 2008 Share Posted September 1, 2008 Use a global field in a relationship to the portal records; the Find requests go in the global field (no actual FIND is performed of course). Since it's a global field it will have a different value for each user each of whom will have their own "found set". What do you mean "no actual FIND is performed"? How do you get the found set then? Am I missing something? I'm looking for some "best practices" on setting op a multi-user database so that in some layouts (e.g. "my projects"), each user only sees records meant "for their eyes". In other layouts (e.g. customer database), they should be able to access all customer records. Can anyone point me to some interesting threads or tutorials that treat this phenomenon? Isabelle Link to comment Share on other sites More sharing options...
AHunter3 Posted September 1, 2008 Share Posted September 1, 2008 What do you mean "no actual FIND is performed"? How do you get the found set then? Am I missing something? No found set is generated either; the results of the pseudo-"FIND" are displayed in the portal. If you actually want to end up with a found set of the records that currently show in the portal, you need only do a Go to Related Record [show only related, PortalRelationship]. That's not really a FIND either — Go to Related Records is a different process than a Find as we usually construe it. I'm looking for some "best practices" on setting op a multi-user database so that in some layouts (e.g. "my projects"), each user only sees records meant "for their eyes". In other layouts (e.g. customer database), they should be able to access all customer records. Can anyone point me to some interesting threads or tutorials that treat this phenomenon? The portal technique is pretty good for showing only "my projects". If you need it to be securely so, you need to edit Accounts & Privileges so that people with that level of user access can only view records that are records of "their projects". Link to comment Share on other sites More sharing options...
aislinn Posted September 1, 2008 Share Posted September 1, 2008 The portal technique is pretty good for showing only "my projects". If you need it to be securely so, you need to edit Accounts & Privileges so that people with that level of user access can only view records that are records of "their projects". I actually have a system in place where in the layout MyProjects there is a portal giving an overview of a certain user's projects based on the logged user (Get (AccountName) function). However, when I scroll down, there is a vast number of "empty records" showing. When I check the status area, it shows the found records to be all records in the project database. Is this what's causing the problem? Link to comment Share on other sites More sharing options...
AHunter3 Posted September 1, 2008 Share Posted September 1, 2008 No. The portal, by definition, shows only related records. Either something is amiss in your relatioship definition or else you've got blank records associated with the current user. I assume you are setting a global field to the value of Get(AccountName), and using the Global in the relationship ? Link to comment Share on other sites More sharing options...
aislinn Posted September 2, 2008 Share Posted September 2, 2008 No. The portal, by definition, shows only related records. Either something is amiss in your relatioship definition or else you've got blank records associated with the current user. I assume you are setting a global field to the value of Get(AccountName), and using the Global in the relationship ? Indeed, as well as a globalcalc to check for active projects. In any case, some serious scrutinizing of my layout led me to the source of the problem, thanks to your comment. smiley-smile The portals were apparently not correctly sourced. One less problem on my checklist! Thanx! Link to comment Share on other sites More sharing options...
millennium Posted May 10, 2012 Share Posted May 10, 2012 EDIT: The attached file has been moved. See updated file below. I must be blind! Where is the file? Link to comment Share on other sites More sharing options...
Techphan Posted May 10, 2012 Share Posted May 10, 2012 I must be blind! Where is the file? A lot of the attachments did not make it through the conversion process for this website. Link to comment Share on other sites More sharing options...
Josh Ormond Posted May 10, 2012 Share Posted May 10, 2012 Here is the file. I think this is the same one. It works fairly well for small to medium sized found sets. I included a little bit of sample data. Searching for cities in the "Text" field will give you the most search results ( Portland, New York, Phoenix, Foxboro, and a few others are in the data set ). You can also save searches if you change the script a little. But it's very outdated, since FM now includes saved finds. Disclaimer: This is a fairly old file. There are numerous ways to accomplish this task. Especially since this file was originally created in version 8 or 9. If you are returning very large "found" sets, it will be increasingly slower as the data set gets larger. Faux Portal Filter.fp7 Link to comment Share on other sites More sharing options...
By Soliant Consulting,
By Soliant Consulting,
By Soliant Consulting,
Recommended Posts