Jump to content

Bizarre Find Fail


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

Recommended Posts

I fell like I'm going insane.  I've created a simple little solution, just a couple related tables, no big deal.  I am creating records via a portal in a Parent table layout, and the records are turning up fine. 

....but somehow on newly-created records, perfectly simple one-field FIND efforts are simply failing.  I am looking at simple layout based on the child table, and the records are there.  In browse mode, I am looking at a record as you see below -- and searching for a record using the primary key, and it just yields no matches.  SO I put a simple text field on the layout as you see.  I am in Brose mode and I can see the value is '222'.  So I search on that field entering '222' -- as you can see, no hits!?? I am simply copying and pasting the field content right back in for a find and getting nothing.

Searches for other records work, but not this newest record.  I can move through the records and try again, no luck (so its not a record commitment problem?).  But eventually, perhaps by closing the window, coming back, at some point, the find *does* work for that record .... but if I create a new one via the relationship, it fails all over again.

BUT, if I create a new record on this layout, the problem doesn't arise.  So it seems something to do with the relationship, but I can't fathom what?  How can a simple direct search on a text field fail?

The picture below left is in Browse mode, looking at an existing record - the second picture is the Find fail.

 

record.jpg

findfail.jpg

Link to comment
Share on other sites

Well, here's the file itself. It's pretty simple.

The situation arose as I was trying to solve the 'portal within a portal' prohibition by using a Card window triggered by a button in the portal to assign 'tags' to Scene records, which are themselves in a portal on the main 'Card' record layout (not unfortunate Card / Card terminology which is a coincidence).  Entities:

Cards > Scenes > Tags

The problem is occurring in the Layout named 'Tagging' which is built on a 'Scene' Context. 

Confronted by the bug, I kept hacking away at the sole script attached to the button, figuring i had left something out . . . so the script may not be right -- I abandoned that angle when I found the simple 

'Tagging' layout just wasn't working for simple 'Finds'. 

IRC_1.4.fmp12

Link to comment
Share on other sites

4 hours ago, Wickerman said:

Well, here's the file itself. It's pretty simple.

 Apparently not simple enough for me to reproduce the problem. I created a new record in the 'Tagging' layout, entered a value into the Number_Scene field and committed the record. I had no problem finding the record. You said that the problem is with records created via a relationship - so I went to the Cards layout and created a new record in Scenes by entering a value into the Number_Scene field in the last row of the portal. Switched to  the 'Tagging' layout and again, no problem finding the record.

 

Link to comment
Share on other sites

Thanks spy much for giving this a try.  Could you try this particular sequence.

1) On the Cards Layout, create a new Scene by entering a value in the "Scene #" field (top of portal row).

2)Commit the record by tabbing or clicking out of the field. Note that the primary key field is populated, and copy that value onto your clipboard.

3) Click on the portal button with the pen icon.  This is now supposed to pop open a card window with a portal in it for adding subject-term keywords to a sub-table of 'Scenes'. The name of the "Scene" that you entered should appear in the little black header.

4) If you are experiencing the problem, nothing will happen, because the script isn't able to find this Scene record.

5) Now go to the Tagging layout, and try to Find the record by pasting the _pk_ into the _pk_ field. (visually note the first few characters)

6) If you get no hit, that's my problem.  Now if you do a "Show All" records and go to the newest one, you will find the record matching the _pk_ you copied.

---

In the picture below you can see a newly-created 'Scene' record in the portal. The fact that the primary key has been populated is, to my understanding, a site  that the child record has been created. 

. . . and yet the button script is not able to find the record doing a find on the current _pk_, which I set as a variable in the script.   (I originally used a Quick Find, but changed it to the Perform Find while trying various things to make it work).

committed.jpg

Link to comment
Share on other sites

Sorry to dump so much on you.  I think I figured out its some kind of record commitment failure.  It seems as though the sub-record is being committed, as the key fields are populating -- but until I click out of the portal onto the main layout, the solution isn't 'seeing' the new sub-record.

So, I just need to put in a script-step that achieves that -- perhaps just 'Go To Field' outside the portal and then back in?  I'm afraid some of the record commitment subtleties tend to pass me by....

Link to comment
Share on other sites

Fields being populated are no indication of record being committed. If you want to know if the current record is committed, use the Get(RecordOpenState) function. If you want to make sure the record is committed, you can use the Commit Records/Requests[] script step.

The confusing part here is your use of another layout. As a rule, switching to another layout commits the record. But perhaps you are opening the other layout in a new window; in such case, the record in the original window will remain open.

 

Link to comment
Share on other sites

Thanks for the elucidation.  And yes, I think the problem involves opening the new window without getting out of the portal in the original layout.

The  Commit Records step has done the trick -- I had tried that, but I think I had put it at the wrong step in the script.

Thanks a million for your patient assistance.

Link to comment
Share on other sites

This topic is 960 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.