Steven Streight put forth some guesses as to the underlying reasons behind the secretive nature of the project. Hi Steven, Yeah, there a number of possible reasons for a project to be 'secret'. 'Being set up' could certainly be one of them. (Although secrecy, in and of itself, isn't exactly a 'requirement' for being set up...) Unethical 'Enron' style projects can also be reason for secrecy ... although that certainly doesn't seem to be the case here. >>If the boss wants this project to be secret, for now, what does that imply? I have a bit of a different take. To me the secrecy implies that, like a lot of other IT departments in large companies, there are a lot of 'internal office politics' going on at this company. My best guess is that there is an upcoming budget meeting where the boss wants to leverage this project to either (a) ask for more money & headcount, or (b) explain why his group can't give up any money or headcount. The 'secrecy' is to avoid tipping his/her hand to his/her peers and has nothing to do with the developer at all. My second best guess keys off Faye's note that she is "new" to the industry. I think there is a chance this is 'busy work'. It would be nice if you could get approval for 'the next big project' in the morning, hire the people you need to do the work in the afternoon, and start the project the next morning. Unfortunately it doesn't always work like that. I would not be surprised if, a month or so from now, Faye were told to 'back burner' this project and start in on the _real_ project. [So why the secrecy here? Some managers are like two-year olds; if they catch wind that manager A has someone working on a non-approved project, they run to the boss to try to steal the headcount.] Big company dynamics are not always that far removed from Kindergarden. Now, however much fun it is to try to guess the motivations of people we don't know working at companies we've never worked at ... it really doesn't add to the 'signal' of offering helpful suggestions to Faye. [I was gonna let Ian's post slide, but with two posts focusing on the potential negatives - I wanted to offer some less scary and less nefarious alternatives. (Occam's razor? You decide.)] We owe tips! [Deja-VooSlap - The impending sense that one is, once again, about to be 'B-slapped' for offering up technical advice that bends the rules a bit.] <tip type="Custom Object Attributes as Global Variables" author="RonL."> Some enterprise reporting packages, (Brio and Oracle Forms/Reports/Etc. come to mind), allow developers to 'tuck away' small bits of code in all kinds of little cubbyholes - OnClicks behind command buttons, OnChange behind dropdowns and text inputs, OnActivate on each of the screens within the report, OnStartUp at the report level itself ... Once in a while, you want a user value/input/selection of some type to 'persist' and be available to you from elsewhere in the report. Sure, that's a good place to use a global variable in the highest 'document' level scripting location available [and that's the "Right" way to do it] - but sometimes there is already a good deal of code in that section that may have been written (badly) by someone else (like me!). Since some of these reporting packages open up the DOM to allow you to do some scripting, you can (in Brio for example) declare your own 'custom' attributes for any object. Oooo! This gives you an easy was to 'cheat'! You can declare a "custom" object attribute and assign it the value you want to persist. Kind of like an 'instant' global variable. Got a rectangle sitting around a set of radio buttons to look nice? "Screen1.Rect1.RonsGoofyCamelCaseFlag = 42;" sets a value you can read or modify from anywhere else in the report. Handy. Gee. I wonder why this isn't covered anywhere in the documentation? [Um, no. Actually I *don't* really want to talk about 'code maintainability' implications ... but thanks for asking!] ;-P </tip> HTH, RonL.