The criterion: ==Jaw cylinder
Should not find records where the text in that field is Jaw Cylinder Black orJaw Cylinder White
I assume that Item is the field that holds this data?
There is an error in your script
Set Field [Transactions::Item ; Transactions::Item]
which assigns nothing as search criteria as you are in find mode at this point. It should be:
"==" & $ShopItem
and you might choose to use:
"==" & Quote ( $ShopItem )
to enclose the value in quotation marks if there is any chance that there is a special character such as #, *, @ etc as part of the text in Item.
Also after it finishes the first record it will move onto the blank portal row
This is one reason NOT to loop through the rows of a portal. If you used Go To Related Records to pull up this set of portal records on a layout based on the portal, you can use go to Records/request/page [next ; exit after last] and not have a blank portal row to deal with.
But you can also use:
Exit Loop IF [ Get (ActivePortalRowNumber ) = Count ( Transactions::Serial#) ]
This assumes that your portal is not filtered.
I am taking your advice and I made a new script with Go to Related Record. When ran, however, it pulls up the previous records information into my new layout RelatedShopItems (Transactions) **created for Go to related records**. I even tried to turn the triggers off! The info from the portal, shows related records from Transactions and it is located on ShopOrderForm (PurchaseOrders).
Since your portal is based on the same table that you are searching with your find, you have to get a bit creative to keep your original found set of portal records intact while performing finds.
This can be done in one of two ways:
Use two layouts based on two occurrences of transactions. you use GTRR to pull up your found set on one layout and perform your finds on the other. As long as your two layouts are not based on the same occurrence of transactions, the two found sets will be independent of each other.
Open a new window and perform the finds in one window while looping through the set or records in the other.
But you might also consider not performing any finds at all. A self join relationship can be set up that matches only to the records your find is pulling up and then you can use count to count the number of related records. If count counts more than one related record, you have duplicates.
Hmmm and another thought: why perform a find specifying the name or description of the item? each item should be identified by a unique ID and you should be searching for duplicate instances of the ID rather than the name/description. This completely avoids the issue of searching for
"Jaw Cylinder" and finding "Jaw Cylinder Black"
I have thought about this and we do have a unique ID called ItemID. But the ItemID would need to match and also the serial number for there to be a duplicate. Is this still possible?