I am regularly encountering the data type of a column being automatically changed based on values I enter in a cell.
I can kind of accept this behaviour when first entering a value in a column (I don’t agree with it, but I can accept it), but it is very frustrating when a long-standing column’s data type gets changed from text to number just because I enter a number at some point. This is very bad behaviour.
The whole concept is poor anyway as it just creates bad habits in developers, a-la Microsoft Access.
Addresses. I have a doc where customers can fill in orders with address and stuff. An address can be like 55 Ridge Road or Ridge Road 55. If a uses the first one…Coda sometimes decides that the column should be a guest what…number and as a result throwing the red flag error.
If I as a maker decide rightly or wrongly that a column should be text or number or whatever then just give me the control to do exactly that. If in CFL you see in a formula that the column should be number an don’t text then throw the flag so I see it and fix it rather than Coda doing it behind my back.
In that way I fix the CFL once rather than changing column type every time Coda thinks it detected numbers in a text column.
My top of mind example is not going to be addressed by that approach.
I am building a rental property management tool for a friend of mine that lives in South Africa. Part of it is to upload digital bank statements, and I am having endless problems with that, made worse by the fact that Coda does not support non-American date formats.
Can we have an Edit column setting that says “Do not try to re-interpret my meaning!”?
I have been in IT for forty years, and I cannot understand that this is such a problem for Coda.
The place that it affects one of my apps is as follows:
We use a temporary table as a pre-fill form so that data can be validated (lack of data validation is another matter!)
The user uses a button to submit and move the entry into the backend table.
the pre-fill form is now empty again ready for a new entry.
Because the form is empty, there is no pre-existing data to ‘lock’ the columns to their column type, so a user can now start a text field with a number, and the column is changed to number type, which breaks the data validation that happens down the line.
My 2 cents on this topic (and it was discussed many times before but seems to no improvement) is that coda column SHOULD NEVER EVER AUTOMATICALLY change its type… I mean whats the point of that ?
If we as Doc makers set some column to be certain type WE KNOW why we did that and we don’t need Coda to rearrange this, its just makes a whole lot of troubles for us (imagine SQL or Mongo doing)
Sorry for a bit of caps talk but its just frustrating.
At lest give us option to manually “lock” the column type, it will be much better solution than to rearrange logic when to do it when to not do it because in 99% there is no use case where this is helpful in my humble opinion.
I have a blank table I use to import data I get from an outside source so I can analyze it. Coda was always changing the column type from what I had specified and this table has over 50 columns so very annoying. I ‘fixed’ it by including fake data in the first row permanently so Coda would stop changing it. Maybe have a default of choosing for us but have a toggle for us to turn it off if we want complete control.
@nathan Except for the cases mentioned, I have another one which is super common, understand in every single doc I build. The lack of a phone number field in Coda is my most common scenario for every single document I build and when column format always changes to number.
I have workarounds, but I find minimal value in the automatic column format change and would rather prefer not to be happening at all.
Another example, similar to my bank statement example above. Every now and again I do a download of data from our ERP system. SAP typically downloads it in .XLS format, which I cut and paste into Coda to use.
There can be two reasons
either because I am downloading information to serve as a basis for documentation,
or I want do some kind of analysis on the data.
In neither of the scenarios is having a random row of type-forcing entries the ideal solution.
The ideal solution is to use the column type to do the type-forcing.
Surely that’s the reason to have a column type, right? To determine the type of the column?
Thank you everyone for adding to this conversation.
Dear Coda, please understand that there is almost zero benefit to this behaviour, and that minimal benefit is far outweighed by the challenges it causes.
So, PLEASE just get rid of it, rather than trying to “limit the logic” of when it is employed. All that approach is doing is further reducing any perceived benefit anyway, and actually just strengthens the reasons to just get rid of it altogether.
I have two scenarios that affect me. In both cases I use an intermediary table to do data checking etc. Because these helper tables only ever have a single record in them (because the helper record gets deleted once the process is over).
The first example is when creating a support request. In there I have a text field for record numerical ID numbers from another system. So why a text field? Because I often need to record more than one so I do that as a comma separated string. When this happens a bunch of downstream functionality gets broken, and one of the reasons for that is because when the column gets changed to numbers the thousand’s separator is turned on by default, so a comma gets added to the now number, breaking future functions that split the field on the comma. Sure, I could change all my logic to workaround this, but I shouldn’t have to.
I have another example where a relation column gets changed to text. This is also in an intermediary table. I have a table for sending a quick email to a customer. The recipient field in this table is a relation column to the customers table. When I click my “send email” button in the customer table it creates a record in the email table and sets the recipient column to the customer, but very annoyingly, the recipient column sometimes gets changed to a text field which breaks my send email button (because it references “recipient.email_address”. Yes, I could change all my logic to workaround this, but I shouldn’t have to.
So, there are many reasons as provided by the contributors to this post why this is just bad all round.
So please just get rid of it, or failing that provide a workspace-wide setting (preferably) to turn it off (or at the very least a per-doc setting to do it).
I’ve complained about this one as well. Coda acted like it wasn’t supposed to do that, but yet I don’t see it NOT doing it still.
When using tracking numbers. If it’s USPS it’s all digits. If UPS it has letters in those digits. So if my order tracking table has processed out all the UPS orders and all I have are USPS items, then my column gets changed AGAIN. So then my USPS number shows up like 923,900,234,234,234 which is also annoying. Thousand separators should NOT be the default. Many numbers are used for ID numbers, etc. and we don’t want comma separators in those. Yet I keep having to go fix things.
In the breaking case it changes the type to url and shows a small circle icon instead of the url text, now hiding all the string notes from everyone on the table. Unless someone knows, and has permission to change it back, it is ‘broken’ as far as all users experience.
We’re trying to balance the cases where it’s helpful to quickly start entering numbers or dates to a default blank table or new column without needing an additional step to set the right type, with cases where you’ve set up a deliberate structure and it’s important that types don’t change.
We clearly have more work to do to support the latter, and know there’s a need to better differentiate intent.
There’s some great ideas on this thread and the input’s helpful for us to consider the best approach.
We as makers, users and paying clients of this software are asking what are the reasons why Coda is changing data type and you are saying that for situations like when we have an empty table so that the user can enter a date in a text field then Coda can make it a date field.
Well, then tell me what takes more time.
Situation A when an user has a empty table and has to click twice to change data type or
Situation B when a maker/editor defines a table columns data type and locks them has to deal with an automation failing as the data type has changed outside the maker control.
Coda is the first software that does that to me… changing stuff behind my back as a maker.
And I am truly disappointed and unsatisfied.
If you sum up all threads that point to this failure of Coda then you will get hundreds of comments against what Coda is choosing currently to do.
I am afraid that Coda is somehow confused how who creates tables (columns) in Coda and who uses them. In my experience, most employees don’t like to touch tables, they use preformatted set ups and they have in most cases no intention to add a column and thus don’t need the provided hint. They have what I call: table fear. It is very common among employees, certainly in larger non tech companies and there is no real cure for it yet. What we do most is make sure that they are not exposed to that fear by making table views that work for them.
Today I was trying to avoid check boxes and I started typing a few options, but the hint logic blocked me, I wrote checked and gave an enter and the column became a checklist, the thing I really want to avoid for practical reasons.
I am a maker and the people using it are users, a clear distinction between these two groups would benefit both populations and a good start is to read again what @Cristian_Nichifor wrote.
This “first” concept is a problem for me. I and some of my clients want to keep some tables lean and mean so we archive out data. For example, tracking numbers. We want this table to be fast so things that have already been delivered are moved to another table. That means sometimes this table winds up empty again. Then that first shipment if it’s USPS all numeric fouls up everything again!
You could leave one row (hidden - filtered) in your table with all columns filled with data in a format that wil maintain the originally chosen type. As far as I know that works and is not complicated. Just make sure that calculations also filter this row out of the calculation.
