Hi Rick;
Well, unfortunately, I'm old school, and by that I mean have been in the tech-industry since '78... so "been there and coded in that", and on almost every platform as well. ARServer since '99 There is a major difference in "Coding" (asm, c, java, and what ever) and "Configuring" which is what I actually term using the "Admin Tool" to build tables/forms/workflow inside ARServer environment. Certainly when I was writing Asm or C using VI, it was up to the knowledgeable-developer to malloc/free. As the coding tools increased in functionality, you now have built-in checking for things like this (null pointer checks, type casting, etc) it makes coding as near as bullet proof as possible, but still possible to create your own issues... (Everything I compile is enforced to use STRICT, and then run additional tool-sets against it..) This is what "Admin Tool" is designed to do for us, protect us from shooting our own feet off. Especially when the admin tool allows you do to things which will essentially break the functionality inside ARServer! Do not misunderstand my comments, I DO NOT think ARServer is bad, in fact for a development-environment it provides many functionalities and ease of use and integrations all "point-n-click" fashion!!! On the other hand, some lacking programmability is quite frustrating at times. (Additional UI Element Controls, extended programmability (underlying compiled code for performance), ...) I wish I still had some marketing information from the '90s where ARServer was being touted as a "Rapid Development Environment"... would be classic :-) My comments are more targeted as this: I cannot believe that such a functionality issue continues to exist in the Admin Tool for such a long time that all developers simply "accept it as normal", instead of the vendor correcting the issue. (I know I have my fare-share of Remedy tickets against admin tool still open for years...) Combine the above, with the current "it worked in V6 and not in V7 is broken" (or worked in Patch 1 and not in Patch 2..) issues, simply has many of us frustrated... at times extremely frustrated... After all the "What do we want to see in the new Developer Studio" thread had tons (and tons) of well-thought and documented, valid requests to make our lives much easier! Thanks-n-advance; HDT Platform Incident / Problem Manager & Architect Robert Molenda IT OS PA Tel: +1 408 503 2701 Fax: +1 408 503 2912 Mobile: +1 408 472 8097 [EMAIL PROTECTED] Quality begins with your actions. ________________________________ From: Action Request System discussion list(ARSList) [mailto:[EMAIL PROTECTED] On Behalf Of Rick Cook Sent: Wednesday, August 22, 2007 11:00 AM To: [email protected] Subject: Re: Error in query..URGENT ** Well, Robert, that's kinda the downside to a development platform as powerful as Remedy ARS. Ever program in C or Assembler? You can create programs that do almost anything, which is great if you know what you're doing, but hell on wheels if you don't. You can take the address of a pointer in C and start stuffing data into it if you want. You could tell Assembler to allocate memory segments that the OS happens to be using at the time. It's certainly not recommended, but there's nothing in the programming toolset to stop you from trying except cold, hard, reality and a well-timed code review. In that regard, and with that perspective, AR System protects us pretty well from stepping on our collective private parts as we develop. It's a fine line between power and safety, one with which we all have taken issue at times. I have asked for a looping mechanism (I mean a REAL one, not Guides or Go Tos) in AR System, and have been told that we can't have one because we can't be trusted with one. The power has been deemed to not be worth the risk of crashing the odd server. So there we are; in a technological detente, for better or for worse. I think we could be far worse off than we are. Rick On 8/22/07, Robert Molenda <[EMAIL PROTECTED]> wrote: One would "Hope and Think" that the "Administrator tool is bullet proof", and by that I mean, since you must do EVERYTHING via this GUI Tool, you should not be able to shoot yourself in the foot. For example, deletion of attachment pool from ALL views of a form AUTOMATICALLY cascades the deletion to the attachment fields. (deletion of the pool from a VIEW of the form should automatically remove the attachment fields from that VIEW) After all, an attachment field without the pool is useless. Simply watching this list over the years, has proven that "more and more" of these "features" are becoming permanent parts of the Admin Tool. I know that I certainly have tripped and fallen on the sword a few times myself... Whoops, sorry, forgot to turn on/off <RANT> Thanks-n-advance; HDT Platform Incident / Problem Manager & Architect Robert Molenda IT OS PA Tel: +1 408 503 2701 Fax: +1 408 503 2912 Mobile: +1 408 472 8097 [EMAIL PROTECTED] Quality begins with your actions. -----Original Message----- From: Action Request System discussion list(ARSList) [mailto:[EMAIL PROTECTED] On Behalf Of Carey Matthew Black Sent: Tuesday, August 21, 2007 10:32 AM To: [email protected] Subject: Re: Error in query..URGENT Nisha, It is a common mistake is to delete the attachment pool before the attachment fields. Are you sure you removed the attachment fields? Open the form in the Admin Tool and go to the Form (Menu) --> Current View (Menu) -->Fields in View (Menu Item) and verify that these fields do not appear in the "Fields Not in View: (By Name)" list. If the fields are there... then... Select the attachment field and click the "Add>>>" button. You will be prompted to either create a pool or pick an existing pool to relate the attachment field too. (Choose either path) ( repeat above if you have multiple attachment fields without an attachment pool) Then view the field properties for the select the Attachment pool you picked above. Go to the Attachment fields tab. Select the Attachment field and click the Delete button ( repeat above if you have multiple attachment fields without an attachment pool) Hope that helps. -- Carey Matthew Black Remedy Skilled Professional (RSP) ARS = Action Request System(Remedy) Love, then teach Solution = People + Process + Tools Fast, Accurate, Cheap.... Pick two. On 8/21/07, RAMTRI, Nisha, IDC < [EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]> > wrote: > ** > > Hi List, > > I have a staging table in Remedy database (this is a regular form) and > through a simple stored procedure I'm trying to insert records into this > table. However, whenever I'm trying to insert a record I get the following > error: > > View 'RM_FaultSubmit' is not updatable because a field of the view is > derived or constant. > Msg: 4406, Level: 16, State: 1 > > Some days back I had made changes to this staging form. There was an > attachment pool created on this form with 2 attachment fields Attachment 1 > and Attachment 2. Now I have deleted the Attachment Pool from the staging > form and also deleted attachment fields (i.e. Attachment 1 and Attachment 2) > from 'Field' table. However on the form I continue to get reference of these > 2 fields. Is it because of this that I am now unable to insert/update the > table? > > I am really stuck because of this. We are on ARS 6.3 and Sybase 12.5 and Sun > OS 5.8. > > Thanks. > > Warm Regards, > > Nisha Ramtri __20060125_______________________This posting was submitted with HTML in it___ _______________________________________________________________________________ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org ARSlist:"Where the Answers Are"
