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"
