Get all the values in current row without specifying all column names

Is there a way to get this? Something like CURRENTROW()?? If I can get the values for all columns, then I can search that record for a string of text. That’s what I need to do.

I can’t use _THISROW because that only returns the key column and value.

Here’s my use case: One of my tables, called Form, has about a hundred columns, each being a question on my form that I use in the app. If the value in any of the columns in the row I’m searching is “Fair” or “Poor/No” then I want that row flagged in some way, probably by creating a virtual field that specifies True/False if either of those text strings were found.

Any ideas would be so appreciated!

[_THISROW] may refer to the Key, but [_THISROW].[DIFFERENT COLUMN] gets the value of other columns in the same row. Otherwise sadly, there is no simple way to concatenate or search across a row that I know of.

3 Likes

Yeah, I need to search across all columns and I’m trying to avoid having to specify every column name in the search.

It would almost be easier to create an entirely new way to handle the form. It’s not elegant, and it will require lots of time (I think). But one idea I have would be to restructure the form to make it easier to search for your flags (which will help keep sync time down). The restructured form would be many rows and only a few columns. You could create a table specifically for the form that use one row per question. There would be a column to store your answers. Then you can search the column for if it needs to be flagged. The really, really hard part comes after they save this new form. You’d have to write a way via actions and/or workflows to write the form data to the main database as a single row so you can use the data later.

But the alternative is that you write an expression that specifies each of the columns in a VC that will be very performance heavy. And the performance hit is going to increase with each record you add. My idea would be a huge undertaking, but should limit the performance hit to only the transferring of the form data to the main table.

Nope.