I have an entity with a text column that is 50 characters long, and I need to increase its length to 100 characters.
My application runs across multiple environments for several customers, using both SQL Server and Oracle databases. In some customer environments, this entity may contain many millions of records.
There is an index on this column.
What I need to know is whether there is any risk that the deployment could fail due to a timeout when altering the column length.
Yes, there can be a timeout risk, but it depends on:
OutSystems will generate an ALTER TABLE to change the column length. If that change forces data movement or index rebuilds on a table with millions of rows, the operation can run for a long time and potentially hit a timeout.
ALTER TABLE
You already have two important risk factors:
On very large tables, changing the length of an indexed text column may cause:
The article you shared about timeouts when adding attributes describes exactly this kind of situation: operations that need to touch all rows in huge tables may time out during the “Update Database” phase of deployment in older Platform Server versions Application deployment takes too long after adding a new Entity Attribute.
There’s also a forum example where an ALTER TABLE failed because a previous operation left the table locked, and the second ALTER TABLE timed out during publish ALTER TABLE issue while publishing OSP.
So from an OutSystems perspective:
VARCHAR
NVARCHAR
VARCHAR2
CLOB
Your specific change (50 → 100 chars) is relatively small, but with millions of rows and an index, it can still be heavy.
Higher risk of timeout if:
Lower risk if:
To reduce the chance of deployment failure due to timeout:
Check Platform Server version on each customer environment
Increase timeout settings (self-managed)
Plan the change during low-usage / maintenance windows
Validate in a representative staging environment
I cannot say for Oracle, but in SQL Server, I haven't seen timeouts when resizing an attribute, even with millions of records.
Adding the “why” behind Kilian’s experience:
SQL Server: NVARCHAR(50) to NVARCHAR(100) is a metadata-only change. Existing rows aren’t rewritten, so it finishes almost instantly regardless of row count. It’s also allowed on an indexed column when the type stays the same, the size grows, and the index isn’t the primary key (see ALTER TABLE … ALTER COLUMN in the SQL Server docs). The index isn’t rebuilt.
Oracle: increasing a VARCHAR2 length is also a data-dictionary change. Existing rows and the index aren’t touched.
The real risk is the lock, not the duration. The ALTER needs a schema-modification lock, so it waits behind any open transaction or long query on that table, and new queries queue behind it. That is what makes a deploy look stuck or time out on a busy table. So:
Shrinking the column (100 → 50) would be a different story, because existing data would have to be checked.
In my experience shrinking is often not possible from OutSystems, even if there are no strings that exceed the limit.