# Table cannot have a number as name of a column **URL:** \ **Category:** Ignition\ **Created:** [June 12, 2023, 9:11am UTC](https://forum.inductiveautomation.com/t/table-cannot-have-a-number-as-name-of-a-column/74897 "2023-06-12T09:11:47Z")\ **Posts on this page:** 12\ **Page:** 1
**Author:** ![r.p](https://avatars.discourse-cdn.com/v4/letter/r/71e660/32.png) [@r.p](https://forum.inductiveautomation.com/u/r.p)\ **Post date:** [June 12, 2023, 9:11am UTC](https://forum.inductiveautomation.com/t/table-cannot-have-a-number-as-name-of-a-column/74897/1 "2023-06-12T09:11:47Z")
In a table it is not possible to give the string 0 as the title of a column because it is interpreted as a number instead of the string, passing "0" instead returns the double quotes in the column name. (yes we need to give the columns the names: 0, 1 , 2, 3 for a particular project) Below a screenshot as an explanation: ![image](https://us1.discourse-cdn.com/inductiveautomation/original/3X/5/7/5790dd2018de69b8c343f3f25998a318ab2384bf.png) ---
**Author:** ![Hayden\_Watson](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/hayden_watson/32/48792_2.png) [@Hayden\_Watson](https://forum.inductiveautomation.com/u/Hayden_Watson)\ **Post date:** [June 12, 2023, 11:24am UTC](https://forum.inductiveautomation.com/t/table-cannot-have-a-number-as-name-of-a-column/74897/2 "2023-06-12T11:24:23Z")
Maybe use an expression binding on the title ```auto toStr(0) ``` ---
**Author:** ![Transistor](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/transistor/32/3380_2.png) [@Transistor](https://forum.inductiveautomation.com/u/Transistor)\ **Post date:** [June 12, 2023, 11:26am UTC](https://forum.inductiveautomation.com/t/table-cannot-have-a-number-as-name-of-a-column/74897/3 "2023-06-12T11:26:49Z")
Option 1: ![Table header 0](https://us1.discourse-cdn.com/inductiveautomation/original/3X/3/0/30c09f16ef7a0be196d56ac1f1cbdbe2fc1ed2bd.png) _stringFormat returns a string._ Option 2: ![Table header 1](https://us1.discourse-cdn.com/inductiveautomation/original/3X/5/5/5553d18b8291699f660b0093956c33008a69a10d.png) _ASCII 48 = '0'._ Option 3: ![Table header 2](https://us1.discourse-cdn.com/inductiveautomation/original/3X/a/3/a3c3631e9d74ff09cc4d2c50451d640319d39336.png) _A leading space will force a string._ ---
**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:** [June 12, 2023, 12:31pm UTC](https://forum.inductiveautomation.com/t/table-cannot-have-a-number-as-name-of-a-column/74897/4 "2023-06-12T12:31:31Z")
> [@r.p](#): > > yes we need to give the columns the names: 0, 1 , 2, 3 for a particular project In general, you cannot have dataset column names that start with a digit. Whether you need it or not. The working approach is to **display** substitute column **headers** where needed. ---
**Author:** ![r.p](https://avatars.discourse-cdn.com/v4/letter/r/71e660/32.png) [@r.p](https://forum.inductiveautomation.com/u/r.p)\ **Post date:** [June 12, 2023, 12:54pm UTC](https://forum.inductiveautomation.com/t/table-cannot-have-a-number-as-name-of-a-column/74897/5 "2023-06-12T12:54:43Z")
I see there are several workarounds but using an Expressions is not ideal for us because we try to use Python for our Business Logic and using alternate names for the columns means more transformations in the process from the original query. There's a similar problem for dictionaries associated to a binding which I notified before but hasn't been replied to: > [@\[BUG\]: binding returning a dict with string keys representing a number cause KeyError in designer](https://forum.inductiveautomation.com/t/bug-binding-returning-a-dict-with-string-keys-representing-a-number-cause-keyerror-in-designer/74619): > > If you create a binding which returns a dictionary and some keys are strings that represent a number they are interpreted as a number which is not a valid key for the dict. See screenshot below (0 is a string "0" but is interpreted nevertheless as the number 0). At the moment only solution is to prepend a "\_0" to the keys. [image] [image] hope these will be properly addressed in the future. ---
**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:** [June 12, 2023, 1:03pm UTC](https://forum.inductiveautomation.com/t/table-cannot-have-a-number-as-name-of-a-column/74897/6 "2023-06-12T13:03:25Z")
> [@r.p](#): > > hope these will be properly addressed in the future. Don't hold your breath waiting for this fundamental behavior to change. You should fix your mis-use of numbers where identifiers are needed, however deep in your technology stack the rot goes. If you are smart, you will also forbids spaces in such names, along with any other characters that aren't legal in identifiers for programming languages. If you are wise, you will add automated checks to your development practices to ensure this. ---
**Author:** ![Tim\_Carlton](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/tim_carlton/32/52835_2.png) [@Tim\_Carlton](https://forum.inductiveautomation.com/u/Tim_Carlton)\ **Post date:** [June 12, 2023, 1:19pm UTC](https://forum.inductiveautomation.com/t/table-cannot-have-a-number-as-name-of-a-column/74897/7 "2023-06-12T13:19:08Z")
Evil Type Coercion. Use a language / environment that doesn't do it or do stupid-string-tricks like prepending a non-digit character. ---
**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:** [June 12, 2023, 1:34pm UTC](https://forum.inductiveautomation.com/t/table-cannot-have-a-number-as-name-of-a-column/74897/8 "2023-06-12T13:34:39Z")
> [@Tim\_Carlton](#): > > Use a language / environment that doesn't do it I'm a big fan of strictly typed languages. I've yet to see an easy-to-learn-and-use scripting language that is strictly typed. Probably because strict typing is not easy for many people to wrap their heads around. I've also yet to see **any** programming language that didn't have **some** restrictions on how identifiers are formed. Do you have a suggestion? Or was that a throw-away line? ---
**Author:** ![Tim\_Carlton](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/tim_carlton/32/52835_2.png) [@Tim\_Carlton](https://forum.inductiveautomation.com/u/Tim_Carlton)\ **Post date:** [June 12, 2023, 1:47pm UTC](https://forum.inductiveautomation.com/t/table-cannot-have-a-number-as-name-of-a-column/74897/9 "2023-06-12T13:47:54Z")
My suggestion is - understand that in most endeavors there are essentially three approaches - Big Design Up Front (BDUF), Agile, and ad-hoc. - understand your personal preferences and the risks (e.g., a large expedition vs an alpine climb) - understand the problem that you are trying to solve - pick a toolset that best solves the problem - implement standards, processes, scripts that mitigate the risks Ignition solves a certain class of problem very well. It uses Jython 2.7. Don't wait for the next release of Jython to fix duck-typing - it isn't going to happen. You don't have to embrace it, but you can accept it. If you can't accept it then move along. If you are doing HMI/SCADA then you will probably end up writing your own from scratch. And you will discover the stupid-xyz-tricks required there. Once you realize the size of that project it makes it easier to accept the workarounds. ---
**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:** [June 12, 2023, 2:20pm UTC](https://forum.inductiveautomation.com/t/table-cannot-have-a-number-as-name-of-a-column/74897/10 "2023-06-12T14:20:02Z")
> [@Tim\_Carlton](#): > > Once you realize the size of that project it makes it easier to accept the workarounds. Precisely. Ergo, design practices that mitigate the pain of those workarounds. ---
**Author:** ![pascal.fragnoud](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/pascal.fragnoud/32/24728_2.png) [@pascal.fragnoud](https://forum.inductiveautomation.com/u/pascal.fragnoud)\ **Post date:** [June 12, 2023, 2:31pm UTC](https://forum.inductiveautomation.com/t/table-cannot-have-a-number-as-name-of-a-column/74897/11 "2023-06-12T14:31:20Z")
I use this when using user input as a key/column name: ```python import unicodedata def remove_accents(s): # NKFD: https://fr.wikipedia.org/wiki/Normalisation_Unicode#NFKD nfkd_form = unicodedata.normalize('NFKD', s) return "".join([c for c in nfkd_form if not unicodedata.combining(c)]) class MalformedKeyError(Exception): pass def make_key(s): """ Sanitize a string so it can be used as a key in an ignition object. If the first character is a digit, an underscore is added before it accents are removed leading and trailing whitespaces are removed other whitespaces are replaced with an underscore """ if isinstance(s, str): s = s.decode('utf-8') key = s.strip() if not key: raise MalformedKeyError("Can't sanitize {!r} into a valid key".format(s)) if key[0] in "0123456789": key = '_' + key return re.sub('\W+', '_', remove_accents(key)) ``` And while we're on this subject, I'll take any advice on improving it. edit: I guess I should filter out any symbols that would make it invalid... like `+` and such. edit: changed things a bit to handle any non-alphanum character. This should make it a valid python identifier. Am i forgetting something ? ---
**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:** [June 12, 2023, 2:35pm UTC](https://forum.inductiveautomation.com/t/table-cannot-have-a-number-as-name-of-a-column/74897/12 "2023-06-12T14:35:45Z")
I generally use the [system.dataset.mungeColumnName()](https://www.automation-pros.com/simaids/doc/index.html) function from my [Simulation Aids module](https://inductiveautomation.com/moduleshowcase/module/automation-professionals-llc-simulation-aids).