Thanks for the info Misi. The only Unique Index on the
BMC.CORE:BMC_BaseElement form is on InstanceId. I wouldn't think InstanceId
would be considered when comparing CIs.
In your example of ('field1' = 'field2'), if it doesn't involve a db search
then it would be ARS that is case sensitive? Is ARS case sensitive in a
situation like this? I have never noticed any case sensitivity behavior
when working with a case insensitive db.
I wouldn't be surprised to see some case sensitive behaviors with more and
more tasks being handed off to java plug-ins. That is why I was questioning
the Atrium Core components specifically.
Jason
On Sun, Aug 15, 2010 at 3:17 AM, Misi Mladoniczky <m...@rrr.se> wrote:
> 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
> > <tauf.chowdh...@frx.com>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: arslist@ARSLIST.ORG
> >> 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"
>
_______________________________________________________________________________
UNSUBSCRIBE or access ARSlist Archives at www.arslist.org
attend wwrug10 www.wwrug.com ARSlist: "Where the Answers Are"
