function readOnly(count){ }
Starting November 20, the site will be set to read-only. On December 4, 2023,
forum discussions will move to the Trailblazer Community.
+ Start a Discussion
EJWEJW 

Winter 16 Bug - Can't save new record for custom object - Internal Server Error

We've tested this in multiple Winter '16 orgs and all fail when attempting to insert a record for a particular custom object.  The object belongs to a managed package we develop (DupeBlocker) and both inserts and upserts fail regardless of the method used.  So far we've tested with the standard UI, a VF page and Apex Code and all fail with an unknown error.  The error from the standard UI new record screen (/<object key>/e) is:
 
An internal server error has occurred

An error has occurred while processing your request. The salesforce.com support team has been notified of the problem. If you believe you have additional information that may be of help in reproducing or correcting the error, please contact Salesforce Support. Please indicate the URL of the page you were requesting, any error id shown on this page as well as any other related information. We apologize for the inconvenience. 

Thank you again for your patience and assistance. And thanks for using salesforce.com! 

Error ID: 80356973-33047 (-1924346448)

Repro steps in that org are to go to the new/edit page (https://gs0.salesforce.com/a02/e in this particular org), enter data and click save.  We have another custom object that is very similar that saves without issue.  This also saves without issue in the current SFDC release.

When saving via apex code (creating an object and inserting or upserting it) there is just an unknown exception.  However, if we try to upsert the record via our VF page, it returns an oracle error:
 
08:37:42.507 (507136905)|EXCEPTION_THROWN|[162]|System.DmlException: Upsert failed. First exception on row 0; first error: UNKNOWN_EXCEPTION, An unknown exception has occurred.: []
08:37:42.510 (510281425)|VF_PAGE_MESSAGE|ORA-20070: 
ORA-06512: at "SLEEPY.SCHEMA", line 52
ORA-06512: at "SLEEPY.CAUTONUMBER", line 621
ORA-06512: at "SLEEPY.CAUTONUMBER", line 638
ORA-06512: at "SLEEPY.CAUTONUMBER", line 653
ORA-06512: at "SLEEPY.CAUTONUMBER", line 678
ORA-06512: at "SLEEPY.CCUSTOMENTITYDATATEMPLATE", line 1394
ORA-06512: at line 1


{call cCustomEntityDataTemplate.insert_custentdatas(?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?)}

{call cCustomEntityDataTemplate.insert_custentdatas(?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?)}

I've opened a partner support case, #12543200, but this is a critical issue as this will affect a large number of customers with DupeBlocker installed if it's not resolved before Winter '16 is released.
Yaswanth KothapalliYaswanth Kothapalli
As this is the Error ID: 80356973-33047 (-1924346448), salesforce support can help you more by checking the backend logs based on the id.
 
EJWEJW
Thanks, I'm aware that's the Error ID and that info is in the case, I posted the issue here as well in hopes that I might get a resolution quicker than going through standard support.  Support did respond and create a known issue for this bug: https://success.salesforce.com/issues_view?id=a1p30000000m5UZAAY 

The cause of the exception is very specific, basically having the word "merge" in the display format of an auto-number name field for a custom object causes the error.  You can work-around the issue by changing the display format so that merge is "mrg" or any other string.  However, this workaround doesn't work for us as this is included in a managed package installed in a large number of customer orgs and they can't modify the display format.

We can update our package to change the display format and push out an upgrade, but that wouldn't fix existing records so editing those would continue to fail.  There isn't a way to fix that data in a customer org with a managed package as the suggested way to do that is to change a field's type to text, update the values, then change it back to auto-number, but that can't be done in a customer org as they can't change the field type.  If we have to go that route we'd likely have to add an upgrade process to clone the existing records into new records to re-create the record name with the new format, then delete the old records.  However, I would very much like to avoid modifying customer data as part of a pushed upgrade, even if the data is config data related to the managed package.

I couldn't get support to offer an ETA for the fix or even state whether or not they plan on trying to fix this before Winter '16 is released.  They simply pointed me to the workaround and closed the case after apologizing for not being able to do more, even though I explained to them that the workaround won't work in this situation and a large number of customers will be impacted by this issue if it's not fixed before Winter '16 goes live.

I'm trying alternate routes for getting a resolution to this issue, posting to this board being one of them.