Not wanting to have the last world or be right (because both solutions work), I’ll just add the knowledge I acquired in long, frustrating sessions to prevent others from the same fate in more complex scenarios:
Both methods make sure that the column only contains values of one type (String). How I understand it, the format detection takes the data in the first row it encounters. I just made a quick test with a formula that creates number, date, boolean and string values.
ifs(
{Name}="A",True(),
{Name}="B",12,
{Name}="C","Hello world",
{Name}="D",today()
)
Try putting this formula column into a new table, create 5 lines, and put “A” to “E” into the “Name” column. Just by re-sorting the rows (pull one of them to the #1 position), you can get Seatable to recognize different data types for that column - and create weird effects on the other types. And it still produces an error for the entry “E”.
So while both methods make sure that the value is always a string and guarantee string detection regardless of row order and content, my personal learnings from this are:
- &“” uses an undocumented, implicit functionality, unless the Seatable programmers tell my that this is by design. I’d rather use documented, explicit methods.
- It works only (?) with strings. As soon as you need to make sure that the column only contains numbers or dates, you might come back to this discussion.
