Constrain to Current Record?

[Courtney]

I'm thinking there is surely an easy answer to this, but I'm not finding it. Is there a way to constrain the found set to just the current record? Or put another way - omit all records except the current record?  I can certainly write a little find routine to do this, but I figured there might be something I'm overlooking?

[dwdata]

if the record you are on has a UNIQUE primary key, you can use the Find Matching Records [] script step on that field.

Hope this helps!

[LaRetta]

Another option which may work better in other situations where the record is not unique ... 

Freeze Window
Show All Records
Omit Record
Show Omitted Only
Loop
Exit Loop If [ Get ( FoundCount ) = 1
Go To Record/Request/Page [ Last ]
Omit Record
End Loop

This was presented by JT aka -Queue- many years ago.  The reason the loop is important is that, in the instant the step 'Show Omitted Only' fires, if another User creates a new record, it could also end up in your found set.  That other-user-created record would be after your record so the loop omits it if it should occur.

[Courtney]

Thanks folks!

[bcooney]

Another method is Go To Related Record, current layout, using a relationship that matches primary key to primary key.

[LaRetta]

Good point, Barbara.  Of course this does require a self-join relationship.  Adding a table occurrence just to provide this functionality is a bit much but if it already exists and there is a unique Key (which there should always be) then one can use it.   

Don's suggestion is ideal since it requires the least amount of support.  All tables should contain a *unique ID although some do not, which is why I made the alternate suggestion.

* Some tables lack a unique ID because of migration in progress or because the developer thought a primary key is only necessary if the table is going to be used in a relationship but this is incorrect ... ALL tables should contain a unique ID.

Nice to see you around!  :-)

[Mark Scott]

Good point, Barbara.  Of course this does require a self-join relationship.  Adding a table occurrence just to provide this functionality is a bit much but if it already exists and there is a unique Key (which there should always be) then one can use it.

Another option — not necessarily better than Don's, but having options is good — would be to leverage Selector-Connector (if you've already got that approach in place, that is).

Set the respective "id" field in the Selector table to the current record's id, then GTRR from that table to the connected occurrence of the current table.  In S/C, each main table usually will have a second occurrence hanging off of the Selector table, so it avoids adding a TO just to provide the functionality of isolating the current record.  - Just a thought.

BTW…

ALL tables should contain a unique ID.

Couldn't agree more, LaRetta!  Thanks for reminding us of that.

Mark

Edited July 9, 2015 by Mark Scott

[LaRetta]

By the way, thanks for mentioning Selector-Connector which is a new structural concept Selector-Connector by Todd Geist.

[Fitch]

Should a single-record prefs table have a unique ID field?

[LaRetta]

Ah, thank you - that wouldn't make sense, now would it, Tom!

The purpose of the unique ID (aside from relationships) is to provide a means of data retrieval allowing import (Update and/or Add To) based upon matching ID.  It is critically important.  You understand this of course, Tom.

However, I do believe that a single-record table should have auto-enter data of 1 and then validate that one_record_only field to 'unique always, do not allow override' so in a sense, it has a unique ID as well. :-)

[dwdata]

Haha - we can officially called the cat skinned ;oP

[LaRetta]

Haha - we can officially called the cat skinned ;oP

Not any of MY family, I hope!  We're a bit sensitive about the hairless cat jokes.  

One thing I love about this forum is that we present options and, as Mark said, options are always good and we've covered every possibility now, that's for sure!