S
Stephan Steiner
Hi
I forgot to check until today when I wanted to update one of my test
projects and see if setting a field to the same value as it already had
would still return something to be updated when I call
ProjectDataSet.GetChanges(DataRowState.Modified) - and then to my surprise
it turns out those CFs weren't even there.
Basically, when I create a project, I also add 29 entries to the
ProjectDataSet.ProjectCustomFieldsDataSet - then I call
ProjectWebSvc.CreateProject(ProjectDataSet). That works just fine, the
project is being written and can be opened in the client afterwards, but all
CFs I set are gone.
When I open an existing project that has those CFs, I have no trouble
dumping them. Also, I've started writing tasks with CFs and those CFs stick.
So I figured perhaps I cannot write Project CFs upon project creation so I
checked out the project after creation, wrote the Project CFs, then
submitted them
(by first calling ProjectDataSet.GetChanges(DataRowState.Added) and calling
QueueAddToProject on that dataset, then by calling
ProjectDataSet.GetChanges(DataRowState.Modified) and calling
QueueUpdateProject (the latter because my code automatically takes care of
updating a CF if it should already exist.. and since some of my CFs have
default values, they exist but don't necessarily have the value I want them
to have).
And this is what happens:
QueueAddToProject fails with an CustomFieldRequiredValueNotProvided error.
QueueUpdateProject runs without a glitch
I turn the SoapException into PSILibrary.PSClientError and go through it -
but it isn't very helpful. ErrorAttributeNames() returns mdpropuid and the
matching entry in ErrorrAttributes is an empty string. So here's a
sidequestion.. where's the useful information? I finally managed to get some
more useful error info by accessing the private properties of
PSIClientError - errorInfoXml finally provided some useful information:
<errinfo><dataset name=\"ProjectDataSet\"><table
name=\"ProjectCustomFields\"><row
CUSTOM_FIELD_UID=\"79298157-67fb-4a64-b933-77e4890a030c\"><error
id=\"11713\" name=\"CustomFieldRequiredValueNotProvided\"
uid=\"6d62326f-75c5-4c0e-93ff-44cb855e0140\" mdpropuid=\"\"
/></row></table></dataset></errinfo>
Stil.. the main problem here is that I have a CUSTOM_FIELD_UID.. but those
values are all newly created GUIDs.. useful information would be the
MD_PROP_ID or MD_PROP_UID so you know which CF lacks the value. And is
finding the error really supposed to be trial and error until you find the
appropriate field and using reflection to access private variables to get
some useful bit of info?
So in the end I'm stuck with 3 questions:
1) How do you write Project CFs upon project creation?
2) Am I doing something fundamentally wrong in writing the project CFs
(using the same approach as writing Task CFs.. the latter ones work just
fine)
3) Is there no way to extract useful information from an error (even
accessing the private variable you still need to propagate it back and
search the data set for the appropriate entry then re-match against the
CustomField definition to know which field caused the problem).
Regards
Stephan
I forgot to check until today when I wanted to update one of my test
projects and see if setting a field to the same value as it already had
would still return something to be updated when I call
ProjectDataSet.GetChanges(DataRowState.Modified) - and then to my surprise
it turns out those CFs weren't even there.
Basically, when I create a project, I also add 29 entries to the
ProjectDataSet.ProjectCustomFieldsDataSet - then I call
ProjectWebSvc.CreateProject(ProjectDataSet). That works just fine, the
project is being written and can be opened in the client afterwards, but all
CFs I set are gone.
When I open an existing project that has those CFs, I have no trouble
dumping them. Also, I've started writing tasks with CFs and those CFs stick.
So I figured perhaps I cannot write Project CFs upon project creation so I
checked out the project after creation, wrote the Project CFs, then
submitted them
(by first calling ProjectDataSet.GetChanges(DataRowState.Added) and calling
QueueAddToProject on that dataset, then by calling
ProjectDataSet.GetChanges(DataRowState.Modified) and calling
QueueUpdateProject (the latter because my code automatically takes care of
updating a CF if it should already exist.. and since some of my CFs have
default values, they exist but don't necessarily have the value I want them
to have).
And this is what happens:
QueueAddToProject fails with an CustomFieldRequiredValueNotProvided error.
QueueUpdateProject runs without a glitch
I turn the SoapException into PSILibrary.PSClientError and go through it -
but it isn't very helpful. ErrorAttributeNames() returns mdpropuid and the
matching entry in ErrorrAttributes is an empty string. So here's a
sidequestion.. where's the useful information? I finally managed to get some
more useful error info by accessing the private properties of
PSIClientError - errorInfoXml finally provided some useful information:
<errinfo><dataset name=\"ProjectDataSet\"><table
name=\"ProjectCustomFields\"><row
CUSTOM_FIELD_UID=\"79298157-67fb-4a64-b933-77e4890a030c\"><error
id=\"11713\" name=\"CustomFieldRequiredValueNotProvided\"
uid=\"6d62326f-75c5-4c0e-93ff-44cb855e0140\" mdpropuid=\"\"
/></row></table></dataset></errinfo>
Stil.. the main problem here is that I have a CUSTOM_FIELD_UID.. but those
values are all newly created GUIDs.. useful information would be the
MD_PROP_ID or MD_PROP_UID so you know which CF lacks the value. And is
finding the error really supposed to be trial and error until you find the
appropriate field and using reflection to access private variables to get
some useful bit of info?
So in the end I'm stuck with 3 questions:
1) How do you write Project CFs upon project creation?
2) Am I doing something fundamentally wrong in writing the project CFs
(using the same approach as writing Task CFs.. the latter ones work just
fine)
3) Is there no way to extract useful information from an error (even
accessing the private variable you still need to propagate it back and
search the data set for the appropriate entry then re-match against the
CustomField definition to know which field caused the problem).
Regards
Stephan