Hi guys,
First I update the maximum length of a textbox field from 4000 to 3.
Then I created a new key for that specific field.
Initially, since it is a new key, I was able to import my solution successfully. But for some reason when I redeploy (meaning the key is already existing), I am having this error "Index size exceeded the size limit of 900 bytes. The key is too large. Try removing some columns or making the strings in string columns shorter." As a workaround I can just delete the key first in the 'target' environment then redeploy and its working for me. But this is not ideal as it would cause issues in some way or another.
Can you please provide your thoughts why this happening?
*This post is locked for comments
Hola,
Este error se genera por que depronto tienes una llave, clave, o regla de detección de duplicados que esta generando conflico, debes quitarla de la solución que estas importando, esto soluciona este error
Hi Joseph,
Note that it is not a bug in MS Dynamics 365 CE, but actually it is a limitation in SQL Server, described here: https://docs.microsoft.com/en-us/sql/sql-server/maximum-capacity-specifications-for-sql-server?view=sql-server-2017#-objects
There is no fix for this error message available in future releases, as this error is a documented limitation in SQL Server. As the error message suggests, the way to avoid this error is reduce the size of the key because it is too large. Try removing some columns or making the strings in string columns shorter (sum of total characters less than 450).
Thank you very much Joseph,
What I ended up doing is I managed to finally remove the key from production using the "Copy Solution" and "Stage for Upgrade" method on my solution that first introduced it.
Then I decided to go with a synchronous plugin that checks for duplicates on create and update of records.
I will use plugins for now until the Keys functionality feels more stable.
Kind regards,
Panos
Hello again,
When exporting the solution from the DEV environment, perform the following steps:
a. Unzip the solution to edit the customizations.xml file.
b. Open it in Notepad++ and find the technical name of the field on which the unique key is based.
c. Change the size of the XML field "Length " to double the XML field "Max length " (for the field in question)
d. Save and Rezip the file and import it into the target environment.
e. You will need to redo the same manipulation upon each export until the Microsoft bug is resolved.
This solution has been suggested by Microsoft's support as a temporary solution.
Microsoft acknowledges the bug and will fix it in the following releases.
Regards,
Joseph
Hello guys,
I am experiencing the same issue.
Did anyone find a solution to the problem?
I actually added a key to the solution and deployed on Production.
Then in the next deployment, the solution is failing to import due to the following error: "Index size exceeded the size limit of 900 bytes. The key is too large. Try removing some columns or making the strings in string columns shorter."
Thanks in advance!
Joseph
Hello JZ,
Did you ever solve this?
We have a deployment process that allows me to only publish managed solutions in our live environment.
When I first imported the solution update patch which included this key, the solution was published successfully.
Now I'm trying to publish a big update (cloning the solution) and I can't get past this issue exactly because of this alternate key I introduced earlier.
I've tried:
1. Reducing the field size from 450 characters to 200 characters on DEV and then import to Live.
2. Removing the key altogether from DEV and then import to Live.
3. Reducing the field size on Live (yes I had to override our internal process) and then import from DEV.
4. Deleting the key altogether from Live (wasn't allowed as I'm getting an error stating that the component is managed which is expected).
I can't easily uninstall from Live the patch that introduced the key in the first place as it also included some new fields and processes that will lead to data loss.
Any ideas of how to get past this?
Many thanks,
Panos
Hi Thomas,
Thanks for reply again!
Yes you are correct. It is a custom single text field in a custom entity. Initially it was set to 4000 for some reason and I changed it to 3 then created a new key.
When I imported it initially in target environment it was successfully imported. But when I tried to reimport again (key already existing), the import error occured.
Do you know how can I fix this? Thanks!
Hi.
Same restriction (max. length of characters in an index) applies for alternate keys:
docs.microsoft.com/.../define-alternate-keys-entity
Alternative keys are supported for following field types:
- decimal
- whole number
- single line of text
I just wonder, since you wrote you changed the length of this field from 4000 to 3, if this is really a single line of text field?
Is this a custom field, created by you, or a default field?
Because I also experienced the fact, that some of the default fields, that exist since the earliest CRM version (e.g. Address fields) does not change from 4000 characters on database level, even though you reduce the number of characters.
Hth Thomas
Hi Thomas,
Thanks for your reply.
No the field mentioned above was not part of the find column of the quick find view. I just created a key for it.
Let me know if you have any other thoughts on this.
Thank you again for your help.
Is your field a find column in the quick find view?
If yes, that's the reason. Because for find columns automatically an index is being created and there are limitations reg. the max. number of characters.
This is a limitation on sql side.
docs.microsoft.com/.../maximum-capacity-specifications-for-sql-server
And since you mentioned you changed it from 4000 to 3, I assume this is a multiple lines of text field. That field will always consume 4000 characters in the db, although you set it to 3 characters (which only does validation that no more than 3 characters can be entered).
Hth Thomas
Stay up to date on forum activity by subscribing. You can also customize your in-app and email Notification settings across all subscriptions.
André Arnaud de Cal... 291,253 Super User 2024 Season 2
Martin Dráb 230,188 Most Valuable Professional
nmaenpaa 101,156