Reference Table: What Am I Doing Wrong?

[JuneCorpuz]

Hello-

I need some help with this reference table. Here my columns

1. 
2. 

Here is the copy of the slice which is set to read only

Here are the result of my reference tables:

Any thoughts?

Thank you.

[Steve]

You haven’t described a problem.

[JuneCorpuz]

Hey Steve, I’m sorry. The first reference table (Photo #1) should read the slice (Photo #3) but based on my observation, the formula is not taking effect and ended reading the same as the (Photo #2). See the result on Photo #4.

[Steve]

That didn’t help me understand at all.

[JuneCorpuz]

Hey Steve.

1. This ref_rows targets the slice users_historys_slice wherein the update mode is set to read-only

2. This is the system generated ref_rows

Based on the conditions stated above, I’m getting the same results for Related users_historys_slice and Related users_historys

What am I doing wrong?

[Steve]

I’m not sure you’re doing anything wrong–your results don’t surprise me. What would you expect to be different?

Some things to consider:

• A slice consists of rows from the table it’s built upon. The slice’s row filter may be used to exclude rows from the table, but ultimately, the slice will only ever include rows that exist within the table it’s built on.

• The key column values of the rows in the slice will be the same as they are in the table, such that you could use a key column value from a slice row to look up the same row in the table (but not necessarily the other way around, because the slice’s filter may exclude some rows).

• REF_ROWS() is a shorthand way of asking, “which rows in the given table (users_historys) or slice (users_historys_slice) refer to this row by the given column (users_pk)?”

• Because the table row and the slice row share the same columns, the users_pk column in both users_historys and users_historys_slice are exactly the same. if the slice includes all of the rows of the table, we would expect REF_ROWS() to produce identical results for both.

But, now that I’ve written all that and I look back on your screenshots and comments, I’m going to guess the problem is that the results for users_historys_slice include an Add button even though the slice is read-only. Is that your concern?

[JuneCorpuz]

Steve:

But, now that I’ve written all that and I look back on your screenshots and comments, I’m going to guess the problem is that the results for users_historys_slice include an Add button even though the slice is read-only. Is that your concern?

Yes that is correct.

[Steve]

Would have been helpful and saved a lot of time if you’d just said that was the problem…

Please post a screenshot of the entire configuration of the Related users_historys_slice column.

[JuneCorpuz]

Sorry about that Steve.

Here are the screenshots

[hru]

Screenshoot of the slice is required, like below sample:

However, did the slice column was originated from a system generated REF_ROWS? (changed name, changed REF_ROW formula to slice?) forcing the system to re-create another REF_ROWS?

[JuneCorpuz]

Yup that’s what I did.

[hru · Accepted solution]

June_Corpuz:

Yup that’s what I did.

I would just delete that Virtual column and create a new virtual column manually, and point the REF_ROWS to the slice. And see that the “Add” should be gone.

And Since there is no Row-Filter-Condition, both VC (system VC and the new VC) should shown the same items, only different is there is no “Add”.

[JuneCorpuz]

Thanks Heru it works!

But this is what really solves my problem. The ELEMENT TYPE DETAILS Reference Table Name should also point to the slice not just the REF_ROWS formula.

[hru]

Yes, Thanks for sharing that. Good to know you’ve solved this.