Leaderboard

Here is another way you could do this. It uses conditional formatting to identify the exact items that cause the conflict with other orders. Again, more work is required if you want to see exactly which overlapping order has the offending item, but it might not be worth the trouble. BookingItemsConflict.fmp12

I see two problems with your request: First, if you have a user named Smith and another user named Smithson there is no way to know when the user enters "the last letter of their login name" unless you already know who is trying to login (in which case why bother with a login procedure?). The other problem is much more serious: it seems you are designing your own "login" procedure that works after the user is already logged in somehow (possibly as a guest?). This is an extremely bad and dangerous practice - see here why:

I am afraid we are not talking about the same thing. My suggestion is to divide the problem into two parts. In the first part you define a self-join relationship of the Orders table that identifies orders that overlap the current order's time span. This is easy to do using the existing, stored, fields of the Orders table: Orders::DateIn ≤ Orders 2::DateOut and Orders::DateOut ≥ Orders 2::DateIn and Orders::OrderID ≠ Orders 2::OrderID The second part is to identify which of the overlapping orders are conflicting - i.e. have a same product. This could be done in a number of ways, for example filtering the portal to Orders 2 by a calculation of: not IsEmpty ( FilterValues ( Orders::ProductIDs ; Orders 2::ProductIDs ) ) where ProductIDs is an unstored calculation field = List ( LineItems::ProductID ) Any records displayed in such filtered portal would be conflicting. You will have to make an additional effort to see exactly why they're conflicting, but perhaps it does not matter? Anyway, the idea is that the number of overlapping orders should be fairly small, so using an unstored calculation to find the conflicting ones among them should be sufficiently quick. Otherwise I see no choice but to move to a denormalized solution where the dates need to be replicated in the LineItems table, and you must take great care that this happens on every relevant layout, in every relevant scenario. --- Caveat: untested code.

You can construct the calculation along the lines of: List ( "image:Photos/" & ArtistName & ".jpg" ; "image:Photos/" & ArtistName & ".png" ) This will create both paths as a return-separated list. The container field will then go over this list and display the first image it can find.