I'm not sure quite what you're doing but it sounds like you are both doing a find on parent records which match enther name and then filtering the portal to only show the matching names.
The first problem I see is that you are filtering the portal via script variables $entry instead of via session/global variables $$entry. Script variables cease to exist at the end of the script in which they are set, so they can't properly filter a displayed portal after the script.
They might seem to work at first, but anything which causes the screen to refresh will cause the filter to then fail if it relies on a script variable instead of a session/global variable.
I suspect that IWP has more screen refresh/window-redraw issues which cause this to fail instantly.
That's what I see as a first problem. Try changing the filter to a session/global variable ( $$entry) and see if it has any effect.
That worked perfectly. Thanks!
On a second thought, this process will not work because of the 'record in use' problem.
I need the ability for users to search on the students table on multiple fields and display the matching results in a filtered portal row based on the vEntry field. Is there any way to accomplish this without locking the record every time a user tries to perform a find?
The method I described does NOT lock the record. It still uses the same global fields. It just changes the filtering on the portal to work off of a session/global $$variable (not a field at all). This does require setting the variable during the script so that it will persist as a $$variable after the script has completed.
How or why would you be encountering any form of record locking with either method? Variables don't lock records. If you need to reset the variable as they change the global fields, you need a script triggered on field exit which resets the variable for portal filtering.
If you encountering "record locking" can you describe what else is going on we don't know about yet? Variables of either script or session type ($ or $$) don't affect record locking.
I have a field gEntry (global text) on the students table for users to search for data. Found data is displayed in a portal row (students_list_view) in the students table. The relationship between the tables is Students X students_list_view.
By default, the database opens on the students table - the search field. It opens the same record for most users so when a user is entering data on the search field, another user gets the record in use error. How can I avoid this error locking?
It sounds like you are using a non-global field. Global fields can be edited simultaneously by multiple users, eve in the same record. Non-global fields can only be edited by a single user of the the record.
Go into the Manage Database screen and in the fields list, select the field in question.
Selet its options and set storage to Global. This will allow multiple users access to the field for editing without triggering record locking.
The field is global - I double checked...yet I get the same record in use error. Could it be the case that globals do not work as they should in IWP? (system is designed for IWP access only).
Portal refreshes can be more problematic on the web because the scripted command to refresh a window works in FMPro but does not call the same in a browser.
This can cause a lot of browser behaviors not matching FMPro experience. My speculation/supposition is that the global should behave the same, but the portal refresh may fail in IWP because browser window refreshes don't trigger the same.
Though the Window Refresh script step is listed as Web compatible, it may need to be actively invoked instead of relaying on a refresh that hasn't been triggered.
You may also need a flush cache step to force the global entry to be evaluated before the refresh is triggered, as IWP data is cached and flushed somewhat differently than in FMPro, where it usually happens in idle time as figured by the FM application.