10 Replies Latest reply on Apr 10, 2020 11:46 PM by Stefan Hall

    Experience with Switch from Case Insensitive to Case Sensitive Implementation

    Peter Adams
      Share This:

      Hello Remedy Community,

       

      I'm looking for customers / partners who have first-hand experience with moving from a Case Insensitive to a Case Sensitive implementation of Remedy, e.g. due to database change. 

      Trying to understand what the user feedback was for such change, and what specific steps were done to minimize / address any negative impact.

      Feel free to comment here or to reach out to me directly by sending a message to Peter Adams

       

      Thanks,

       

      Peter

       

      Remedy AR System

        • 1. Re: Experience with Switch from Case Insensitive to Case Sensitive Implementation
          Stefan Hall

          Peter, good idea.  We've always relied on case insensitive searches and since version 7.6.04 we've seen practically every problem.  Over time it has gotten a little better, but there is still a lot of room for improvement.  I'll briefly sort through and then add our points here.

           

          Thank you very much for your impulse.

          • 2. Re: Experience with Switch from Case Insensitive to Case Sensitive Implementation
            Eric Wuensche

            Hi Peter Adams,

             

            Unfortunately we could only provide feedback for the other way round (which we did lately again with some frustration). I would not even try to go back. And if I would be forced to do so by a software change, I would try to do anything to prohibit it. I am only aware of frustrated users who had to use a case-sensitive system.

             

            Stefan Hall maybe there should be a counter question for the experiences with moves from case-sensitive to case-insensitive (Or a link to one which might already be existing).

             

            best regards

            Eric

            • 3. Re: Experience with Switch from Case Insensitive to Case Sensitive Implementation
              Stefan Hall

              Eric Wuensche

              Hmm, you're right.  I got Peter's question backwards.  My mistake, but anyway, I write my experiences here anyway, maybe someone will take care of the system weaknesses.

              • 4. Re: Experience with Switch from Case Insensitive to Case Sensitive Implementation
                Peter Adams

                Thanks, Stefan, Eric.  Did anyone ever go from case insensitive to case sensitive?

                • 5. Re: Experience with Switch from Case Insensitive to Case Sensitive Implementation
                  Carl Wilson

                  Hi Peter,

                  I have not heard of anyone going that direction, only from sensitive to insensitive.

                  Wondering why an organization would want to do this, seems like a backwards step.

                   

                  Cheers

                  Carl

                  1 of 1 people found this helpful
                  • 6. Re: Experience with Switch from Case Insensitive to Case Sensitive Implementation
                    Stefan Hall

                    Peter,

                    I'm still amazed that you put the question that way. I really know many customers in Germany, Austria, Switzerland and nobody has ever asked this question. Imagine that the Google search is case sensitive... bmc, Bmc, bMc, bmC, BMc, bMC, BmC, bMc... you hide almost everything. Is it really a relevant use case?

                    But many customers ask the other way round, as soon as special characters play a role or users don't want to know which upper/lower case errors other users have entered. Unfortunately, the implementation of the functional indexes is still not really stable and a bit buggy. Let me explain it briefly:

                     

                    1. in the AR base configuration (CCS, ar.conf) you can set case insensitive and functional indexes. But you cannot define the index type.
                      At server startup the ARServer always sets "BINARY_CI" hard coded first and even overwrites a correct db_trigger settings like "BINARY_AI".

                    2. In the past there was a db.conf file where you could set special DB parameters, i.e. "BINARY_AI". Now it would be integrated into CCS, first per server and then only as a shared paramter for all servers. But the shared parameter does not work since its introduction (tested until version19.02), you have to set it additionally in the AR Server configuration as a workaround.
                      Not bad you think? Please keep in mind that the installers occasionally change the server name (switch between FQDN and not FQDN). In these cases new records are created in the CCS and the shared DB parameter does not work!! The installer creates all new forms, indexes again hard coded with the wrong "BINARY_CI". This may not be noticeable in the USA, but with all functional indexes <> BINARY_CI it is a small catastrophe and a lot of manual rework.

                      Even if everything works, the setting changes unnecessarily often at every server start for every process:
                      BINARY_AI (from DB configuration or DB trigger) > BINARY_CI [hard coded) > BINARY_AI (only if set via AR configuration).

                      I hope you understand that this is a relevant system weakness and the solution would be so simple. Another real ar.conf parameter in addition to the index setting "db-functional-Index" to specify the desired index type like BINARY_AI. Then only the hard coded setting needs to be replaced and everything would be much more secure.

                    3. This leaves the problem of ITSM indexes that are much too long and cannot be created as functional indexes. Ok, you could outsource the indexes and achieve something there by using larger blocksize. But if you look closely, these indexes are regularly superfluous in this form and can be designed shorter without any loss. At the moment, this is a lot aof manual work and only possible directly at DB level and thus not at the system.

                     

                    So if you don't get an answer to your question here because the need is not there, everyone else would be happy about a better, more stable implementation of the case insensitive method.

                     

                    Stefan

                     

                    04/10/20 - optical improvement, obviously can't handle the iPad - can't get shift+enter for new line

                    1 of 1 people found this helpful
                    • 7. Re: Experience with Switch from Case Insensitive to Case Sensitive Implementation
                      Samo Puharic

                      I would add problems with upgrade if you have functional indexes in place.

                      After so much time spent in debugging with BMC support (unsuccessful) we revert to normal indexes and do the upgrade with normal indexes.

                       

                      Functional indexes are so much pain.

                      We advise our customers only DB which natively provide case Insensitivity.

                       

                      Regards

                      Samo

                      • 8. Re: Experience with Switch from Case Insensitive to Case Sensitive Implementation
                        Stefan Hall

                        Samo,

                        you are unfortunately right, the support can often not help you there, but still I would not go that far. In the public service in Europe this trivial implementation would often be unthinkable.

                         

                        We have managed it and under control, if BMC can still get the rest under control, it works without our manual effort.

                        • 9. Re: Experience with Switch from Case Insensitive to Case Sensitive Implementation
                          Peter Adams

                          Stefan, I'm just trying to do some research and find out, if this is something that some customers have done.  We have many, many customers, and for on-premise deployments we generally don't collect any data directly from the system. So, sometimes I have to ask some questions in the community.

                          • 10. Re: Experience with Switch from Case Insensitive to Case Sensitive Implementation
                            Stefan Hall

                            Peter, I understand.  Maybe you can still help the other customers and put a developer on the bugs described above.  The support is overstrained with this.

                             

                            Stay healthy!

                              Stefan