Project crashes on cut and paste after starting to use Project Ser

[Joncat]

Have been using Project for several years to plan and track our projects.

Am in the process of implementing Project Server.

Imported around 40 existing plans into project server. Our employees are
recording time in our old project system and also running a test using the
project server time reporting system. We updated the project server projects
with 2 weeks worth of timesheet data. I am using a 'master plan' outside of
project server that has all of the Project servers projects set up as
sub-projects in order to open all of the files. To change our incomplete
task to 'start no earlier than' the date following the last timesheet report
I am using a table with the constraint date column visible. I filter the
table to show only the unstarted tasks (with no summary tasks), enter the new
date in the first row and then select the rest of the rows for that column
and eiter 'edit/fill/down' or just cut and paste to the rest of the tasks.
When I do this however, Project crashes with the ever popular "Microsoft
Project has encountered a serious error . . . Do you want to send info to
Microsoft" message. We use this same technique on the existing system which
does not use the project server version of the files, and everything works
fine. There are very few differences between the two sets of files beyond
replacing one of our Administrative projects with the one provided by Project
Server. Interestingly enough, in the project server admin project, which has
only two weeks of data, some of the tasks show up in the time sheets as
having Remaining Work that does not equal 0 hrs --- a few of them have things
like .25 hrs or 6.75 hrs. If I open the Project Server admin project in
Project, the Remaining Work for these tasks shows as 0 hrs.

So any ideas what is causing the crash on copy/paste or edit/fill/down and
why do some of the admin tasks show remaining work <> 0 if the project server
timesheet but not when you open the project in Project? Seems to have
something to do with Project Server, since the original plans that we didn't
load into the server do not exhibit either problem.

Thanks in advance for your help,
jc

 

[Gary L. Chefetz \(MVP\)]

Cut and paste of entire rows is a big nono in Project Server. This
duplicates key information in the database and will cause file corruption.

--

Gary L. Chefetz, MVP
"We wrote the books on Project Server"
http://www.msprojectexperts.com

For Project Server FAQs visit
http://www.projectserverexperts.com

For Project FAQs visit
http://www.mvps.org/project

-

 

[Joncat]

I am aware that copying whole tasks is perilous --- you don't even need to be
using Project Server to get bit by that one as far as I have seen, but . . .

We are not copying entire rows. We are only copying the constraint date
value from one row to another. This has always worked reliably (like for the
past 4 years with hundreds of projects).

Is there any way to assure that the existing files are not corrupted? They
seem to work fine with the copies we still have outside of Project Server.
If there was a reasonable way to check for corruption, that'd be a help.

Thanks,
jc

 

[Gary L. Chefetz \(MVP\)]

I assume that if you use a plain-text source for your copy, that you will
not experience this problem. Try typing a date in notepad, copy it, and
paste into cells. I'm more curious why you would work it this way rather
than using Tools > Tracking > Update project to accomplish the same thing in
a couple of clicks.

--

Gary L. Chefetz, MVP
"We wrote the books on Project Server"
http://www.msprojectexperts.com

For Project Server FAQs visit
http://www.projectserverexperts.com

For Project FAQs visit
http://www.mvps.org/project

-

 

[Joncat]

We experienced some quirky issues with Project some years ago that we
attributed to the Tracking/Update feature --- perhaps erroneously, but
changing this practice seemed to eliminate the symptom. Over the years, I've
seen Project do so many bizarre things that it's sometimes tough to pinpoint
a root cause. Using Edit/Fill/Down has worked reliably for us for years even
if it's a bit more inconvenient. Maybe we'll try it again. Still, it's hard
to believe that using a standard feature, like edit/fill/down on a column
would cause a crash.

Do you have any ideas on how to detect and isolate 'corruption' --- at the
moment it seems that all we can do is crash the system and assume that there
must be something wrong in one of the thousands of tasks we are dealing with.