Thread Details
  • State Verified Answer
  • +1 person also asked this people also asked this
  • Replies 20 replies
  • Subscribers 320 subscribers
  • Views 3651 views
  • Users 0 members are here
Forum Actions
Related

PMSE tables cleaning in database

Enes Saridogan

Dear developpers,

I would like to make a cleaning for the executed BPM processes, is it enough to remove data from the table PMSE_INBOX or is there other table to cleanup ?

Additionnaly, I would do the same for the emails, I want to keep only one year of data, I identified the following tables : 

  • emails
  • emails_beans
  • emails_email_addr_rel
  • emails_text

What do you propose ? Did you face the same issue ? What is the best practice to make a safe cleanup / archiving ?

Thanks in advance,

Enes

Parents Reply
  • 0 in reply to Enes Saridogan

    Hi Enes,

    Yes, the cas_id field in the pmse_inbox table is all good. The problem comes in the related tables like pmse_bpm_thread, pmse_bpm_flow as they can only store up to 4 digit values in the mentioned field.

    We are also using Oracle 12c, so it's strange you didn't notice that problem yet. Anyway, I am in contact with Sugar support on this, and let's see what they have to say.

    Kind Regards and have a nice weekend ahead.

    Junid

Children
  • 0 in reply to Junaid Usman

    Hello Junaid,

    I just checked in my database, and the cas_id column in pmse_bpm_flow table is not limited to 4 digits, no problem at all. Very strange :/

    By the way, how are the general performance for your instance ? We are running in Sugar 7.9.3 (migration planned next year) and it is very slow when saving or displaying cases for example (700.000+ cases).

    Best regards and have a nice week.

    Enes

  • +1 in reply to Enes Saridogan

    ,

    Sugar had a huge amount of performance improvements since version 7.9 (2017 release).

    Please note that 7.9 has not been supported for a number of years as well, as the current on-premise version is 10.0.x.

    The recommendation from me is to start planning the upgrade, as there are many steps involved (both on the infrastructure/architecture and at the application level) on getting through 3+ years worth of releases.

    For your specific scenario you will find especially useful for listviews speed up some features we released back in version 8 to optimise record listing retrieval.

    In saying that, it is good to think about either an archival strategy or a performance testing combined with system scaling strategy to make sure your system is in optimal shape for your business needs.

    --

    Enrico Simonetti

    Sugar veteran (from 2007)

    www.naonis.tech


    Feel free to reach out for consulting regarding:

    • API Integration and Automation Services
    • Sugar Architecture
    • Sugar Performance Optimisation
    • Sugar Consulting, Best Practices and Technical Training
    • AWS and Sugar Technical Help
    • CTO-as-a-service
    • Solutions-as-a-service
    • and more!

    All active SugarCRM certifications

    Actively working remotely with customers based in APAC and in the United States

  • 0 in reply to Enes Saridogan

    Hi Enes,

    Then looks like they introduced that in Sugar9 or 8 because sugar support considers it as a bug.

    Regarding performance issues, I would highly recommend upgrading your instance to Sugar9. As Enrico already mentioned, since Sugar8 there are a lot of performance improvements and things are loading pretty fast as compare to Sugar7.

    Kind Regards,

    Junaid