Adding a new field (column) error: You have exceeded the usage limits for this base

[Joya_Cousin]

I am trying to add the 501st field (column) to a table I use for planning work, and for more than one hour now I have been getting the message “An error has occurred: Sorry you have exceeded the usage limits for this base”. See screenshot

I am on a pro plan and nowhere near my record limit. This is frustrating because it is impeding time sensitive work.

Anyone have any idea how to solve this?

Sometimes I succeed in adding a few columns, but when I refresh the page as instructed in the error popup, the new columns disappear.

[ScottWorld]

Wow, that’s a limit that I didn’t know about. I can see that an Airtable employee has confirmed in another thread that there is a limit of 500 fields per table.

Having said that, what are you currently doing that requires 500 fields in a single table? There is probably a way to set up your system with multiple tables instead of a single table.

[Joya_Cousin]

OMG! Thanks for the comment. I really hope this is not true that there is a maximum of only 500 columns! :rage:

I am a portrait artist and I use this to schedule work for my clients - a column for every day, with a record for each artwork/contract. I have bookings months in advance and need to have more than a year of data active. I have tried to get it to work the other way around, but I need the flexibility of records to hold all the details relating to each artwork. So given the limitations of databases, it is not possible to put the artworks in fields instead.

I will have to try to adjust the records which depend on “live” data from this table and then try deleting some columns if this is the case. Disappointing!!! :sob: :sob: :sob:

[Bill_French]

Hi Joya, and welcome to the community!

Joya_Cousin:

a column for every day, with a record for each artwork/contract. I have bookings months in advance and need to have more than a year of data active.

Indeed, and this suggests you have a data modeling problem, not a field limit problem.

Joya_Cousin:

I need the flexibility of records to hold all the details relating to each artwork.

You are conflating business requirements with an implementation strategy. My recommendation is to clear your mind of everything related to HOW to store data and focus on precisely WHAT the requirements are. Focusing on what specifically your information solution should achieve will allow you (or @ScottWorld) to work backwards toward the most effective implementation that scales and is sustainable.

Joya_Cousin:

So given the limitations of databases, it is not possible to put the artworks in fields instead.

Firstly, there are very few limitations to what databases can do, and second, EVERYTHING must go into a field because data cannot be persisted any other way. Your comment suggests you are conflating the separate idea of tables, records and fields.

Joya_Cousin:

I have bookings months in advance and need to have more than a year of data active.

I have a client who has five years of advanced bookings in Airtable and more than 750 attributes for each booking. This is made possible by the data architecture behind the application which actually uses no more than 32 fields for any given table.

ScottWorld:

what are you currently doing that requires 500 fields in a single table? There is probably a way to set up your system with multiple tables instead of a single table.

This is precisely the compass-heading you need to adjust to. My sense is that given a close look at what you’ve designed and in context of clear business requirements, @ScottWorld will provide a far better approach that will avoid scrapping the system or succumbing to unreasonable compromises.

Joya_Cousin:

I am a portrait artist and I use this to schedule work for my clients

@ScottWorld is a “database artist” but I’ll bet he can’t paint portraits for sh*t. Just sayin’ – wink, wink. But both @ScottWorld and myself would probably be interested in seeing your art, so please share a link! :slightly_smiling_face:

[ScottWorld]

@Joya_Cousin

As @Bill.French has pointed out, you have not setup your database properly. You are misunderstanding the difference between tables, records, and fields. For example, you never want to have each field be a separate date. Each record can be a separate date, but never fields.

Airtable can easily & effortlessly handle everything you need to handle, but you need to completely restructure your entire system from the ground up.

If you have a budget for this project and you need to hire an expert Airtable consultant & developer to help you with this, feel free to send me a private message.

Otherwise, you’re going to need to start all over again from scratch. You need separate tables for each main element that you’re trying to track, and then you need to link those tables together. I don’t know what your system looks like, but at the very least, you will need one table for “Artwork” and one table for “Bookings”. You might need more tables than that as well.

@ScottWorld is a “database artist” but I’ll bet he can’t paint portraits for sh*t. Just sayin’ – wink, wink. But both @ScottWorld and myself would probably be interested in seeing your art, so please share a link! :slightly_smiling_face:

