Hey Axton ... I was told ARS 7.0.1 patch 7 or greater fixes this issue ... Thanks,
Sean -----Original Message----- From: Action Request System discussion list(ARSList) [mailto:[EMAIL PROTECTED] On Behalf Of Axton Sent: Thursday, July 24, 2008 10:06 PM To: [email protected] Subject: Re: Possible Outer Join Bug ....Can anyone confirm or know if there is a fix? An update, I've received the following stack traces during the reproduction of this or something similar. Two signal 11's. As a side note, one thing I think Remedy needs is the ability to define joins with multiple data sources. Take the join in this example, the base tables and the largest join are the only data sets I need. All of the other joins are just clutter. This feature should even be bundled with the ability to support unions, aggregate functions, column concatenation, and all of the other things that are possible on every db that Remedy runs on. Axton Grams Environment Information: SunOS 5.9 Generic_122300-25 sun4u sparc SUNW,Sun-Fire-V445 Oracle instant client 10.2.0.3-20070101 ARServer 7.0.1 patch 1 200701111654 The eid's that cause the crash use this format: x|x|y|y|z|| x^x -> inner y^y -> inner x|x^y|y -> inner x|x|y|y^z -> outer x|x|y|y|z^null -> outer Thu Jul 24 16:24:51 2008 390620 : AR System server terminated when a signal/exception was received by the server (ARNOTE 20) Thu Jul 24 16:24:51 2008 11 Timestamp: Thu Jul 24 2008 16:24:51.8924 Thread Id: 8 Version: 7.0.01 patch 001 200701111654 Jan 11 2007 17:30:06 ServerName: yyy Database: SQL -- Oracle Hardware: sun4u OS: SunOS 5.9 RPC Id: 1079 RPC Call: 1 (GE) RPC Queue: 390620 Client: User xxx from Remedy User (protocol 12) at IP address z.z.z.z Form: zzz Logging On: User Stacks: /prod/sys/remedy/bin/arserverd:DumpStackTrace+0x88 /prod/sys/remedy/bin/arserverd:SignalTrapProc+0x160 /usr/lib/libthread.so.1:0x156c8 /usr/lib/libthread.so.1:0xf320 /usr/lib/libthread.so.1:0xf4d0 /usr/lib/libc.so.1:0x475b4 [ Signal 11 (SEGV)] /usr/lib/libc.so.1:0x47d88 /usr/lib/libc.so.1:0x46eb4 /usr/lib/libc.so.1:malloc+0x20 /prod/sys/remedy/bin/arserverd:ResizeArray+0x50 /prod/sys/remedy/bin/arserverd:StencilARFieldValueList+0x84 /prod/sys/remedy/bin/arserverd:argetentry_12_svc+0xf5c /prod/sys/remedy/bin/arserverd:HandleRPCs+0x134e0 /prod/sys/remedy/bin/arserverd:WorkerThread+0x5f4 /prod/sys/remedy/bin/arserverd:RestartableThreadMain+0x60 /prod/sys/remedy/bin/arserverd:UnixThreadStartRoutine+0xe8 /usr/lib/libthread.so.1:0x15370 Thu Jul 24 16:18:03 2008 390620 : AR System server terminated when a signal/exception was received by the server (ARNOTE 20) Thu Jul 24 16:18:03 2008 11 Timestamp: Thu Jul 24 2008 16:18:03.9875 Thread Id: 9 Version: 7.0.01 patch 001 200701111654 Jan 11 2007 17:30:06 ServerName: xxx Database: SQL -- Oracle Hardware: sun4u OS: SunOS 5.9 RPC Id: 495 RPC Call: 1 (GE) RPC Queue: 390620 Client: User zzz from Remedy User (protocol 12) at IP address y.y.y.y Form: aaa Logging On: User Stacks: /prod/sys/remedy/bin/arserverd:DumpStackTrace+0x88 /prod/sys/remedy/bin/arserverd:SignalTrapProc+0x160 /usr/lib/libthread.so.1:0x156c8 /usr/lib/libthread.so.1:0xf320 /usr/lib/libthread.so.1:0xf4d0 /usr/lib/libc.so.1:0x47884 [ Signal 11 (SEGV)] /usr/lib/libc.so.1:0x47518 /usr/lib/libc.so.1:0x47d04 /usr/lib/libc.so.1:free+0x20 /prod/sys/remedy/bin/arserverd:FreeAREntryIdList+0x3c /prod/sys/remedy/bin/arserverd:FreeARSchemaContextStruct+0x20 /prod/sys/remedy/bin/arserverd:FreeARSchemaContextList+0x28 /prod/sys/remedy/bin/arserverd:argetentry_12_svc+0xf78 /prod/sys/remedy/bin/arserverd:HandleRPCs+0x134e0 /prod/sys/remedy/bin/arserverd:WorkerThread+0x5f4 /prod/sys/remedy/bin/arserverd:RestartableThreadMain+0x60 /prod/sys/remedy/bin/arserverd:UnixThreadStartRoutine+0xe8 /usr/lib/libthread.so.1:0x15370 On Mon, Jul 7, 2008 at 4:14 PM, Axton <[EMAIL PROTECTED]> wrote: > IMHO, anything that causes arserverd to crash (segfault, etc.) is a defect. > > Axton Grams > > On Mon, Jul 7, 2008 at 2:54 PM, Garrison, Sean (Norcross) > <[EMAIL PROTECTED]> wrote: >> ** >> >> I have designed a table that will be used to determine impact: >> >> >> >> Impact Table >> >> __________ >> >> Id >> >> ProductID >> >> ClientID >> >> >> >> Data in this table looks like this: >> >> >> >> ID ProductID ClientID >> >> 1 1 1 >> >> 2 NULL 2 >> >> >> >> Product ID maps to the Instance ID in AST:BusinessService and ClientID maps >> to AST:Organization. We have scenerios where a Client can be impacted but >> no products are actually affected. In order to do this I have to use outer >> joins. AST:BusinessService is outer joined to Impact table. The resulting >> AST:BusinessServiceToImpactTable_Join form is then outer joined to >> AST:Organization. So the data for example would look like this: >> >> >> >> RequestID ProductName Product ID ClientName >> Client ID >> >> 1|1|1 Product1 >> 1 Client1 1 >> >> 2|NULL|2 NULL NULL >> Client2 2 >> >> >> >> **Note the "NULL" values are actual NULLs and not the word "NULL". The two >> joins exist just to pull in the names. >> >> >> >> The problem I am encountering is this: >> >> >> >> If I select the "2|NULL|2" record the arserverd will do a hard crash. In my >> opinion this is a Remedy bug. It should allow for outer joins like this. >> >> >> >> Here is an actual request ID of a join form that is causing the crash: >> >> >> >> 000000000000197||000000000018595|000000000021403|000000000018595|000000000021403 >> >> >> >> Notice the "||"???? >> >> >> >> I am doing it this way to normalize the data. I shouldn't have to copy the >> names into my impact table. That makes no sense to me but I do have a >> workaround (Oracle View). >> >> >> >> I am on ARS 7.01 patch 6 (Linux) on Oracle 10g. Has anyone encountered this >> issue before and if so do they know if there is a later patch that fixes it? >> >> >> >> Thanks, >> >> >> >> Sean >> >> >> >> __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" _______________________________________________________________________________ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org Platinum Sponsor: www.rmsportal.com ARSlist: "Where the Answers Are"
