UniVerse

Expand all | Collapse all

Unable to use CREATE.INDEX in 12.1.1

  • 1.  Unable to use CREATE.INDEX in 12.1.1

    Posted 4 days ago
    It has been very frustrating when the changed Universe 12.1.1 to no allow updating indexes while people are accessing the file. This worked before from 9.6 to 11.3.1 but not 12.1.1. We have clients that run 24/7 and we have to stop our Web-based applications running under Apache Tomcat, make sure no one is using our Eclipse IDE tools and kill any phantom jobs before you use CREATE.INDEX. Otherwise, you get this:
    >CREATE.INDEX ACCT.CHECKS BANK.NO NO.NULL

    Unable to open "ACCT.CHECKS", file open by other users, exclusive access failed.

    Here is what Rocket said in my case:
    Advice from our ATS engineer:
    Reverting functionality to how it was prior to UniVerse 12.1.1 can cause issues where a newly created and built index can be out of sync if existing users have the file open. As long as our customers acknowledge the risk, we could create a new story which would allow customers to have their installation behave as it was prior to UniVerse 12.1.1 if they choose. This would be something that is configurable.

    ------------------------------
    Doug Averch (Owner)
    U2logic, Inc.
    daverch@u2logic.com
    303-946-5226 (cell & text)
    ------------------------------


  • 2.  RE: Unable to use CREATE.INDEX in 12.1.1

    Posted 4 days ago
    Huh.  I was under the assumption that UV 12 took much of the memory structure and things like that away from the individual processes and instead replaced it with a more centralized system.  Because of that, I was actually hoping that UV 12 was going to do a BETTER job of allowing 24x7 shops to be able to service the system without having to take an outage.  We all have understood that doing things when the system was up and running was a potential problem and could cause issues but I would have hoped that Rocket would have worked on addressing the underlying issue with having to take systems offline for every bit of database altering rather than just locking down the "bad" practices and thus forcing more downtime.

    ------------------------------
    Ryan Ladd
    ------------------------------