I would go with Kaiser... Do not create a record everytime it is modified.. Have a temp field to pull the record ID if that record has already been created. So if that temp field is not null do nothing else create that record if that temp field is null..
Cheers Joe -----Original Message----- From: Action Request System discussion list(ARSList) [mailto:[EMAIL PROTECTED] Behalf Of Kaiser Norm E CIV USAF 96 CS/SCCE Sent: Friday, September 28, 2007 2:11 PM To: [email protected] Subject: Re: Unique ID? Well how about instead of creating a record on each and every modify you only create a record if a record for the desired time period does not already exist? -----Original Message----- From: Action Request System discussion list(ARSList) [mailto:[EMAIL PROTECTED] On Behalf Of Wheeler, Dylan Sent: Friday, September 28, 2007 12:43 PM To: [email protected] Subject: Re: Unique ID? ** Yeah, that's the problem Ben. Lets say they run a search for all the records that were modified between 09/01/2007 and 09/14/2007. A record could be modified 5 times on 5 different days and so it would show up in the search 5 times. I just wish I could do a distinct join, which it looks like I'm not being slow today, it's just not possible without using a table field and direct sql. It would be easy if I could just create them a report in crystal but there are just too many user variables that they need to be able to input Dylan -----Original Message----- From: Action Request System discussion list(ARSList) [mailto:[EMAIL PROTECTED] On Behalf Of Ben Cantatore Sent: Friday, September 28, 2007 10:30 AM To: [email protected] Subject: Re: Unique ID? ** I honestly believe that hiding duplicates should be done at the reporting level. Create 2 groups, one for the ticket and the subgroup would be the time increments (ie months, days, hours... whichever you're trying to report on.) If you really insist that it be done on the form level, then I'd modify your existing workflow. Assuming days, meaning you don't care for the time portion of the timestamp, I'd have the ticket/date only (no timestamp) as the link between parent and child. That way, if its a new day or different incident, new record gets created. Same day, same incident, update the existing record. So the result is you can update incident xyz 15 times in a day, and only one child record is recorded. If you update that same incident the next day, a new child recorded is created. Hope that helps, Ben Cantatore Remedy Administrator Avon (914) 935-2946 "Wheeler, Dylan" <[EMAIL PROTECTED]> Sent by: "Action Request System discussion list(ARSList)" <[email protected]> 09/28/2007 12:17 PM Please respond to [email protected] To [email protected] cc Subject Unique ID? ** Maybe it's too early in the day but I can't get my head wrapped around a problem. A group here needs to keep track of when records in a form gets modified. They want to be able to search for a date range and come up with the records modified in that date range. Simple enough. The problem I run into is if a record gets updated a month ago, then it gets updated today. If they do their time search for the records that were updated a month ago, it wont show in that list. So I created a table, every time the record gets modified it pushes to a new table and creates a timestamp record. Created a join form between the parent and the timestamp form. Works great except I can't get it to show me only unique records. So if a record gets modified twice in a time period, when they do their search on my join, it will show two of that record. Am I going about this the wrong way? Like Joe I'm trying to stay away from the coffee and tea just doesn't have that same bite heh ------------- Dylan Wheeler Production Control Analyst Principal IT Operations Downey Savings & Loan Association, F.A. Email: [EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]> This message and any attachments are for the intended recipient(s) only and may contain privileged, confidential and/or proprietary information about Downey Savings or its customers, which Downey Savings does not intend to disclose to the public. If you received this message by mistake, please notify the sender by reply e-mail and delete the message and attachments. No virus found in this outgoing message. Checked by AVG Free Edition. Version: 7.5.488 / Virus Database: 269.13.33/1034 - Release Date: 9/27/2007 5:00 PM _______________________________________________________________________________ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org ARSlist:"Where the Answers Are"
