Value for field 'someCustomField' exceeds max length

[Michael_Langell]

Hi everyone,

I have actually seen this field type before, and I think you will only see it with SFDC custom fields.  It is the default field type when a custom field is created in Marketo by Salesforce with a text type.  The SFDC text type could be text or text area.  Marketo does not differentiate the SFDC field type and just labels both as text.  Just looked in my instance to confirm this.

So that is why you would get errors with some text fields above 255 and others will be fine.  Depends on what the field type in SFDC and the associated character limit is.      

Custom Field Types 

However, I cannot answer why this would be giving you more issues now.

-Mike

[Anonymous]

Thanks for the reply! Syncing from Salesforce seems to bea commonality between the clients I am seeing this problem with. I have clients that have custom fields they created in Salesforce (with the __c suffix) and clients that have fields without that suffix that they must have created in Marketo but all impacted clients have at least some fields syncing from Salesforce. It's possible Marketo started doing a check on the field length in Salesforce recently and rejecting data that will not fit that.

[Anonymous]

We have checked with some of our client and they have the fields syncing to Text Area (Long) fields in Salesforce which have a default limit of 32,768 characters. We are seeing fields of much fewer characters than this still fail when being pushed to the synced Marketo field.

[SanfordWhiteman]

"text" has long been the API type for textarea (which in turn is the Mkto type for longtext).

What we have now is a much more significant bug than just aligning names (which would still be a regression). This is creating a whole new API type in Marketo: text(n). Is this correctly aligning lengths that were previously ignored in Mkto? Maybe, but that says nothing about truncating existing values, nor why string(n) isn't being used. It's going to require a audit of all fields to know what's "right."

[SanfordWhiteman]

To give what should be a clear example, billingStreet previously had the API type text with no length value, interpreted as a TEXT = CLOB = NVARCHAR(MAX) at a database level (NVARCHAR(32000) or NVARCHAR(64000) would suffice given domain knowledge, but that precision is not necessary and doesn't change the problem).

In contrast, billingCity previously had the API type string(255), mapped to NVARCHAR(255).

With the recent release, the API type for billingStreet changed to text(2000). This was not previously a possible type.  Since lengths were not previously included, text was assumed to use the platform's max # of storage bytes typically 2 GB (data length being approx. half of that).  When a length is suddenly specified, it appears that the column is being destructively truncated from 2GB storage/1GB data to 2000 bytes data.  This kills any integration that dynamically synchronizes Marketo and SQL.  Truncating the column (even if there is no current value > 2000 bytes) appears to be a destructive act.

Kenny Elkington​

[Anonymous]

I don't use Salesforce.

[Anonymous]

Looking into this further it is impacting all Marketo clients. Fields that used to accept more than 2k characters now all have a limit of 2k as of the 6/3 release.

[SanfordWhiteman]

Yes, this is causing us major concern.  Like I said we don't even have a clear picture about whether data is/can be truncated.  Someone from Mkto needs to get on this, stat.

ETA: I opened a case via one of my clients.  Advise everyone affected to do the same.

[Michael_Langell]

FYI all,

I actually got the below response on 7/12, but figured I would send to you all as well.  The issue should be fixed now.  Let me know if any of you are still experiencing problems. 

This has been resolved by our engineers. A patch was developed and released on Friday. Please let me know if this is still an issue for you or if the patch resolved it.

-Mike 

[Anonymous]

Thank you for sharing. I have confirmed this in testing.