Okay, yeah, so don't do that. If you need a binding to poll, use an expression now(updateRateMilliseconds) - at least if you're throwing that away it's going to run in a few microseconds, and not require a full network IO hop to retrieve history data that's then immediately discarded.
But all that's a tangent. Let's go back a step:
You have a bunch of individual tags here that you're trying to assemble into a dataset for display on a view. That's fine.
Are each of these individual tags supposed to be stored into a database? You almost certainly want them to be logged individually - not in some kind of pseudo dataset format. If you just need trends over time, that's a fine job for the tag historian. If you want event driven storage, such as "when I change X, do Y", then you need either transaction groups or to just script database updates. This is a totally separate problem from the live display in a table problem, and should be treated as such.
The "live display of a sequence of values" problem is best handled with bindings, so that you don't have to do the polling yourself and can reuse our tag subscription mechanisms for efficiency. Unfortunately it's slightly convoluted to do this - you need to configure an inner view to use for each row of the table, and provide it tag paths to use internally in indirect bindings: