# Inserting a table column screws up other column bindings **URL:** \ **Category:** Ignition\ **Tags:** perspective\ **Created:** [May 30, 2024, 3:11pm UTC](https://forum.inductiveautomation.com/t/inserting-a-table-column-screws-up-other-column-bindings/91146 "2024-05-30T15:11:45Z")\ **Posts on this page:** 1\ **Showing post:** 4
**Author:** ![pturmel](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/pturmel/32/3295_2.png) [@pturmel](https://forum.inductiveautomation.com/u/pturmel)\ **Post date:** [May 30, 2024, 3:19pm UTC](https://forum.inductiveautomation.com/t/inserting-a-table-column-screws-up-other-column-bindings/91146/4 "2024-05-30T15:19:27Z")
If all of the bindings are pulling from your query dataset, consider dynamically generating the entire `props.columns` list using the dataset's metadata. Some techniques: > [@Automation Professionals' Integration Toolkit Module](https://forum.inductiveautomation.com/t/automation-professionals-integration-toolkit-module/74934/5): > > I have spent my holiday poking at this. Wanted to provide an efficient replacement for a common use of python transforms: Make a (Perspective) table that dynamically populates both .data and .columns from source dataset that isn't constrained to any particular structure or data types. In Vision, one can achieve this (mostly) by pre-populating the column attributes dataset with all of the possible column names your application might deliver. No such thing in Perspective. But a transform can … (Whether you use my toolkit or not.) --- _[View the full topic](https://forum.inductiveautomation.com/t/inserting-a-table-column-screws-up-other-column-bindings/91146)._