I’ve had a Notes Field in my GLide App for years that did not have a size or character limit, then this morning I went to add a note and I get this error.
What is causing this? It’s a Notes Field there is no limit in the details.
Do you have empty spaces or line break?
1 Like
I’ll check. Stand by.
1 Like
I’m cutting and pasting an email. So yes, there are line breaks for sure. No empty line breaks at the top or bottom though. If I paste it as plain text I get the same error.
Is it possible that your text is very large? There’s a 1MB database cell limit which is about one million characters.
Digging through the code that triggers that warning, it appears that the limit is 2500 bytes. Not characters, but bytes. Normal characters are just a single byte each, but something like an emoji character is actually several bytes. So yeah, it’s actually quite a small limit.
2 Likes
I’ve been adding long email threads to this field for three years - far more than 2500 bytes and this error just showed up yesterday. Is this a new limitation?
It seems so.
Are you running the latest version of the builder? Can you try again? I’m curious if they lifted that limit now because I’m not running into it at the moment.
I just pasted a lot of things in, it’s fine for me. I tested the byte count and mine was over 100k.
2 Likes
I actually noticed this behavior two days ago, but it doesn’t seem to appear again today… hehe. You probably know where it came from?
This became an issue Friday, two days ago, as well. I could not update any fields. I was going to come in here today and rework my system. I feel I was going to create multiple dated rows instead of appending to singular cell. I have been appending data to a single row for almost 4 years now. So this change was a shock. Does anyone know what might have caused this?
I believe you’re right. It looks like this was a temporary bug. I have no problem cutting and pasting large text again.
3 Likes
Can you share your use case on why you need to append data to a single cell?
Let me preface this with I am not a software designer, I manage a small auto repair shop, and we use this app as a customer resource management, appointment tracking, vehicles owned, maintenance provided/ point of sale system. It has ballooned over the years from originally appointment tracking to now it does everything but order and look up parts. There is a table called vehicles; each vehicle no matter the owner has it’s own row. Columns consist of lookups and relations from other tables, i.e. appointments, contacts, quotes, etc. As well as vehicle specifics and a historical maintenance column. That maintenance column is appended from the vehicle’s edit screen after any maintenance is performed. Updates are dated and included any and all mechanic notes. There are approximately 1600 rows and 25 or so columns in this table. We perform approximately 5 -10 repairs/record updates a day. I know this method is not ideal, until recently, last Friday, I never even thought of the character count. I am aware I will have to potential develop a more sound system. Let me know if this is enough information. Thanks Will
Hi, thanks for the detailed response.
I assume this is what you have at the moment:
Table: VEHICLES
This table is doing the heavy lifting for the whole shop.
-
Column: Vehicle_ID (Unique identifier)
-
Column: Owner (Relation to Contacts table)
-
Column: Make
-
Column: Model
-
Column: Year
-
Column: VIN
-
Column: Appointments (Relation to Appointments table)
-
Column: Quotes (Relation to Quotes table)
-
Column: Maintenance_History (
The Problem Area : A “Long Text” field where dates, mechanic notes, and repairs are pasted one after another)
Why this broke:
Though this has been resolved, the problem with “appending” here is ultimately you have a lot of text in one cell. By “appending,” you are treating a database field like a Microsoft Word document. Eventually, the file gets too full. Furthermore, you cannot run reports on this. You cannot ask the app, “Show me all cars that had brake pads changed in 2023,” because that data is buried inside a paragraph of text.
To fix this, we need to stop appending text and start adding rows. We need to take that Maintenance_History column, chop it off, and turn it into its own table.
This concept is called a “One-to-Many” relationship .
-
One Vehicle…
-
Has Many Service Records.
Here is the proposed design. This will likely require you to create one new Table in your app platform.
1. Table: VEHICLES (Cleaned Up)
Keep the car data, but remove the history blob.
-
Vehicle_ID (Key)
-
Owner (Link to Contacts)
-
Vehicle Details (VIN, Make, Model, License Plate, Mileage)
-
Legacy_History_Archive (
Action: Rename your old “Maintenance History” column to this. Make it Read-Only . Keep it for reference, but stop typing in it.)
2. Table: SERVICE_LOGS (New Table!)
Instead of editing the car, the mechanic creates a new row in this table.
-
Service_ID (rowID for this specific job)
-
Date (Date of repair)
-
Vehicle_Link (Relation: Matches the Vehicle_ID from the table above)
-
Mechanic_Name (Who did the work)
-
Service_Type (Dropdown: e.g., Oil Change, Brakes, Engine, Tires, Inspection)
-
Mechanic_Notes (Text: “Customer reported squeaking. Replaced pads/rotors.”)
-
Cost (Number: optional, if you track financials here)
-
Odometer_Reading (Number: Mileage at time of service)
Part 3: How this changes your workflow
The Old Way (The Crash):
-
Open Vehicle.
-
Click Edit.
-
Scroll to the bottom of a massive text block.
-
Type “1/28/25 - Fixed Brakes.”
-
Save.
The New Way (Scalable):
-
Open Vehicle.
-
Look for a list/grid labeled “Service History” (This displays the rows from the new Service_Logs table).
-
Click “Add New Record” (or “+”).
-
A blank form pops up.
-
Select Date, Type “Fixed Brakes,” Enter Mileage.
-
Save.
Thank you for detailed response your self. I appreciate all the input. The illustrations are great. You hit really close to how I was going to approach this. You are missing a small part of the equation that I did not include. Our appointment table is where we initially type all work done and then this data is manually copied to the history filed of that vehicle. So in essence the vehicle table’s only heavy lifting is the history column. But I digress, after appointments are completed we usually just delete the appointment. The reason was because most appointments contained pictures and videos we took during the work. This was so we could share what we saw visually with the customer. Well in order to save on disk quotas we would just copy the vehicle update text and date into the above mentioned field and then delete appointment. So back to my potential solution, we will still use the appointment screen with notes and photos and videos if needed. Instead of manually copying notes, I will change behavior of delete button. When pressed it will provide a modal asking which vehicle this appointment applies with a button selection for that customer’s list of vehicles. After proper vehicle is selected the repair date, original complaint, and repair notes will be written to a new table and linked to that vehicle. My only limitations I can see with this are ability to quickly see complete history notes. However, I am sure I will think of something. The original appointment will then be deleted. The only reason to have the vehicles selected at the end is because a lot of the times when we create appointments for customers over the phone, they do not know all of the vehicle data, and we don’t get to update that information until we get the vehicle. Again, I truly appreciate your input, it does provide good insight and I am sure I will incorporate some of it.
1 Like
This topic was automatically closed 7 days after the last reply. New replies are no longer allowed.