Published Projects do not appear in project Center

[Kurt Petteloot]

We use Project Server 2003 with SP3 installed on Server as well as on MSP
Prodfesiiona clients.

Next to the default 'Published' version, we use a second version (called
'PP') to store and maintain a high level version of each ('*.published')
project.

The problem is that the 'PP' versions are not properly displayed in the
Project Center view in PWA. This used to work before however... since then
SP3 has been installed, but I can not be sure that this is what caused the
problem.

This is how we work to create both version of a project:

First the published project-version is created from an enterprise template
and saved (+published) onto the server. Everything fine so far: the project
shows up in the Project center views in PWA as can be expected.

Then we create a new project and store it with the same name as the
published project. Only this time we save the project as a 'PP' version and
publish it the same way as we did with the published version.

This time however the project does not appear in the project center view!!

So we went digging...and this is what we found...

With each publish of the project an xml file is dropped in and removed again
from the VIEWDROP folder. No errors are found in the eventlog and a trace on
the SQL database didn't reveal any errors. So it looks as if the project is
published properly.

We dug a little deeper....and came up with this...

For both versions of the project, a record had been created in the
MSP_WEB_PROJECTS table. By modifying the URL to show the Project view of the
'PP' version we can even view the project from PWA in a project view.

So we compared both records and found that the field
'WPROJ_Default_WPROJ_ID' for the 'PP' version had a value of -1... and all of
the other 'PP' projects that are missing in the project center views have the
same value, instead of the ID that refers to the default project.

Changing this value to the project ID of its published version, and then
refreshing the project center view and... voila ... there it is. Of course we
reverted the value back to its original value (-1), because we figure that
there has to be some good reason why this field is not set correctly.

Can anyone help us to figure out what is preventing this value to be set
correctly?

Thanks a lot for your help.

Kind regards
Kurt

 

[Gary L. Chefetz [MVP]]

Kurt:

Your process is broken as this is not the way to use versions in 2003. First
save the published version, then do a Save As to save the pp version.
Basically, you're clobbering the database by using the same name. You can't
save any project as any version other than "published" until you save the
published version. I'm quite surprised that the system isn't trapping this
and throwing an error.

--

Gary L. Chefetz, MVP
MSProjectExperts
For Project Server Consulting: http://www.msprojectexperts.com
For Project Server FAQS: http://www.projectserverexperts.com

 

[Kurt Petteloot]

Hi Gary,

Thanks for the input. Based on your answer I started a SQL trace to figure
out what really happens in case the PP version is created from scratch and
see the difference with what happens when the PP version is created by saving
the published project as a PP version.

It is obvious now that the code only inserts the correct vlaue for the
default project id when the latter of the two above mentioned scenario's is
run.

However, IMHO there is still a flaw in the logic... because: if the system
allows one to save a PP version from scratch and all it tests for is to see
whether there is a project with that same name already stored on the databse,
then why doesn't it register the webproject id of that other project in the
field. Moreover, I'm pretty sure that project server did work like this
before, wince we have several PP versions that have been stored in the way I
described in my earlier post. Apparently this behavior has been altered by
installing a patch, although I'm in oblivion about the exact patch that may
have caused it.

So, as mentioned before, it seems to me that the system does have a defect
here by allowing the creation of these versions the way we create them.
Although I agree with you that we may need to adopt our procedures, it shows
that project server is inconsistent in its behavior this way.

Thanks for your help so far Gary. Looking forward to your response to see if
this could be considered a defect in your opinion.

Kind regards
Kurt

 

[Gary L. Chefetz [MVP]]

Kurt:

I think what this boils down to is that you were able to exploit an
undiscovered bug in the system until the patch. The bug remains, but
obviously it has changed behaviors. Regardless of the bug behavior, you are
not using the tool as it was designed to be used.

--

Gary L. Chefetz, MVP
MSProjectExperts
For Project Server Consulting: http://www.msprojectexperts.com
For Project Server FAQS: http://www.projectserverexperts.com