Change of Text Field from "Text" to Empty "Lookup"

[MrAlNather]

Hi,

MOPS 2007 with SP2.

I have recently experienced two occasions with two seperate schedules
where all the text fields have changed their input criteria from
normal "text" to a blank lookup table. This has removed all the data
that was previously in the fields.

This appears to have happened automatically. Project Professional
users have not changed the settings in their files. The administrator
claims not to have changed any settings in global.

Furthermore, the administrator is now claiming that local macros are
probably causing this, without explaining how it happens (this is
probably a political statement as they like to use eglobal as a
restrictive control method rather than a method to share "good stuff"
across the company). We use Rod Gill's s-curve macro and another one
that sets a time interval to show only "current-ish" tasks. Neither of
these macros use any text fields. The time interval macro uses the
Flag10 field.

In the last instance of this, the user closed his schedule in the
evening and opened it the next morning to find this had happened. He
did not run any macros.

I have never come across this issue before.

Can anyone shed any light on what we are doing wrong?

Thanks,

Paul

 

[Rod Gill]

If you have text in a Text field, then create a lookup list for that text
field, any values that are not on the list get deleted automatically. In
Project 2007, Edit lookup dialog, expand the Data Entry options and set the
Allow additional items to be entered option and the text won't get deleted
when creating the lookup.

This is the behavior in Project, I don't have server available at the moment
to test if the same happens with Enterprise lookups.



--

Rod Gill
Microsoft MVP for Project - http://www.project-systems.co.nz

Author of the only book on Project VBA, see: http://www.projectvbabook.com

Hi,

MOPS 2007 with SP2.

I have recently experienced two occasions with two seperate schedules
where all the text fields have changed their input criteria from
normal "text" to a blank lookup table. This has removed all the data
that was previously in the fields.

This appears to have happened automatically. Project Professional
users have not changed the settings in their files. The administrator
claims not to have changed any settings in global.

Furthermore, the administrator is now claiming that local macros are
probably causing this, without explaining how it happens (this is
probably a political statement as they like to use eglobal as a
restrictive control method rather than a method to share "good stuff"
across the company). We use Rod Gill's s-curve macro and another one
that sets a time interval to show only "current-ish" tasks. Neither of
these macros use any text fields. The time interval macro uses the
Flag10 field.

In the last instance of this, the user closed his schedule in the
evening and opened it the next morning to find this had happened. He
did not run any macros.

I have never come across this issue before.

Can anyone shed any light on what we are doing wrong?

Thanks,

Paul

__________ Information from ESET Smart Security, version of virus
signature database 4986 (20100330) __________

The message was checked by ESET Smart Security.

http://www.eset.com

__________ Information from ESET Smart Security, version of virus signature database 4986 (20100330) __________

The message was checked by ESET Smart Security.

http://www.eset.com

 

[Ben Howard [MVP]]

Hi Paul, are these Enterprise Text Fields or local ones?

 

[MrAlNather]

If you have text in a Text field, then create a lookup list for that text
field, any values that are not on the list get deleted automatically. In
Project 2007, Edit lookup dialog, expand the Data Entry options and set the
Allow additional items to be entered option and the text won't get deleted
when creating the lookup.

This is the behavior in Project, I don't have server available at the moment
to test if the same happens with Enterprise lookups.

--

Rod Gill
Microsoft MVP for Project -http://www.project-systems.co.nz

Author of the only book on Project VBA, see:http://www.projectvbabook.com

















__________ Information from ESET Smart Security, version of virus signature database 4986 (20100330) __________

The message was checked by ESET Smart Security.

http://www.eset.com- Hide quoted text -

- Show quoted text -

Thanks Rod,

I know how to change the fields. It even comes up with a nice big
warning before you finalise the change. In these cases it seems to
have happened without any interference from anyone. One of the users
did not even know this was possible to do, let alone actually do it!

