Thanks for replying Tommy. Yea I know about the dev cache mode and we have it enabled on our dev server. Even with the dev cache mode turned on, I just wish the developer studio didn't talk to the server so much and had a cache of it's own. IMO, it should only talk to the server when I'm opening the object and saving the object.. With the exception of modifying table fields I guess ;)
On Mon, Feb 14, 2011 at 2:56 PM, Tommy Morris <tommy.mor...@radioshack.com>wrote: > One thing to make sure of is that Developer Cache Mode is turned on. Our > app server crashed every time a developer would try to do anything in Dev > Tool without dev cache mode on. And since we cannot put the server in Dev > Cache mode during Production Hours I have to do after hours “code changes” > to change the time on a notification escalation. > > > > *From:* Action Request System discussion list(ARSList) [mailto: > arslist@ARSLIST.ORG] *On Behalf Of *Robert Halstead > *Sent:* Monday, February 14, 2011 4:44 PM > *To:* arslist@ARSLIST.ORG > *Subject:* Frustrations with Remedy Developer Studio 7.5 > > > > ** Forgive me as this is more of a rant. > > > > My patience for Remedy Developer Studio 7.5 is growing thin. I find that > performing the most insignificant tasks become a test in patience as the > tool communicates to server for every single action. > > > > Selecting a field on a form, talk to the server to get properties. > > Selecting multiple fields, talk to the server to get all properties. > > Select a field in a web service definition... > > > > The latter will take quite a bit of time if you have a lot of fields on a > form. > > > > I'm getting very frustrated with the performance of the Developer Studio.. > I wish that the tool cached the objects from the database like the Migrator > does and only updates when needed or when the developer forces the refresh. > Even have a periodic refresh would be nice.. > > > > I wish that the tool wasn't so chatty back to the server. It doesn't make > sense that when object reservation is enabled, that the tool would need to > go to the server for each field (like it would have changed since I have the > form reserved?). > > > > Right now I'm pulling my hair out trying to modify a web service operation > we have on one of our forms that has 100+ fields. Every time I remove / add > a output mapping field, the developer studio does some mass server > communication that takes about 30 seconds. To do what exactly, I'm not > sure... If I have the web service object reserved, why would it need to go > to the server for changes or whatever? I haven't even saved the object > yet... why is it talking to the server?? > > > > Why can't it just load the entire web service object and the form it > references into a cache so that the "user experience" is fast and snappy > after the initial load? Then when I save the web service, perform the due > diligence to ensure the mappings are correct. > > > > I have used the knowledge base to look for "enhancements" and tricks when > using the developer studio, but alas it seems no one else suffers from this > issue or no one has encountered it / reported it. > > > > It would be nice if BMC provided configuration settings that we could pass > to the developer studio to configure how we want the tool to act and when we > want the tool to communicate to the database or put more options in the > preferences to configure the performance of the developer studio. > > > > Perhaps something greater than just adjusting the memory that java uses... > > Perhaps there could be a white paper on database optimizations that would > help the developer studio perform better. > > > > It would also be nice if while we are waiting for a form or other object to > load, that a progress bar is displayed or something that tells us what the > tool is doing. Most of my time spent in the developer studio is the "white > screen" as the tool becomes unresponsive during save's or object retrievals > from the server.. As a developer, I want to know what the tool is doing so > that when I complain to BMC that the performance is slow, I have a point of > reference. If I know generally what is going on, maybe I can optimize the > database so that the operation is quicker? Who knows! > > > > Whats frustrating is that after 1 revision and 7 patches later, I would > expect the developer studio to have all the bugs and performance issues > ironed out and be fast and snappy... Nope. > > > > How do BMC's Remedy developers program in this? Don't they get frustrated > with the NullPointerErrors and slow responsiveness? I'm guessing that they > just install a remedy server on their local box to avoid the performance > issue of the network. > > > > I think the development studio is a giant step up from the old Remedy > Administrator that we have all used in the past. But now that the tool is > main stream, there needs to be some serious work done to make the tool more > responsive and optimized when connecting over the network. > > > > Again, sorry for the rant, I just needed to vent. > > > -- > "A fool acts, regardless; knowing well that he is wrong. The ignoramus acts > on only what he knows, but all that he knows. > The ignoramus may be saved, but the fool knows that he is doomed." > > Bob Halstead > > _attend WWRUG11 www.wwrug.com ARSlist: "Where the Answers Are"_ > -- "A fool acts, regardless; knowing well that he is wrong. The ignoramus acts on only what he knows, but all that he knows. The ignoramus may be saved, but the fool knows that he is doomed." Bob Halstead _______________________________________________________________________________ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org attend wwrug11 www.wwrug.com ARSList: "Where the Answers Are"
