I am running into an issue when adding a new field to an entity. In my entity I had 526 fields, I tried to add a new one but I got the error message "Attribute xxx cannot be created because we have hit a maximum number of attributes allowed for an entity (1000)". However I only have 526 fields in the entity. Furthermore, I deleted one field I don't need anymore and I tried to add my new field but I still have the same error message even though I've deleted one field. Could anyone help me out please. I do appreciate it. Thanks !
Walloud
You will be hitting the column limit, even with only 526 fields.
You have to remember that CRM will add its own fields in addition to the ones that you have, such as ones for base currency. This can take you over the limit.
Also consider that the Filtered Views that CRM automatically creates have extra columns for lookup (name), optionset (name) and date (local) fields which can also mean you exceed the limit there.
I think your only options are to delete more fields in order to free up the room, or re-architect your entity design to split it over multiple related entities instead
Looks like you are facing the SQL Server 8k row limit
you can check the field names and verify this.
more information here:
http://mileyja.blogspot.com/2013/09/dealing-with-8k-sql-server-row-limits.html
You need to remember that some fields, such as currency will have two separate fields in SQL thus increment the column count by two for each one you create. If you have 500+ fields on a single entity then it is time to normalize the data and start breaking it out into related entities. It will be better for performance and your data in the long run.
http://en.wikipedia.org/wiki/Database_normalization
Cheers!
Related
I have a situation where I have imported a bulk file of the Account and Contact records into CRM 13, and duplicate detection has kicked back a lot of the info for Contacts as failed because of duplicate data that ties back to the Account record.
Here are the steps I took:
For my accounts record I removed dupes in Excel based off two fields, and it removed about 500 records from thousands. I then imported the CSV file as is, into CRM 13
Out of those 500, there could be unique records that I need to try and import into the CRM.
I need to re-import the data into the CRM from an older file than the one I originally imported, and have the 500 records that were dropped added to the CRM. But I don't have the time to dig through a few thousand rows of data and pick out each unique row of data and I don't want the CRM to re-add the entire Account record a second time to the system, giving me dupes in the CRM.
Is there a way (without using a dynamic form, as they aren't working on the MS hosted CRMs, at the moment) to re-import the entire form, with the dropped unique records to the CRM and only add the unique data, and ignore the existing data?
I hope this makes sense. I can try to clarify, if need be. Thanks for any help you guys can provide.
You could do an export of the records from CRM, then use VLOOKUP in Excel to compare the difference in records, then import the difference to CRM again.
The issue seems to be related to the fact that whichever column you are using to match the account to the contact, there are multiple account records that match the criteria.
What I would suggest is ensuring that whatever you are using to identify account, that each value cannot resolve to more than one record. You could create a data map that resolves the account by something unique like account number.
Look at step #6 in the following example: https://www.powerobjects.com/blog/2011/12/15/importing-lookup-values-using-crm-2011-data-import-wizard/
We wanted to tweak the options of the Lead Source field in the Leads entity. We removed the existing items by deleting them. And added in new items. This has caused all the records to get updated with new Lead Source items. There is a lot of mismatch between the old values and the new ones.
I am guessing the 'Value' field for the 'Lead Source' set references the 'Lead Source' field in the Leads entity. When the item corresponding to that value changed, the referenced record automatically got updated.
Do we have a way to recover the old items and replace them to their original state?
I want an easier way out so I don't have to ask my DBA to roll back changes to the CRM database.
Help appreciated!!
If you have a solution that contains Lead you could import the solution and overwrite the customizations.
If you do not have a recent solution containing the Lead entity you could export a solution from another CRM organization, import the solution, and then re-do the customizations to Lead.
You could also manually copy all the Lead Source option set values from another CRM organization.
There are only 10 so it is a 5 minute job.
These are the options, values start from 1 and proceed to 10:
I am building a search engine, and have a not so unique ID for a lot of different names... So, for example, there could be an id of B0051QVF7A which would have multiple names like "Kindle" "Amazon Kindle" "Amazon Kindle 3G" "Kindle Ebook Reader" "New Kindle" etc.
The problem, and question i have, is that i am trying to enter this data from a DB of 11 ish million rows. each is being read one at a time. So i dont have all the names of each ID. I am adding new documents to the list each time.
What i am trying to find out is how do i add names to an existing Document? if i am reading documentation correctly, it seems to overwrite the whole document, not add extra info to the field... i just want to add an extra name to the document multivalue field...
I know this could cause some weird and wonderful "issues" if a name is removed (in the example above, "New Kindle" could be removed when a newer Kindle gets released) but i am thinking of recreating the index every now and again, to clear out issues like that (once a month or so. Its taking about 45min currently to create the index).
So, how do you add a value to a multivalue field in solr for an existing document?
Since according to the question linked to by #Mauricio Scheffer's comment... Solr does not currently support updating a single field value in an existing document. I see that there might be a couple of options here...
In your process that is pulling data from the database, when it finds a new name, it will need to pull all fields for the existing document from Solr, add the new value and resend the complete document to Solr (you may already be doing this).
Add some additional logic to your code that reads from the database, to gather all of the unique names for each document prior to inserting documents into the index. However, given that you have ~11 million records, there could be a resource constraint that would prevent this from being feasible.
Setup:
I have two lists on a SharePoint site, A and B. List A has a column 'b' that is a lookup to the ID field of list B. I have 500k+ records in A and about 6k records in B.
What works:
I am able to execute a query for items in list A using SharePoint web services, and am even able to filter the query based on a specific "lookup" value for column 'b'. For example, I can query for items in A whose column b matches 1234 (...<Value Type="Lookup">1234</Value>...), and so on.
What doesn't work:
The query does not work for items older than a specific date, even though my query does not involve dates in any way -- only the lookup column. Any query on data newer than two years old works fine, anything older than that fails. If I view items from the SharePoint web page they appear ok, and all the links from child records in B to parent records in A work just fine -- the lookup columns appear intact.
Question:
Is there some kind of maintenance task in SharePoint that can cause some underlying data to get corrupted that can prevent a query based on a lookup id to stop working, like a system restore, etc? In other words, the lookup column data appears correct on the surface in the web browser. But does SharePoint represent this value with a GUID or other invisible data that might be out of sync or stale?
Thanks.
Maybe you are hitting another limit; the maximum number of items retrieved in a query?
See list throttling
Try querying by the ID by adding the LookupId=”TRUE” attribute to your FieldRef element.
http://abstractspaces.wordpress.com/2008/05/05/caml-query-lookup-field-by-id-not-by-value/
The problem appears to be related to the fact that the column in question was indexed. When I removed the index everything started working. When I reapplied the index, everything kept on working. I'm attributing this problem to a corrupt index.
I got a question about the behavior of lookup fields when importing data. I wonder how the lookup fields behave when the list they point to is being replaced/imported. To explain the issue, I will provide a quick example below:
As example, assume we have these two sharepoint lists:
Product Types
-------------
+ Type Name
+ Code Nr
+ etc
Products
--------
+ Product Name
+ Product Type (Lookup field to list "Product Types")
+ etc
In my scenario, the Products List contains production data on the production Sharepoint platform. It is filled with data by the business users.
However the Product Types list contains rather static data and is maintained by the developer.
Now after a development cycle, the developer wants to deploy his new webparts and his new data (product types list). The developer performs the following procedure:
On the dev machine: Export "product type" list using stsadm
On the production machine: Delete all items in the "product type" list
On the production machine: Import the "product type" list using stsadm
This means we basically replace the "product type" list on the production server while keeping the "product" list as it is.
Now the question:
Is this safe? Will the lookup references break under certain circumstances?
Any downside of this import/export procedure?
What happens if someone accesses a "product" during the import? Will the (now invalid) reference clear its own content (become a null value).
What happens if the schema of the "product type" list changes (new column)? Will this cause any troubles?
Thanks for all feedback and suggestions!
Update 1
The imported "product type" items have the same IDs as previously deleted ones.
Update 2
Started a bounty to get some more feedback/opinions.
We have had this exact same scenario before. This is a little tricky, depending upon how you will approach it.
1) Delete and Recreate Product Type list through UI
If you delete and recreate the lookup List(Product Type in your case) through UI, then you will lose the connections because the List's id GUID will change upon recreation. So do not go that route.
2) Delete and Recreate Product Type through a Feature
If you had created the Product Type list through a feature.xml file using the <ListInstance> element, then if you delete that list and then recreate it using the same feature (basically Id attribute of ListInstance remains the same, number of list items, i.e. the number of <Row> elements, may change), the association would be maintained. So if you were adding 5 more product types, then if you had created the list using a feature, you could just delete the list and provision the new one using the same feature with extra info for new items and everything would just work!
As a side note, this is the better approach because if you have to do the upgrade on a lot of servers, then rather than doing list export import via stsadm, feature deactivation and activation is a much more recommended solution. This is how we did it.
3)Deleting all list items from Product Type and adding new ones (list is never deleted)
If you are linking the lookup field (in Product List) to the ID field of the lookup list(Product Type), you have to remember that ID is auto-incrementing, so if you delete all items and then add new ones, then their ID's would be different. Say you had 5 items with ID's (ID field is not shown in UI while editing in Datasheet view) 1-5 in the list. If you delete them and add new items, their ID's would start from 6 and not 1 again. So if your lookup field had link to the item with ID 1 in it, then this method is not going to work because there is no item with ID 1 in the Product Type list anymore. So you might want to really try this out before going to production with this method.
4) Editing the list in place
If the list is not extraordinarily huge, and you only have to make this change to one or two instances, could you not just edit the list directly in the datasheet view on the prod server? When editing in datasheet view, do not delete the item, but just overwrite the values of its columns. And you can add more items if you want. This will make sure your ID's are valid.
I have mostly talked about adding new items to the list. Now if you were deleting existing items, then your lookup fields will be affected because assuming you linked the field by ID, the ID is not present anymore since the item has been deleted. Basically, any method you use, maintaining your ID's is critical.
Now regarding your doubts/questions:
I am not too sure about stsadm export import for a list (never done it myself), but stsadm can be tricky as some operations will work on certain scopes only. So you better try out your exact scenario on a dev env.
What happens during an import is tricky again depending on the exact timing. I am sure SP has its own concurrency mechanisms, but you cannot have a definitive answer as it might probably be different based on the stage of the import. If possible, recommended approach is to do the import during a planned downtime.
Regarding changing schema of the list, a change in the schema of a list will not affect the existing list instances (for the most part). If you do this through UI, I believe SP makes changes to the content DB directly. I am not certain how you intend to do this, but if you were to add a column to an existing list using a feature, the way to do this is during feature activation by adding a new content type to the list and adding your new column to this content type. This way you add the column but do not affect the existing list items.
Good luck...
There are two components to a particular lookup: the field, and the field value. The field value only contains the ID of the item(s) it refers to, and the display field. This information is meaningless without the field, which specifies what list to look at and what field to use as the display field.
The primary reason that a Lookup will break occurs on the field scope: either the list it referred to no longer exists, or the list does not contain the required field. These would generally happen if you deleted and recreated the list, but you aren't doing that. If you do break a lookup's list reference, then the only thing you can do is re-create the lookup, because you cannot configure the list reference for a lookup field once it is created.
The downside of your import/export procedure is that you lose the validity of all currently existing lookup values. A lookup maintains its integrity based on the ID of the item it references. So when the display field changes, it still refers to the same item. If you delete the item, then the lookup no longer references it, even if you create a new item that has the same value for the display field. So you would have to reassign all of the products to the new product types.
It should be noted that if you were to revert the deletion of that item, it would return to being on the lookup! The reference to that ID is kept until the actual lookup value is updated (such as by editing the Product).
All of your now invalid references will be null for purposes of interaction. You won't see anything on display forms, and you won't have the options when you try to update the product. When you do update the product, you update it to what you just set it to, which since you can't set the non-existent IDs, means that there are no more references to those IDs.
Any changes to the Product Type list's schema that do not affect the display field specified for the lookup will not have any effect on the lookup integrity. If you do change the display field in any fashion, and of course if you delete it, then it will break in the same fashion as with the list reference. However, you can set the display field, both in the UI and in the object model, so it is easy to fix this.