External reference with class module error

I have an issue importing a class module. This class module is an SFC and has an external reference parameter.  The external reference does not allow me to uncheck "Allow instances to be configured".. That seems normal?

Regardless, I have defined the external reference path within the class module because all of my instances use the same path. This is usually fine, but when I'm importing to another database (different site) i get the following error...

Wed Aug 3 09:56:56 2022
Importing FERMXFER from D:\DeltaV\DVData\Import-Export
Updating Type: MODULE CLASS: Name: FERMXFER
1: WARNING: DATABASE INTERNAL ERROR
2: WARNING: An Objectivity database error occurred
3: WARNING: Objectivity message
** Error #101: set_<association>(): Cannot add the association with cardinality
1 to the object because such association already exists
- context = #?-?-?-?
4: WARNING: Unable to set exposed attribute
5: WARNING: IMPORT ERROR: IMPORT of MODULE CLASS with key FERMXFER FAILED at line:5843 column:2. This could cause other serious import errors for related items in this file. Import is now resuming at the next item in the file.

1: DATABASE INTERNAL ERROR: 1 item(s) did not import successfully. Please review warning messages. 1 database internal errors were reported.
2: DATABASE INTERNAL ERROR: Errors occurred during the processing of the import script
Some items failed to import
Wed Aug 3 09:57:13 2022

What I have to do is remove the defined parameter path from the class module, which means i either have to redefine each instance once it's imported... or i have to also export and import the individual instances. I don't understand why this would be  problem...many instances using the same external reference path should be common. 

Any suggestions? Thanks

4 Replies

  • well, i removed the reference and it still gives me the error.... it fixed it last time... Note: the referenced line and column is the very end of the file..
  • Sorry Trey, no suggestion on the Internal Database Error. I would suggest a GSC call.

    Whenever I see a "DATABASE INTERNAL ERROR", I think, better make sure my backups are good and I have a current Export. An Export is needed if you have to rebuild the database. The Database Backups may still contain the genesis of the issue and although it gets you back up an running if you need to restore, it may still lead back to the issue. This is likely an import issue that the database is rejecting so not a restore scenario. But I'd do an export anyway, if you don't already have one.

    I would not expect a "DATABASE INTERNAL ERROR" because of a parameter defined as an external reference. I don't know what this could be, but I'd try the following:

    - create a new database and import the class into that database (may need some additional Setup Data items to import successfully) to see if the issue occurs there? If it does, you have a much simpler path for GSC to reproduce the issue i.e. you don't need to provide the entire database to them.

    - Create a simpler SFC class from scratch and see if that imports successfully. If it does, add the additional features and structures to recreate the failing class. Or delete content from the class until it can import and try to figure out if you can reproduce the issue.

    Could this class be a private "embedded" module or does it have Embedded Blocks or other structures that might not be in a basic Class Module.

    Please involve the GSC so they can give you more informed guidance.

    Andre Dicaire

  • In reply to Andre Dicaire:

    I know this is a week old at this point and probably won't be as verbose as our friend Andre, but I can tell you more than likely your DATABASE INTERNAL ERROR is related to the module classes exposed parameters. If you aren't aware, module classes have shortcut parameter names that are exposed at the instance like PID1$CONTROL_OPTS that normally reference a PID1/CONTROL_OPTS for example. These shortcut names do not have to match exactly. However, if you have a shortcut name such as BLOCK1$PARAM_1 that references BLOCK1/PARAM_2 and there is also a BLOCK1/PARAM_1, you will get this when trying to import the module class over the top that changes any of this. These situations tend to occur when copying and pasting parameters and then not updating the shortcut names to the defaults. The fix is actually pretty straight forward. On your current system that you are importing into, find the appropriate Class (in this case FERMXFER), Right click on it and say "Configure Instance." Then click the Parameters Tab, and the Filter button. Check all the boxes, then OK. On the left panel of shortcut names, do a shift click to select all parameters and then click the "Default Name" button. Depending on your database, it might think for a minute or two and then you can click Close. I suspect your import will then work the next time.
  • In reply to Matt Forbis:

    i ended up putting in a service call, but i wish i had seen your response.. i just came back here to report my findings...you are 100% correct

    the "exposed" name or shortcut name wasn't the same.. The parameter had the same name but i think if you create a parameter it gets the name.. then if you rename the parameter, the exposed name stays the same.. have to change that by going to "configure instances" on the class module