I figured the EPM admin had changed a setting, but even he does not
seem to know that this is possible for him to do at a global level (I
can't remember whether it is or not). For political reasons the EPM
admin is getting aggravated and accusing local macros of being the
cause. I find this really difficult to believe as I have checked all
the code we are using and there is no way (unless some sort of bug is
triggered). This is an attempt to undermine confidence and it works.

He doesn't bother to explain how "macros" can do this or when it has
happened before. I cannot find any evidence on this forum to back up
his claims.

Paul

 

[MrAlNather]

Hi Paul, are these Enterprise Text Fields or local ones?
--
Regards,  Ben.

http://www.applepark.co.ukhttp://appleparkltd.spaces.live.com/












- Show quoted text -

Hi Ben,

I am rusty as a server admin, so have forgotten the difference. They
are "Text1 through Text30".

Paul

 

[MrAlNather]

Hi Ben,

I am rusty as a server admin, so have forgotten the difference. They
are "Text1 through Text30".

Paul- Hide quoted text -

- Show quoted text -

Guys,

So I'll take the stony silence as supporting of my view that what I'm
being told by my admin is garbage.

Thanks anyway

Paul

 

[Gary L. Chefetz]

You are talking about local fields, not enterprise fields. These cannot be
controlled in the enterprise, so your Administrator is not to blame.
Certainly, using local macros could explain the changes as well as user
error. If you need to centrally control custom fields, you should use
enterprise fields only.

 

[MrAlNather]

You are talking about local fields, not enterprise fields. These cannot be
controlled in the enterprise, so your Administrator is not to blame.
Certainly, using local macros could explain the changes as well as user
error. If you need to centrally control custom fields, you should use
enterprise fields only.

--
Gary L. Chefetz, MVP, MCT, MCTIP
Business:http://www.msprojectexperts.com
FAQs:http://www.projectserverexperts.com
BLOG:http://www.projectserverhelp.com








- Show quoted text -

Thanks Gary,

Just to be crystal clear; a macro will only change fields text1
through text30 if it is programmed to do that? Generally using macros
to do other things does not change the settings on these fields?

Paul

 

[Gary L. Chefetz]

Paul

You haven't provided enough information to be deterministic about what's
going on in your environment, and analyzing macros isn't an NG activity,
although the Dev group will help you with code issues. Macros can do all
sorts of things including altering field structures for both enterprise and
non-enterprise fields, so there's no telling what you might be experiencing
without analyzing the macros and the environment. This could have absolutely
nothing to do with macros and could be user-induced issues.

Bottom line, I can't give you any conclusive statement at this point.

--
Gary L. Chefetz, MVP, MCT, MCTIP
Business: http://www.msprojectexperts.com
FAQs: http://www.projectserverexperts.com
BLOG: http://www.projectserverhelp.com

 

[MrAlNather]

Paul

You haven't provided enough information to be deterministic about what's
going on in your environment, and analyzing macros isn't an NG activity,
although the Dev group will help you with code issues. Macros can do all
sorts of things including altering field structures for both enterprise and
non-enterprise fields, so there's no telling what you might be experiencing
without analyzing the macros and the environment. This could have absolutely
nothing to do with macros and could be user-induced issues.

Bottom line, I can't give you any conclusive statement at this point.

--
Gary L. Chefetz, MVP, MCT, MCTIP
Business:http://www.msprojectexperts.com
FAQs:http://www.projectserverexperts.com
BLOG:http://www.projectserverhelp.com









- Show quoted text -

Thanks Gary,

Understood. I'll post the macros on the developer group to get
feedback. One of them is Rod's S-curve, though, with minimal mods so I
know it isn't that one.

Paul

 

[Neil A]

Hi,

Did you ever find an answer to this?

We've recently found the same problem across a number of projects (7 out of
17 sampled). The projects affected show no particular pattern - we have some
that have their own custom code, some that don't. There are different PMs
involved. Some interface to other systems (Cobra), but some don't.

For those projects affected, not all text fields are affected. There are
some fields defined in the Global.mpt, and these are ok. Every other custom
text field (non-enterprise) has an empty lookup.

One strange thing about our environment - we have SP2 installed on the
clients, but not on the server. Long sad tale there - the server needs a
rebuild to get SP2 installed.

Thanks
Neil.