Warn with Column name matches existing table

Had a table called Tasks, and a table called TimeLogs. TimeLogs have a lookup column that selects a single task and logs a start time and an end time. Because I referenced the TimeLogs several times in my Task columns, I created a column in Tasks called TimeLogs. Some of my functionality broke as it thought I was referring to either the table or the column incorrectly in several places. When referring to the column, I can make sure to use CurrentValue.TimeLogs or thisRow.TimeLogs, but sometimes when I wanted the table, it would assume I meant the thisRow or CurrentValue, but there is no way to tell it, no I mean Table.TimeLogs.

Would be nice if it warned me or blocked me from naming them the same, as I’m not sure there is a place to go to see all the filters, column functions, etc that have been broken, other then going through them one by one, or waiting for a coworker to complain that a feature is broken.

I think when you create a lookup column, it automatically names it the same as the table?

Hello @N_G ,

There are a couple of things you can do:

  1. don’t have tables and columns with the same name - you can rename the column and your formulas will adjust themselves accordingly
  2. when you are typing formulas, there are little icons next to the names that appear and they indicate whether you are dealing with a table or with a column.
1 Like

Thanks for the reply @joost_mineur . I am definitely going to choose a naming convention form now on that will avoid this scenario in the future.

Not important I guess but just some thoughts I had about what happened:
So I had this weird issue where a button inside table Tasks referenced TimeLogs.Filter(). And it worked fine for weeks. Then I added a Column in Tasks called TimeLogs, and my button broke… This is odd since the formulahelper lets us select which specific TimeLog we are referring to (without needing to prefix with thisRow, etc as long as we used the formulahelper to select the right object). Was odd that it suddenly thought I was talking about the column TimeLogs, even though it new it to be the table TimeLogs before.

I am getting alot of feedback over the past several days that prefixing slows down formulas (could be miniscule and not worth mentioning, not sure), and I was afraid of not prefixing because this type of situation where it chooses the incorrect one could happen. But, I also learned that if you use the formulahelper to select the right object, it locks in the correct one, so no need to prefix. But it seems it grabbed the right one for a bit and then made it be the wrong one, so I’m not sure if I can trust the formulahelper selecting versus prefixing… anywho… all to say the naming convention sounds like the most trustable solution to this problem.