Re: Interesting "Bug" in 7.1
Oh, if I had a nickel for all of the things that BMC tries to pass off as "training issues" that wouldn't be issues at all if things were simply designed and implemented properly in the first place... -Lyle Taylor -Original Message- From: Action Request System discussion list(ARSList) [mailto:arsl...@arslist.org] On Behalf Of Steve Michadick Sent: Tuesday, December 23, 2008 5:20 AM To: arslist@ARSLIST.ORG Subject: Re: Interesting "Bug" in 7.1 Here's a couple more... ARS 7.1 patch 004 w/ ITSM 7.0.3 patch 008 - If you change the name of a form in the Admin Tool, your users will start getting a $MENU$ pattern matching error telling them that the value they selected from the menu doesn't match what is in the menu. We fixed this by removing the $MENU$ from the Pattern for each affected field. BMC Support told me that this is fixed in patch 005, but until then we just have to restart the services. When someone goes to create an Incident and manually selects values in the Incident Owner fields, but then deletes them out before saving the Incident, that ticket can no longer be modified. Selecting from the menus sets some hidden fields that are not cleared out when the menu fields are. These hidden fields are used in workflow to lock the ticket down. After disabling many AL's and Filters to get past this, we finally just had them recreate the ticket (leaving the Owner fields blank to be filled in by workflow) and then deleted the "dead" ticket. I suppose you could also unhide the offending fields and clear them out too. I'm going to create some workflow to keep this from happening in the first place. Of course, I've been told that this is a training issue that users shouldn't be entering and clearing out those fields, but you know users will do all sorts of things they aren't supposed to do. Steve Michadick Remedy Engineer MCNOSC -Original Message- From: Joe DeSouza [mailto:joe_rem...@yahoo.com] Sent: Monday, December 22, 2008 1:31 PM Subject: Re: Interesting "Bug" in 7.1 ** Wanna know another interesting bug? Try exporting an AL that has a really long Set Field If qualification as a .xml export, and then reimporting it again. The import will fail. I experienced that a couple of weeks ago and was beating my brains numb as to why the import was failing on that AL only and not others. And the only different thing about that AL compared to any other that exported and imported well was that qualification length. Exporting and importing it as a .def file, it has no problem. There is nothing wrong with the xml format but yet for some reason the import fails. The reason why I wanted a xml export and not a def, is that there were some modifications I needed to do on the def file which is easier in the xml format than the def. Joe From: ccrashh To: arslist@ARSLIST.ORG Sent: Monday, December 22, 2008 12:08:47 PM Subject: Interesting "Bug" in 7.1 If you create a SET FIELDS action in an Active Link on a form with a 0 byte (unlimited) field using the 6.3 version of the Admin tool (even if the server is 7.1), you can cut and paste or type several thousand characters (try about 4000). If you try to do the same thing in an Active Link, on the same form and field, with the 7.1 Admin Tool, it will not let you cut and paste and/or type more than about 1900 characters into the SET FIELDS action. Give it a shot. Truly fun. The problem is worse than thatyou can import such an Active Link onto a 7.1 server, no problem. You just can't modify the set fields itself. You can't run Remedy Developer Plus from the 7.1 Admin tool against it either. It will hang the minute it hits that active link. Fun times. You can imagine the run-around I got from BMC Support. I had to debug and solve this myself. Now...is this a bug in 7.1 or something BMC/Remedy "fixed" because it was "not working correctly" in 6.3? ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org <http://www.arslist.org/> Platinum Sponsor: www.rmsportal.com <http://www.rmsportal.com/> ARSlist: "Where the Answers Are" __Platinum Sponsor: www.rmsportal.com ARSlist: "Where the Answers Are" html___ ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org Platinum Sponsor: www.rmsportal.com ARSlist: "Where the Answers Are" NOTICE: This email message is for the sole use of the intended recipient(s) and may contain confidential and privileged information. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender by reply email and destroy all copies of the original message. ___
Re: Interesting "Bug" in 7.1
You are welcome... I actually do intend opening up a ticket as I have the def files to reproduce the issue. I didn't do it as like you I had a few things up my sleeve including a rollout of production after an upgrade so didn't think I'd have much time to follow it up with Remedy Support after opening up a ticket.. This is something I faced just about 3 weeks ago. I think I'll leave opening up a ticket with them when I come back to work next year.. Cheers Joe -Original Message- From: Action Request System discussion list(ARSList) [mailto:arsl...@arslist.org]on Behalf Of Carey Matthew Black Sent: Tuesday, December 23, 2008 9:07 AM To: arslist@ARSLIST.ORG Subject: Re: Interesting "Bug" in 7.1 Joe, I wish I had enough time to go back and figure out exactly what object was doing it. ( I would love to see the BUG get opened to get that fixed.) However, for now... the filters imported from the .def file. So I need to get moving on the other objects and hopefully get some testing going. Thanks again for the push in the right direction for the workaround. :) -- 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 Tue, Dec 23, 2008 at 8:44 AM, Joe D'Souza wrote: > ** > I can bet a few beers that there is a filter that has a run if qualification > that makes the XML file tag for that filter run miles towards the right hand > side of the page and that is the one that is causing them not to import. > > When I narrowed down to this AL that was causing my problem, I attempted to > export just that one AL, and then re-import it without modifying the XML > file at all and got the same error (Unable to send.) > > That's when I noticed that the only difference in that AL compared to the > tons of other AL's that successfully migrated, was the length of the AL > qualification. > > Joe > > PS: And it took me a day or so to find that out :-) On my first attempt I > thought I fubar'ed my XML def file somehow so took a second export and made > double sure I didn't do anything wrong while editing it, got the same error, > then started chomping the XML def file to bits and pieces importing each > piece at a time, finally till I got the offending AL.. So much FUN! > > -Original Message- > From: Action Request System discussion list(ARSList) > [mailto:arsl...@arslist.org]on Behalf Of Carey Matthew Black > Sent: Tuesday, December 23, 2008 7:57 AM > To: arslist@ARSLIST.ORG > Subject: Re: Interesting "Bug" in 7.1 > > > Joe, > > Now that is down right fascinating to me. > > We were having problems moving our forms from v6.3 (patch 22 or 25) to v7.1 > Patch5 unless we used the XML form of the object file. ( And now I am having > problems trying to get some of the filters to import in the XML form.) I > guess I will try the def file format and see if that works better. > > GR... > > In fairness however, we are also moving from Sybase to Oracle at the same > time we are moving from ARS v6.3 to v7.1 and moving from Solaris to Linux > too. So we have stumbled into a few other problems due that those other > layers changing too. > > G.. > > > But thanks for sharing the pain everyone. I now have a new path to test. :) > > > ccrashh, > > By the way... Are you also using Oracle as your RDBMS? The reason I ask is > that 4000 is a special number and we bumped into a problem with a Set field > Qualification trying to search a field that was longer than 4k in length. So > I wonder if your problems are more RDBMS centric than ARS centric. Just a > thought. > > -- > 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 Mon, Dec 22, 2008 at 1:31 PM, Joe DeSouza wrote: >> ** >> Wanna know another interesting bug? >> >> Try exporting an AL that has a really long Set Field If qualification as a >> .xml export, and then reimporting it again. The import will fail. I >> experienced that a couple of weeks ago and was beating my brains numb as >> to >> why the import was failing on that AL only and not others. And the only >> different thing about that AL compared to any other that exported and >> imported well was that qualification length. >> >> Exporting and importing it as a .def file, it has no problem. >> >> There is nothing wrong with the xml format but yet for some reason the >> import fails. The reason why I wanted a xml export and not a def, is that >> there were some
Re: Interesting "Bug" in 7.1
Joe, I wish I had enough time to go back and figure out exactly what object was doing it. ( I would love to see the BUG get opened to get that fixed.) However, for now... the filters imported from the .def file. So I need to get moving on the other objects and hopefully get some testing going. Thanks again for the push in the right direction for the workaround. :) -- 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 Tue, Dec 23, 2008 at 8:44 AM, Joe D'Souza wrote: > ** > I can bet a few beers that there is a filter that has a run if qualification > that makes the XML file tag for that filter run miles towards the right hand > side of the page and that is the one that is causing them not to import. > > When I narrowed down to this AL that was causing my problem, I attempted to > export just that one AL, and then re-import it without modifying the XML > file at all and got the same error (Unable to send.) > > That's when I noticed that the only difference in that AL compared to the > tons of other AL's that successfully migrated, was the length of the AL > qualification. > > Joe > > PS: And it took me a day or so to find that out :-) On my first attempt I > thought I fubar'ed my XML def file somehow so took a second export and made > double sure I didn't do anything wrong while editing it, got the same error, > then started chomping the XML def file to bits and pieces importing each > piece at a time, finally till I got the offending AL.. So much FUN! > > -Original Message- > From: Action Request System discussion list(ARSList) > [mailto:arsl...@arslist.org]on Behalf Of Carey Matthew Black > Sent: Tuesday, December 23, 2008 7:57 AM > To: arslist@ARSLIST.ORG > Subject: Re: Interesting "Bug" in 7.1 > > > Joe, > > Now that is down right fascinating to me. > > We were having problems moving our forms from v6.3 (patch 22 or 25) to v7.1 > Patch5 unless we used the XML form of the object file. ( And now I am having > problems trying to get some of the filters to import in the XML form.) I > guess I will try the def file format and see if that works better. > > GR... > > In fairness however, we are also moving from Sybase to Oracle at the same > time we are moving from ARS v6.3 to v7.1 and moving from Solaris to Linux > too. So we have stumbled into a few other problems due that those other > layers changing too. > > G.. > > > But thanks for sharing the pain everyone. I now have a new path to test. :) > > > ccrashh, > > By the way... Are you also using Oracle as your RDBMS? The reason I ask is > that 4000 is a special number and we bumped into a problem with a Set field > Qualification trying to search a field that was longer than 4k in length. So > I wonder if your problems are more RDBMS centric than ARS centric. Just a > thought. > > -- > 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 Mon, Dec 22, 2008 at 1:31 PM, Joe DeSouza wrote: >> ** >> Wanna know another interesting bug? >> >> Try exporting an AL that has a really long Set Field If qualification as a >> .xml export, and then reimporting it again. The import will fail. I >> experienced that a couple of weeks ago and was beating my brains numb as >> to >> why the import was failing on that AL only and not others. And the only >> different thing about that AL compared to any other that exported and >> imported well was that qualification length. >> >> Exporting and importing it as a .def file, it has no problem. >> >> There is nothing wrong with the xml format but yet for some reason the >> import fails. The reason why I wanted a xml export and not a def, is that >> there were some modifications I needed to do on the def file which is >> easier >> in the xml format than the def. >> >> Joe ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org Platinum Sponsor: www.rmsportal.com ARSlist: "Where the Answers Are"
Re: Interesting "Bug" in 7.1
Actually Steve, funny that you mention this.. We recently renamed a truck load of forms of an ITSP installation to facilitate the installation of SRM (which does not install with ITSP as there are similar form names in ITSP which creates a problem) Besides the problem you faced, we also faced other problems, which is why I was editing that .XML def file anyways. All Push field actions for some odd reason have the old form name embedded in the mapping information of both Filters and Active Links! (Escalations including) So although you may open that same filter or AL in the admin tool and find no reference to the old form name, the user tool catches it and errors out with a ARERR 303 as it tries to push information with the mapping information containing the old form name! If you export the def file, you will see that old form name embedded in it and the easiest way to clean it is to do an XML export and edit the XML file. I thought this information might be useful to you since you say you renamed your form.. Cheers Joe PS: PLEASE BE CAREFUL if you try to modify the def file in a .def format instead of .XML as then you will need to consider the altered length of the form that has been renamed unless the old length and the new length is the same... -Original Message- From: Action Request System discussion list(ARSList) [mailto:arsl...@arslist.org]on Behalf Of Steve Michadick Sent: Tuesday, December 23, 2008 7:20 AM To: arslist@ARSLIST.ORG Subject: Re: Interesting "Bug" in 7.1 Here's a couple more... ARS 7.1 patch 004 w/ ITSM 7.0.3 patch 008 - If you change the name of a form in the Admin Tool, your users will start getting a $MENU$ pattern matching error telling them that the value they selected from the menu doesn't match what is in the menu. We fixed this by removing the $MENU$ from the Pattern for each affected field. BMC Support told me that this is fixed in patch 005, but until then we just have to restart the services. When someone goes to create an Incident and manually selects values in the Incident Owner fields, but then deletes them out before saving the Incident, that ticket can no longer be modified. Selecting from the menus sets some hidden fields that are not cleared out when the menu fields are. These hidden fields are used in workflow to lock the ticket down. After disabling many AL's and Filters to get past this, we finally just had them recreate the ticket (leaving the Owner fields blank to be filled in by workflow) and then deleted the "dead" ticket. I suppose you could also unhide the offending fields and clear them out too. I'm going to create some workflow to keep this from happening in the first place. Of course, I've been told that this is a training issue that users shouldn't be entering and clearing out those fields, but you know users will do all sorts of things they aren't supposed to do. Steve Michadick Remedy Engineer MCNOSC -Original Message- From: Joe DeSouza [mailto:joe_rem...@yahoo.com] Sent: Monday, December 22, 2008 1:31 PM Subject: Re: Interesting "Bug" in 7.1 ** Wanna know another interesting bug? Try exporting an AL that has a really long Set Field If qualification as a .xml export, and then reimporting it again. The import will fail. I experienced that a couple of weeks ago and was beating my brains numb as to why the import was failing on that AL only and not others. And the only different thing about that AL compared to any other that exported and imported well was that qualification length. Exporting and importing it as a .def file, it has no problem. There is nothing wrong with the xml format but yet for some reason the import fails. The reason why I wanted a xml export and not a def, is that there were some modifications I needed to do on the def file which is easier in the xml format than the def. Joe From: ccrashh To: arslist@ARSLIST.ORG Sent: Monday, December 22, 2008 12:08:47 PM Subject: Interesting "Bug" in 7.1 If you create a SET FIELDS action in an Active Link on a form with a 0 byte (unlimited) field using the 6.3 version of the Admin tool (even if the server is 7.1), you can cut and paste or type several thousand characters (try about 4000). If you try to do the same thing in an Active Link, on the same form and field, with the 7.1 Admin Tool, it will not let you cut and paste and/or type more than about 1900 characters into the SET FIELDS action. Give it a shot. Truly fun. The problem is worse than thatyou can import such an Active Link onto a 7.1 server, no problem. You just can't modify the set fields itself. You can't run Remedy Developer Plus from the 7.1 Admin tool against it either. It will hang the minute it hits that active link. Fun times. You can imagine the run-around I got from BMC Support. I had to debug and solve this myself. Now...is this a bug in 7.1 or something
Re: Interesting "Bug" in 7.1
I can bet a few beers that there is a filter that has a run if qualification that makes the XML file tag for that filter run miles towards the right hand side of the page and that is the one that is causing them not to import. When I narrowed down to this AL that was causing my problem, I attempted to export just that one AL, and then re-import it without modifying the XML file at all and got the same error (Unable to send.) That's when I noticed that the only difference in that AL compared to the tons of other AL's that successfully migrated, was the length of the AL qualification. Joe PS: And it took me a day or so to find that out :-) On my first attempt I thought I fubar'ed my XML def file somehow so took a second export and made double sure I didn't do anything wrong while editing it, got the same error, then started chomping the XML def file to bits and pieces importing each piece at a time, finally till I got the offending AL.. So much FUN! -Original Message- From: Action Request System discussion list(ARSList) [mailto:arsl...@arslist.org]on Behalf Of Carey Matthew Black Sent: Tuesday, December 23, 2008 7:57 AM To: arslist@ARSLIST.ORG Subject: Re: Interesting "Bug" in 7.1 Joe, Now that is down right fascinating to me. We were having problems moving our forms from v6.3 (patch 22 or 25) to v7.1 Patch5 unless we used the XML form of the object file. ( And now I am having problems trying to get some of the filters to import in the XML form.) I guess I will try the def file format and see if that works better. GR... In fairness however, we are also moving from Sybase to Oracle at the same time we are moving from ARS v6.3 to v7.1 and moving from Solaris to Linux too. So we have stumbled into a few other problems due that those other layers changing too. G.. But thanks for sharing the pain everyone. I now have a new path to test. :) ccrashh, By the way... Are you also using Oracle as your RDBMS? The reason I ask is that 4000 is a special number and we bumped into a problem with a Set field Qualification trying to search a field that was longer than 4k in length. So I wonder if your problems are more RDBMS centric than ARS centric. Just a thought. -- 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 Mon, Dec 22, 2008 at 1:31 PM, Joe DeSouza wrote: > ** > Wanna know another interesting bug? > > Try exporting an AL that has a really long Set Field If qualification as a > .xml export, and then reimporting it again. The import will fail. I > experienced that a couple of weeks ago and was beating my brains numb as to > why the import was failing on that AL only and not others. And the only > different thing about that AL compared to any other that exported and > imported well was that qualification length. > > Exporting and importing it as a .def file, it has no problem. > > There is nothing wrong with the xml format but yet for some reason the > import fails. The reason why I wanted a xml export and not a def, is that > there were some modifications I needed to do on the def file which is easier > in the xml format than the def. > > Joe > > > From: ccrashh > To: arslist@ARSLIST.ORG > Sent: Monday, December 22, 2008 12:08:47 PM > Subject: Interesting "Bug" in 7.1 > > If you create a SET FIELDS action in an Active Link on a form with a 0 > byte (unlimited) field using the 6.3 version of the Admin tool (even > if the server is 7.1), you can cut and paste or type several thousand > characters (try about 4000). If you try to do the same thing in an > Active Link, on the same form and field, with the 7.1 Admin Tool, it > will not let you cut and paste and/or type more than about 1900 > characters into the SET FIELDS action. Give it a shot. Truly fun. > > The problem is worse than thatyou can import such an Active Link > onto a 7.1 server, no problem. You just can't modify the set fields > itself. > > You can't run Remedy Developer Plus from the 7.1 Admin tool against it > either. It will hang the minute it hits that active link. > > Fun times. You can imagine the run-around I got from BMC Support. I > had to debug and solve this myself. > > Now...is this a bug in 7.1 or something BMC/Remedy "fixed" because it > was "not working correctly" in 6.3? No virus found in this outgoing message. Checked by AVG. Version: 7.5.552 / Virus Database: 270.10.0/1861 - Release Date: 12/22/2008 11:23 AM ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org Platinum Sponsor: www.rmsportal.com ARSlist: "Where the Answers Are"
Re: Interesting "Bug" in 7.1
Joe, Now that is down right fascinating to me. We were having problems moving our forms from v6.3 (patch 22 or 25) to v7.1 Patch5 unless we used the XML form of the object file. ( And now I am having problems trying to get some of the filters to import in the XML form.) I guess I will try the def file format and see if that works better. GR... In fairness however, we are also moving from Sybase to Oracle at the same time we are moving from ARS v6.3 to v7.1 and moving from Solaris to Linux too. So we have stumbled into a few other problems due that those other layers changing too. G.. But thanks for sharing the pain everyone. I now have a new path to test. :) ccrashh, By the way... Are you also using Oracle as your RDBMS? The reason I ask is that 4000 is a special number and we bumped into a problem with a Set field Qualification trying to search a field that was longer than 4k in length. So I wonder if your problems are more RDBMS centric than ARS centric. Just a thought. -- 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 Mon, Dec 22, 2008 at 1:31 PM, Joe DeSouza wrote: > ** > Wanna know another interesting bug? > > Try exporting an AL that has a really long Set Field If qualification as a > .xml export, and then reimporting it again. The import will fail. I > experienced that a couple of weeks ago and was beating my brains numb as to > why the import was failing on that AL only and not others. And the only > different thing about that AL compared to any other that exported and > imported well was that qualification length. > > Exporting and importing it as a .def file, it has no problem. > > There is nothing wrong with the xml format but yet for some reason the > import fails. The reason why I wanted a xml export and not a def, is that > there were some modifications I needed to do on the def file which is easier > in the xml format than the def. > > Joe > > > From: ccrashh > To: arslist@ARSLIST.ORG > Sent: Monday, December 22, 2008 12:08:47 PM > Subject: Interesting "Bug" in 7.1 > > If you create a SET FIELDS action in an Active Link on a form with a 0 > byte (unlimited) field using the 6.3 version of the Admin tool (even > if the server is 7.1), you can cut and paste or type several thousand > characters (try about 4000). If you try to do the same thing in an > Active Link, on the same form and field, with the 7.1 Admin Tool, it > will not let you cut and paste and/or type more than about 1900 > characters into the SET FIELDS action. Give it a shot. Truly fun. > > The problem is worse than thatyou can import such an Active Link > onto a 7.1 server, no problem. You just can't modify the set fields > itself. > > You can't run Remedy Developer Plus from the 7.1 Admin tool against it > either. It will hang the minute it hits that active link. > > Fun times. You can imagine the run-around I got from BMC Support. I > had to debug and solve this myself. > > Now...is this a bug in 7.1 or something BMC/Remedy "fixed" because it > was "not working correctly" in 6.3? ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org Platinum Sponsor: www.rmsportal.com ARSlist: "Where the Answers Are"
Re: Interesting "Bug" in 7.1
Here's a couple more... ARS 7.1 patch 004 w/ ITSM 7.0.3 patch 008 - If you change the name of a form in the Admin Tool, your users will start getting a $MENU$ pattern matching error telling them that the value they selected from the menu doesn't match what is in the menu. We fixed this by removing the $MENU$ from the Pattern for each affected field. BMC Support told me that this is fixed in patch 005, but until then we just have to restart the services. When someone goes to create an Incident and manually selects values in the Incident Owner fields, but then deletes them out before saving the Incident, that ticket can no longer be modified. Selecting from the menus sets some hidden fields that are not cleared out when the menu fields are. These hidden fields are used in workflow to lock the ticket down. After disabling many AL's and Filters to get past this, we finally just had them recreate the ticket (leaving the Owner fields blank to be filled in by workflow) and then deleted the "dead" ticket. I suppose you could also unhide the offending fields and clear them out too. I'm going to create some workflow to keep this from happening in the first place. Of course, I've been told that this is a training issue that users shouldn't be entering and clearing out those fields, but you know users will do all sorts of things they aren't supposed to do. Steve Michadick Remedy Engineer MCNOSC -Original Message- From: Joe DeSouza [mailto:joe_rem...@yahoo.com] Sent: Monday, December 22, 2008 1:31 PM Subject: Re: Interesting "Bug" in 7.1 ** Wanna know another interesting bug? Try exporting an AL that has a really long Set Field If qualification as a .xml export, and then reimporting it again. The import will fail. I experienced that a couple of weeks ago and was beating my brains numb as to why the import was failing on that AL only and not others. And the only different thing about that AL compared to any other that exported and imported well was that qualification length. Exporting and importing it as a .def file, it has no problem. There is nothing wrong with the xml format but yet for some reason the import fails. The reason why I wanted a xml export and not a def, is that there were some modifications I needed to do on the def file which is easier in the xml format than the def. Joe From: ccrashh To: arslist@ARSLIST.ORG Sent: Monday, December 22, 2008 12:08:47 PM Subject: Interesting "Bug" in 7.1 If you create a SET FIELDS action in an Active Link on a form with a 0 byte (unlimited) field using the 6.3 version of the Admin tool (even if the server is 7.1), you can cut and paste or type several thousand characters (try about 4000). If you try to do the same thing in an Active Link, on the same form and field, with the 7.1 Admin Tool, it will not let you cut and paste and/or type more than about 1900 characters into the SET FIELDS action. Give it a shot. Truly fun. The problem is worse than thatyou can import such an Active Link onto a 7.1 server, no problem. You just can't modify the set fields itself. You can't run Remedy Developer Plus from the 7.1 Admin tool against it either. It will hang the minute it hits that active link. Fun times. You can imagine the run-around I got from BMC Support. I had to debug and solve this myself. Now...is this a bug in 7.1 or something BMC/Remedy "fixed" because it was "not working correctly" in 6.3? ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org <http://www.arslist.org/> Platinum Sponsor: www.rmsportal.com <http://www.rmsportal.com/> ARSlist: "Where the Answers Are" __Platinum Sponsor: www.rmsportal.com ARSlist: "Where the Answers Are" html___ ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org Platinum Sponsor: www.rmsportal.com ARSlist: "Where the Answers Are"
Re: Interesting "Bug" in 7.1
Wanna know another interesting bug? Try exporting an AL that has a really long Set Field If qualification as a .xml export, and then reimporting it again. The import will fail. I experienced that a couple of weeks ago and was beating my brains numb as to why the import was failing on that AL only and not others. And the only different thing about that AL compared to any other that exported and imported well was that qualification length. Exporting and importing it as a .def file, it has no problem. There is nothing wrong with the xml format but yet for some reason the import fails. The reason why I wanted a xml export and not a def, is that there were some modifications I needed to do on the def file which is easier in the xml format than the def. Joe From: ccrashh To: arslist@ARSLIST.ORG Sent: Monday, December 22, 2008 12:08:47 PM Subject: Interesting "Bug" in 7.1 If you create a SET FIELDS action in an Active Link on a form with a 0 byte (unlimited) field using the 6.3 version of the Admin tool (even if the server is 7.1), you can cut and paste or type several thousand characters (try about 4000). If you try to do the same thing in an Active Link, on the same form and field, with the 7.1 Admin Tool, it will not let you cut and paste and/or type more than about 1900 characters into the SET FIELDS action. Give it a shot. Truly fun. The problem is worse than thatyou can import such an Active Link onto a 7.1 server, no problem. You just can't modify the set fields itself. You can't run Remedy Developer Plus from the 7.1 Admin tool against it either. It will hang the minute it hits that active link. Fun times. You can imagine the run-around I got from BMC Support. I had to debug and solve this myself. Now...is this a bug in 7.1 or something BMC/Remedy "fixed" because it was "not working correctly" in 6.3? ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org Platinum Sponsor: www.rmsportal.com ARSlist: "Where the Answers Are" ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org Platinum Sponsor: www.rmsportal.com ARSlist: "Where the Answers Are"
Interesting "Bug" in 7.1
If you create a SET FIELDS action in an Active Link on a form with a 0 byte (unlimited) field using the 6.3 version of the Admin tool (even if the server is 7.1), you can cut and paste or type several thousand characters (try about 4000). If you try to do the same thing in an Active Link, on the same form and field, with the 7.1 Admin Tool, it will not let you cut and paste and/or type more than about 1900 characters into the SET FIELDS action. Give it a shot. Truly fun. The problem is worse than thatyou can import such an Active Link onto a 7.1 server, no problem. You just can't modify the set fields itself. You can't run Remedy Developer Plus from the 7.1 Admin tool against it either. It will hang the minute it hits that active link. Fun times. You can imagine the run-around I got from BMC Support. I had to debug and solve this myself. Now...is this a bug in 7.1 or something BMC/Remedy "fixed" because it was "not working correctly" in 6.3? ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org Platinum Sponsor: www.rmsportal.com ARSlist: "Where the Answers Are"
