Hi,
I am just guessing here though...
If you do a search to a case-insensitive database, the case should not
matter. I wonder though if a Unique Index will prevent the records "AA"
and "aa" to be created parallel.
Another issue is filter run ifs such as ('field1' = 'field2') which may
not be case insensitive as it has nothing to do with a database search.
Best Regards - Misi, RRR AB, http://www.rrr.se
Products from RRR Scandinavia:
* RRR|License - Not enough Remedy licenses? Save money by optimizing.
* RRR|Log - Performance issues or elusive bugs? Analyze your Remedy logs.
Find these products, and many free tools and utilities, at http://rrr.se.
> Regarding case sensitivity... My coworker believes that we keep running
> into case sensitivity issues somewhere in the process of bringing in CIs
> (a
> dataset per source), identifying, normalizing and merging. We have
> stopped
> normalizing just to rule that out.
>
> I have looked through the documents and have not found anything to
> indicate
> any of the Atrium components are case sensitive. I have a hard time
> believing that a product designed to gather data from many sources,
> identify
> and reconcile would be case sensitive.
>
> Has anybody experienced case issues with any of the Atrium components?
>
> Jason
>
> On Wed, Aug 11, 2010 at 5:11 PM, Chowdhury, Tauf
> <[email protected]>wrote:
>
>> **
>>
>> Jason,
>> Not sure what NE and RE is but if you are using an AIE data exchange, is
>> your Primary Key field the MAC attribute? If not, then that could
>> possibly
>> be why you see duplicates. Also, are there duplicates in the source or
>> are
>> there only duplicates after you do a Reconciliation? Actually, is the
>> duplicate CI in the staging dataset or in BMC.ASSET? If it is in the
>> staging
>> dataset (the temp dataset where CI's are put into after AIE pulls from
>> the
>> source), then perhaps it is an AIE mapping issue or just eliminate the
>> dupes
>> from the source if you can. However, if the dupe is getting created in
>> BMC.ASSET only after you do your reconciliation, then I would check the
>> identification rules to make sure you are identifying correctly and CMDB
>> doesn't think that you are merging a new record every time.
>>
>>
>>
>> -----Original Message-----
>> From: Action Request System discussion list(ARSList) on behalf of Jason
>> Miller
>> Sent: Wed 8/11/2010 6:27 PM
>> To: [email protected]
>> Subject: Atrium Core case sensitive?
>>
>> Hello everybody,
>>
>> We are fairly new to CMDB/AIE/NE/RE. We are having issues with CIs from
>> different import sources not identifying as the same CI. Our database
>> is
>> MS
>> SQL and is configured as case insensitive. We are now looking to see if
>> case sensitivity is an issue. For example we will get duplicate MAC CIs
>> in
>> the production dataset for 001B783ED321 and 001b783ed321 after an ID and
>> Merge.
>>
>> What are we missing. Are there any components in the Atrium Core that
>> are
>> case sensitive?
>>
>> Thanks,
>> Jason
>>
>> ARS 7.5 p5 (before the bad one)
>> Atrium Core 7.6 p2
>> ITSM 7.6 p1
>> MS SQL 2008 64 bit
>> Win 2008 64 bit
>>
>>
>> _______________________________________________________________________________
>> UNSUBSCRIBE or access ARSlist Archives at www.arslist.org
>> attend wwrug10 www.wwrug.com ARSlist: "Where the Answers Are"
>>
>> ------------------------------
>> This e-mail and its attachments may contain Forest Laboratories, Inc.
>> proprietary information that is privileged, confidential or subject to
>> copyright belonging to Forest Laboratories, Inc. This e-mail is intended
>> solely for the use of the individual or entity to which it is addressed.
>> If
>> you are not the intended recipient of this e-mail, or the employee or
>> agent
>> responsible for delivering this e-mail to the intended recipient, you
>> are
>> hereby notified that any dissemination, distribution, copying or action
>> taken in relation to the contents of and attachments to this e-mail is
>> strictly prohibited and may be unlawful. If you have received this
>> e-mail in
>> error, please notify the sender immediately and permanently delete the
>> original and any copy of this e-mail and any printout.
>> _attend WWRUG10 www.wwrug.com ARSlist: "Where the Answers Are"_
>
> _______________________________________________________________________________
> UNSUBSCRIBE or access ARSlist Archives at www.arslist.org
> attend wwrug10 www.wwrug.com ARSlist: "Where the Answers Are"
>
> --
> This message was scanned by ESVA and is believed to be clean.
>
>
_______________________________________________________________________________
UNSUBSCRIBE or access ARSlist Archives at www.arslist.org
attend wwrug10 www.wwrug.com ARSlist: "Where the Answers Are"
