.csv import and merge issues with Project 2007

[Todd]

I'm getting data corruption when attempting to merge into Project 2007. The
data being imported is a .csv file (exported from Test Track Pro) that I'm
merging into a large Project file.

The merge results in rows in my project file that are directories (not
tasks) being overwritten with task information (although they still function
as directories).

Expected behavior is for
*imported tasks with existing merge keys in the project file to update with
new data
*imported tasks with new merge keys to be added as new rows
*existing directories in project to be untouched.
(This is how merging has worked for me for over a year in Project 2003.)

I've installed both the SP-1 as well as the infrastructure updates.

I posted this initially in response to an older related question, but am
reposting as a new question as I didn't see the topic float to the top.

 

[JulieS]

Todd,

Please check your original post, I replied to you there.

Julie

 

[Todd]

Thanks for the quick response, Julie. For some reason, I'm unable to find
your response to my previous post.

FWIW, the issue I'm having seems to be different from the import related
predecesor data loss described in the other thread.

I rely heavily on the ability to merge new tasks and data from TTP into
Project on a daily basis and this corruption issue arising from the migration
from 2003 to 2007 unfortunately breaks that process.

I'm inclined to simply revert back to 2003 where this problem doesn't exist,
but I have been planning to get my associates into Project 2007 and take
advantage of some of the features of Project Server 2007 to synchronize our
planning.

Any help would be tremendously appreciated.

 

[JulieS]

Hi Todd,

In your original post as well as your comments below you mention
"directories" several times. I am not sure what you are referring
to, as I don't believe there are "directories" in project files.

Can you expand on that comment?

Julie

 

[Todd]

Ah, I can see where that is confusing. By directories I mean 'summary
tasks'. I am tracking many tasks in several projects through numerous depts.
I use summary tasks to create a nested hierarchy to sort work in Project
into logical groups.

Fortunately, since my last post I've actually stumbled upon the solution to
my problem.

The issue had to do with 'summary tasks' not having data in the 'bug number'
field, a custom field I am using as the merge data key for imported tasks.
When importing a csv file and using bug numbers as the data key, instead of
just appending new tasks/bugs at the end, Project was slotting new tasks into
any column without data in the bug number field *including* summary tasks.
It's definitely a bug with Project but it can be worked around by entering
dummy data in the bug # field for summary tasks. In that case new tasks
*seem* to append as expected. I'm going to test the fix a few more times to
be sure.

 

[JulieS]

Hi Todd,

Thanks for the clarification and for the explanation of the
resolution. I can well imagine that using a null value as the merge
key would create significant problems. I wouldn't call it a bug
however -- Project did exactly as you requested -- it merged the
null values together, overwriting data.

Glad to know you've worked it out and thank for posting the
resolution.

Julie

 

[Todd]

Interestingly, having null values in the merge key field didn't create
problems in 2003.

In contrast, 2007 merges an imported task that has data in the merge key
field (all imported tasks have bug numbers) with tasks existing in the
project file that don't have data in the merge key field. So essentially
follows the logic for the merge key:

if X=Y OR if Y = null, then merge, if not append.

That's unexpected and unnecessarily limiting behavior from my perspective.

2003 operated in what I consider to be a more intuitive and generally useful
manner by not assuming all information in a task is dispensible and
overwriting it if the merge key field is null. 2003's logic is simply:

if X=Y, merge, if not append.

So it remains a bug in my book.

 

[JulieS]

Thanks for the additional details Todd. I know some fairly
significant changes were done to the back-end database and this
oddity may have been an unintended result of that change.

Julie