Haha, thank you, @Bill.French! :slightly_smiling_face: And yes, you are correct — my terrible 6th grade & 7th grade art teachers beat any artistic aspirations out of me for life, so I can absolutely NOT paint ANY portraits!! :cold_sweat:

I had to turn to the world of computers because I couldn’t turn to the world of art!! But luckily, as you suggested, I really do consider designing databases a form of artwork. :slightly_smiling_face:

[Joya_Cousin]

Thanks, Bill for your detailed critique. Indeed, although I have a degree in computer science, there’s no wonder I’ve never been paid to write a line of code! :joy: :joy: :joy:

The table I am using is primarily for managing all things related to each piece of art I create, whether it is a studio piece or something commissioned by a client. Each piece of art is a record with about 30 fields of non-date related fields. So there are things like the medium, material, size, price, total hours etc.

I also have a habit tracker that is formatted as you mentioned by having days as records, but I couldn’t get it to work for artworks because I need to link and summarize hourly data for each artwork, as I track my productivity by weeks and months since I started painting three years ago. I also have a time budget based on price for each commissioned piece. I need to monitor my use of that budgeted time as time goes by.

I switched over from using Excel spreadsheets for everything, and so it is obvious that the database has not been “designed”. Plus I have invested too much time, and don’t have enough time in the foreseeable future to start from scratch.

The quick fix workaround I decided on was to condense all the historical day fields into weeks by manually summing them up and deleting fields. After five years (or ~250 fields) I can store the summarized info on another table and then condense further into year fields, keeping the most recent data in weeks and the forward planning info as days, in order to stay within the 500 column limit.

If there was a way that I could enter the daily hours I plan on painting and the hours I actually spend painting on each piece and have it link into my primary artworks table that would be brilliant, but this is the first database I have used in the 20+ years since university, and I couldn’t figure out a way to get it done!

You can see more of my work at http://joyacousin.com/. I have only been at this professionally for a year, but thanks for asking! :art:

[Bill_French]

Joya_Cousin:

… don’t have enough time in the foreseeable future to start from scratch.

This is not an uncommon scenario, so you make do with what you can, and on the side, begin to shape a new model that can overcome the limitations.

There will come a time when you’ll realize - Wow! This can be much simpler. I predict it will come when you take advantage of a relational model that separates time (a flowing resource) from artefacts (a static resource). The issues abound when you create rows of data that mix these two very different elements.

Once they are separate and links are established, your time with Airtable will become somewhat enjoyable.

Joya_Cousin:

You can see more of my work at http://joyacousin.com/ . I have only been at this professionally for a year, but thanks for asking! :art:

And yet - “Grey Gaze” is absolutely amazing! This is obviously your true calling. I know a few art enthusiasts who I will share.

Out of curiosity, is there a price on Gray Gaze? My wife says I have no budget for fine art because I have no taste for fine art, but I’m curious none-the-less.

[Joya_Cousin]

You’re speaking Greek to me, Bill… I already love all the tables I have, this is the only one with a hiccup. Any concrete suggestions for accomplishing what I need would be appreciated, in the meantime, I will hobble along and focus on my day job. :tulip:

Grey Gaze is $1500, and you know what they say: “happy wife; happy life”!

[Bill_French]

Joya_Cousin:

Any concrete suggestions for accomplishing what I need would be appreciated

It’s really difficult to make advisements without seeing and fully understand the requirements to get to concrete steps. Lacking a deep dive means that pouring concrete falls onto you.

@ScottWorld has made a few that seem like the right path and my recommendation is that you must separate any data that is time-centric from any data that is artefact-centric which also follows @ScottWorld’s recommendation without seeing your system more intimately.

If you have records that represent things (like paintings) and records that represent time (like hours spent on each painting) - they must exist in separate tables and relational connections should be used to see each artefact and the time spent.

[ScottWorld]

Any concrete suggestions for accomplishing what I need would be appreciated

@Joya_Cousin:

@Bill.French has guided you in the right direction, and so have I, but you are not following our advice.

Again, to repeat one more time:
You need to setup different tables for different types of records.

Your data is currently horizontal (columns), and you will need to somehow make it vertical (rows).