Apex Code Development You need to sign in to do that
Don't have an account?
gtuerk Fields 'recreated' during deployment, duplicated field ids
Hoping someone can point me in the right direction on a seemingly ongoing problem. The first one I have not seen before but seems related to the other issue. Here's what we're seeing:
We added a few fields to one of our Custom Objects in one of our Development sandboxes and replicated that (i.e. did not deploy but instead recreated the field) in our Production environment. This is a typical pattern we employ when we have extended development cycles and a quick field needs to be added. When we did the deployment this time, the field was eliminated from Salesforce and recreated - thereby losing all the data in that field. There were no differences between the field's label, field name and/or API name so we would not have expected it to be deleted, yet it was. Has anyone experienced this before?
The other problem, which we have seen a number of times, is that we sometimes have two fields with the same field ID value. We have a (n anti)pattern in place that uses Query String parameters to pass fields from one Custom Object to another to preset the layout of the new object with values from the other object without being persistent (i.e. we don't save the record until the user explicitly does so). More than once, the field ids of two different fields have the same ID. This makes the field copy not work. These seem related to the above but was hoping to better understand how these field ids are allocated during the deployment process to guard against these errors.
thanks in advance
The only way to delete a field using the Metadata API is by explicitly listing its API name in "destructiveChanges.xml" (same format as package.xml) and including that file in your deployment.
The Metadata API uses the field's API name as the primary key, so if you created the field separately in both organizations but used the same API name, when you migrate your schema from one organization to the other it will apply the settings for that field from the sandbox to production (as you intended). But unless you use destructiveChanges.xml, it will not delete and recreate the field--it will treat the changes as an update.
Note that if you change a field's API name in one place, there's no way to propagate that change to another because it changes the primary key. But if this had happened, the result would be that a new field would be created, not that your old field would be deleted. Based on what you described, this scenario doesn't apply (but it seemed useful to mention).
Is it possible that, rather than the field being deleted, you migrated profile permissions from your sandbox that were incorrect for production, and the result is that end users can no longer see the field or its data?
Jon
salesforce.com Product Manager