And I remember reading somewhere that Oracle with "case-insensitivity"
enabled caused a large volume of highly inefficient "table scans"...in
other words it wasn't using the indexes at all.  Perhaps that was
someone who had tried to switch after the initial installation of the
database.

 

We are on Oracle 10g and we have purchased Full Text Search licenses.
What I've discovered with FTS is that you can leverage the feature on
lookup fields by making the setting "Index for FTS" on the target field:
in other words, we set First Name and Last Name on the CTM:People form
to "Index for FTS" and all of the forms that lookup by name from that
table worked as you described in your MacDOUgal scenario.  Trouble is
that I haven't figured out how to enable FTS on MENUS.  Either character
or form-based.  I would like for the Company field or the Product field
to be case insensitive and that just doesn't seem to be possible.

 

One more problem that we found was that the Change Management module
started throwing ARERR 314 errors when performing a search with FTS
enabled on the server.  We can't find any fields or workflow that may be
causing this and disabling FTS cures it.  I'm trying to get my support
partner to open a defect with BMC.

 

Best of luck,

Gp

 

George Payne

Corporate Applications Developer

Electric Reliability Council of Texas

(512) 248-3940

[EMAIL PROTECTED]

________________________________

From: Action Request System discussion list(ARSList)
[mailto:[EMAIL PROTECTED] On Behalf Of Rick Cook
Sent: Wednesday, February 13, 2008 2:14 PM
To: arslist@ARSLIST.ORG
Subject: Re: Remedy and Database choices.

 

** Oracle can be set up as case-insensitive starting with v10 (it might
have been possible with 9i).  BUT, as was noted above, you have to
specify it when you create the DB.  Once that's done, there's no
changing that option.

Rick

On Feb 13, 2008 11:58 AM, Frank Caruso <[EMAIL PROTECTED]> wrote:

Sybase 12.5 is case insensitive and i also think there is way to
configure Oracle to be the same.


On Feb 13, 2008 2:53 PM, Roger Justice <[EMAIL PROTECTED]> wrote:
> ** MS SQL Server can be configured on install as case sensitive. The
FTS on
> ARS 7 will allow on a Character field what you are requesting.
>
>
>
>
>  -----Original Message-----
>  From: Chapin, John <[EMAIL PROTECTED]>
>  To: arslist@ARSLIST.ORG
>  Sent: Wed, 13 Feb 2008 2:27 pm
>  Subject: Remedy and Database choices.
>
>
> **
>         Howdy, listerz...   we're having the darndest time trying to
build a
> new Remedy environment.  We'd like to be able to run Remedy on Linux
or
> Solaris servers, but we're currently running Windows with a MS-SQL
database.
>         Here's what I've learned....   do I have this right...?
(This is
> meant as a question, open for comment.)    thanks --
>         If your Remedy Db is MS-SQL, they will enjoy case-insensitive
> searches.  This means that if they type "macdougal" in the Name+
field, and
> then press "F-5", the search will return all tickets opened by either
"James
> MacDougal" or "Sarah Macdougal", or even "Albert MACdOugAl"
>         If a user types "macdougal" in Name+, and presses ENTER, a
pick-list
> of all "MacDougals" from the People table will appear.
>         This is good.
>
>          If instead you have Sybase or Oracle, users will NOT have
> case-insensitive searches.  If a user types "macdougal" in the Name+
field,
> they will return none of the aforementioned users.
>         Furthermore, if they type "macdougal" in Name+,  and press
F-5,  you
> will not get any matches for any of the "MacDougal"s which are in
> SHR:People.
>         When building new Remedy environments, this is a potentially
huge
> "GOTCHA"...   it makes it just about impossible to switch from MS-SQL
to
> either Sybase or Oracle without having to tell your users about the
whole
> case sensitivity thing.
>         This is baaaad.
>         The "Full Text Search License" does not impact this
case-sensitivity
> issue.
>
>
>
>
>  -----------------------------------------
>  The information contained in this transmission may be privileged and
>  confidential and is intended only for the use of the person(s) named
>  above. If you are not the intended recipient, or an employee or agent
> responsible
>  for delivering this message to the intended recipient, any review,
> dissemination,
>  distribution or duplication of this communication is strictly
prohibited.
> If you are
>  not the intended recipient, please contact the sender immediately by
reply
> e-mail
>  and destroy all copies of the original message. Please note that we
do not
> accept
>  account orders and/or instructions by e-mail, and therefore will not
be
> responsible
>  for carrying out such orders and/or instructions.  If you, as the
intended
> recipient
>  of this message, the purpose of which is to inform and update our
clients,
> prospects
>  and consultants of developments relating to our services and
products,
> would not
>  like to receive further e-mail correspondence from the sender, please
> "reply" to the
>  sender indicating your wishes.  In the U.S.: 1345 Avenue of the
Americas,
> New York,
>  NY 10105.__Platinum Sponsor: www.rmsportal.com ARSlist: "Where the
Answers
> Are" html___
>  ________________________________
>  More new features than ever. Check out the new AOL Mail!
>
>
>  __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"


__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"

Reply via email to