9

Is it possible to change a field's Data Type without removing all references to it in controllers and classes?

I'm considering changing a Rich Text Area to a Long Text Area.

I'm receiving the following warning in the UI when trying to change it now:

"Cannot change field type of a custom field referenced in Apex class or trigger: myController".
Improve this question

3 Answers 3

Reset to default
14

I don't think there's any easy way to change a field that is being referenced in an apex class or trigger. There are two ways to get this done that I know of. Assuming you're working primarily in a sandbox:

  1. Comment out all the lines with that field in it in all classes and triggers.
  2. Modify the field.
  3. Deploy all the changed code and metadata to production
  4. Uncomment all those lines of code
  5. Deploy all the changed code to production

or

  1. Make a new field with a new name.
  2. Change every reference in your code to that new field.
  3. Deploy changed code and new metadata to production
  4. Move over any data from the old field to the new field
Improve this answer
2
  • Yeah I guessed these two would be the simplest options, cheers Jeremy. I was hoping for a magical 'Make this field changeable' checkbox somewhere... but we can't always get what we want!
    – Daft
    Commented Oct 8, 2014 at 12:44
  • 13
    Both options fill me with sadness and dread.
    – Robs
    Commented Jul 29, 2018 at 20:59
4

You could try to retrieve the object and all classes, triggers, vf pages components... with the metadata API by using the Eclipse or ant plugin. Then you are able to duplicate the field at the xml file of the object and replace the fieldname at all referencing entities. Finally you need to add the new field to the package.xml file.

After deploying the metadata back to the Org, you should be able to delete the original field.

A second round trip is needed, if the field should have the same API name as before.

Improve this answer
1

I know this is old, but if anyone needs answer, I would do what @Jeremy Nottingham says with one slight difference.

I would submit my change set to production without any changes, then revise my triggers and submit a revised change set. This way I could remove the trigger on the field, change the field and then put it back with the original change set with minimum time.

I am in an org where people may need access any time during the day including weekends. Some triggers being down could cause issues no matter when I did the change.

Improve this answer

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .