Microsoft Playbook error: CustomFieldInvalidUID

[Sam]

Hi,

I am facing an error while using Microsoft Playbook to restore the custom
fields and lookuptables in my PWA site.

Follwoing are the steps I followed:
1. Manually create custom fields.

2. Used the Playbook Tool to make a backup of the Custom Fields.

3. Manually delete the custom fields from the Instance.

4. Used the Playbook Tool to restore the deleted custom fields back onto the
Instance.

5. The Playbook Tool throws errors if this process is repeated more than once.

The error I am facing is "CustomFieldInvalidUID" or "LookuptableInvalidUID".


Am i doing something incorrect while restoring the fields and tables?

 

[Andrew Lavinsky]

I would question if it is perhaps a procedural issue....

1) Are you using Merge or Replace? Sounds like Merge, and I might recommend
Replace
2) You don't need to delete the fields if you're using Replace

Note that you may also opt to restore the views at the same time. They're
linked to the fields using the UID. If the UID gets changed, then the views
get hosed up as well.

-A

 

[Sam]

Hi Andrew,

Are you saying that I should not delete the fields at all, if i need to
restore?

I have tried both replace and merge (however I need to use Merge option
only) after deleting the fields and faced the same error.

 

[Andrew Lavinsky]

There's no need to delete the fields. Replace will simply replace the old
ones.

-A

 

[JazzSayzz]

Hi Sam and Andrew,

We are facing the exact same problem. "CustomFieldInvalidUID" error when
trying to copy our custom fields and lookup tables from development to
production.

I have read your post and replies, but I figure you didn't find a solution
yet?

Maybe it has something to do with using the Dutch version of MS EPM.
Although all the other settings copy without a glitch.

Thanks in advance!

Regards,
J

 

[Andrew Lavinsky]

At this point, we're straining the limits of my knowledge of Playbooks, which
itself is an imperfect tool that is quite useful but sometimes surprising
in its results. I would pose a couple of questions that focus on what seem
to typically throw Playbooks off track:

1) Are you sure that DEV and PROD are patched to exactly the same level?
2) Does this throw an error the first time you deploy the Playbooks to a
fresh instance, or if you try to deploy Playbooks a second time to an instance?
What happens if you deploy to a VPC or virtual environment?
3) Sometimes there are dependencies in the settings which cause Playbooks
to choke, for instance if you have timesheets off, and try to copy timesheets
settings, or if you don't get the views with the fields, etc. (Probably
not the case, but I throw it out there as a possibility)
4) Are you merging or replacing? Do you get different results based on which
one you use?
5) Is the log file identifying which field is causing the issue, or is it
all fields?

-A

 

[JazzSayzz]

Andrew,
We researched your suggestions, but they did not (yet) solve our problem.
I've posted our reply underneath your questions. Thanks!

1) Are you sure that DEV and PROD are patched to exactly the same level?
We checked the patch levels on both environments. Both run on build number
12.0.6422.000 (Service Pack 2)

2) Does this throw an error the first time you deploy the Playbooks to a
fresh instance, or if you try to deploy Playbooks a second time to an
instance?
What happens if you deploy to a VPC or virtual environment?
I’m not sure if this problem only occurs the second time. Because of the
time restrictions we’re not able the recreate a fresh install.

3) Sometimes there are dependencies in the settings which cause Playbooks
to choke, for instance if you have timesheets off, and try to copy timesheets
settings, or if you don't get the views with the fields, etc. (Probably
not the case, but I throw it out there as a possibility)
We only experience problems with restoring “Custom Field and Lookup Tableâ€.
All other settings with playbook work perfectly.

4) Are you merging or replacing? Do you get different results based on which
one you use?
We tried both options (Replace and Merge). Both options result with the same
errors

5) Is the log file identifying which field is causing the issue, or is it
all fields?
Problems occur only with Custom Fields & Lookup Tables. We don’t have any
errors with the default custom fields.

 

[Sam]

Hi,

I found that the problem we are experiencing is actually by design. What is
occurring is that once a custom field is deleted the GUIDs for these fields
are still retained in shadow tables within the databases (Published). These
entries act as place holders for that particular custom field. For this
reason we are able to restore the xml containing these custom fields into a
different site but not the same site it was deleted from as according to
these tables the GUID that is attempting to be restored already exists within
the database although it has been deleted.

The only way around this would be to locate the GUID for the custom field
within the database shadow tables and remove them. Unfortunately direct
modification to the project databases is not supported. Prior to attempting
to remove these values you should always backup your environment and take
extreme precaution as you would be entering a non-supported state.

Hope this helps