• Replies 4 replies
  • Subscribers 12 subscribers
  • Views 109 views
  • Users 0 members are here
Options
Related

Reconfiguring AVEVA supplied DBs to a Different DB number Issue

Russen Harold Cordovan

We need to combine two different E3D projects from 2 subcontractors. Each project copied the AVEVA supplied DBs for the multidiscipline support purpose. These AVEVA supplied DB copies were modified according to each subcontractor's preference so eg. DB number 7007 from subcon A is not anymore same with DB number 7007 from subcon B. One of these copies should be reconfigured to a different. Here's what we did:

1. Set protection to false of eg. DB number 7007

2. performed merge and integrity check patch on

3. reconfigured 7007 to 11000

4. DB number 21019 is referencing 7007 previously, tried integrity check 21019 with external reference checked .  

5. DICE report shows few objects still linking to 7007 and majority to 21019 . Note that DB number 7007 is not anymore existing and used.

for some AVEVA supplied DBs that we reconfigured, there are no issues after reconfiguration to new DB number.

Error message in the DICE log after reconfiguration from 7xxx to 11xxx


                     Error getting session no. 55827 from database

Modifying the DB number is a must otherwise I can't be able to include the DB with conflicting DB numbers, especially in a global environment. It's not the best practice but we have no choice but to find solution for this. 

Has anyone experienced this? 

Thank you.

  • Have you reconfigured db 7007 with RCFUPDATE option?

    You can read https://softwaresupportsp.aveva.com/#/knowledgebase/details/000036222?lang=en_US

    Hope this helps somehow...

  • in reply to Corrado Galluzzi

    Yes Corrado I used RCFUPDATE ALL option, just strange that references links to the old DB number 7007. 

    Another example below:

    DB Name = FGADMI/PSP_CATALOGUE

    Old DB Number = 7876

    New DB Number = 11876

    After Reconfigure with RCFUPDATE ALL option, here's the DICE of one of the DBs referencing to FGADMI/PSP_CATALOGUE

    **********************************************************************

    Database FGADMI/FGHVACCATA  

    Error getting session no. 55827 from database


    External databases referenced
    _____________________________

    Number              Name                                          No of references
    ______                ____                                          ________________

    7876                                                                        14
    11876                  FGADMI/PSP_CATALOGUE       2

    ************************************************************************

    You can see 14 references linked to old DB number 7876. This number is not anymore used as it is already reconfigured to new number 11876. 

    Note, I already set the DB Protection to OFF before I reconfigured the DB.

    Thanks Corrado.

  • in reply to Russen Harold Cordovan

    For some reason, it seems that reconfiguration process looks for a specific database session.

    And it doesn't find it because you  (correctly) merged the databases.

    If you still have the original databases, it would be interesting to try again without merging before reconfiguring.

    Just an idea...

  • in reply to Corrado Galluzzi

    Actually i tried reconfiguring without merging first, still having some issues. This project don't have another backup files so choice but to work with only available db files. Even system db does not register some of the physical db files. More likely one of the reasons could be those references to the unregistered dbs. Was just hoping merging all dbs can fix this but unfortunately cannot.

    Thanks Corrado!