Skip to main content

I have noticed that when I add custom columns to SQL Server (I know not officially supported, but it’s for testing purposes), that when an Acumatica upgrade is done, these custom columns are dropped. It’s not a huge deal (that’s why we do RDS SQL Server backups before upgrade), but it seems a little counterintuitive that a drop operation is run on a column that the system doesn’t know about. This is probably the result of a complete table drop and refresh as part of the upgrade process.

Does anyone have any strategies for seamlessly moving over custom columns when an upgrade is run? I like the ability to manage the table structure at the SQL Server level, so if there is some way to do that which also plays nice with the Acumatica framework, that would be the best of both worlds...

to avoid these drops your custom fields need to be prefixed with usr, e.g. usrCustomField.

Fields without usr prefixes will be dropped during upgrades if they are part of the core tables.

What I mean by this is, if you create a custom table, that table is not affected by upgrades and its fields can be anything


Ok thanks Shawn. So it seems that if I prefix the column name with usr, that should solve my problem, regardless of how I create the column, correct?


@ShawnBurt05 oops, sorry.  I meant to make your answer the “Best Answer”, not mine. Maybe the mods can fix that when they get a chance.


that is correct. even is you are not using “standard” processes to modify the tables, the prefix will protect your changes when upgrades occur.


Hi @rosenjon  - best answer fixed 😀


Reply