You are currently reviewing an older revision of this page.
A sample Object Reference error message:
Internal Error Error Message: Object reference not set to an instance of an object. TargetSite: System.String get_DefaultPartsDB() DeclaringType: ECT.ECAD.API.ProjectSettings Attributes: public MemberType: Method
Sometimes when working with Bentley Substation or promis.e you may get an error whose first line is “Object reference not set to an instance of an object” like the sample shown above. This is typically the message you would see if some uncaptured error has occurred either in promis.e or in one of the supporting components (Microsoft SQL, .Net, ADO, C#, etc.) that the software has no way to properly handle. Thus you get this rather general error message which is very non-descriptive, and contains little helpful information in determining what the actual error was or what caused it. As these errors are reported to Bentley Support, we add them to our development efforts so that they can be properly handled with much more useful error messages or possibly prevented in the first place. However, that depends on many factors, most especially that the condition causing the error has a repeatable pattern. For a fictitious example, let’s say we discover that using a “#” character (we recommend that users avoid such reserved characters) in a particular field like the Device Tag on a symbol will cause it to have an “Object Reference” error. Since that would be a repeatable issue, we could trap for that condition and not allow users to use that character or bring up a message that says something more helpful and specific such as “illegal character” so users will have a clear indication of the issue. We would also put the error on Be Communities so that any other users that might run into that error before we release a build with that error fix will be able to tell what to do (see Option 1 below).
Unfortunately, the "Object Reference" error is often caused by some unique instance of data corruption and is not repeatable once the corrupted item is found and removed. In these cases we are limited more to finding the corruption and removing it to stop the error and allow work to proceed (see Option 2 below).
To see if the specific instance of the Object Reference error you are receiving has already been determined, please use the Search field at the top of the Be Communities page to search for “Object Reference” and the keyword from the TargetSite portion of the error you are seeing, such as in the sample message above you would type “Object Reference get_DefaultPartsDB” into the search field and the top result should be the description for an error with locked projects.
If the search does not find any documented case of the error you are seeing, or the description doesn’t fit your circumstances, then see Option 2 below
If the error you are seeing has not been documented already, then we would need to try to determine what is causing the error by the circumstances surrounding its occurrence.
Commonly, if we are able to narrow down the error to a particular object, then deleting that object and replacing a new one down in its place resolves whatever corruption was causing the error. So for example if right clicking on a symbol and selecting the Device ID dialog brings up the error, then we would typically suggest that you delete that symbol and place a fresh one down in its place. Likewise, if trying to assign a wire number to a particular wire brings up an error, we would suggest deleting and redrawing that wire, or if it is a Wire Tag, deleting that Wire Tag and reassigning it.
Sometimes we can use some of the built in commands to help find the corruption that is causing the error. For example if you use the Update command on the page, or the Validate command, it might help either remove the corruption or point to an object that needs to be removed. You should use those commands with caution though and always make sure you have a current backup of the project before using those commands. For instance, the Validate command can falsely indicate that many objects on the page need to be removed (or even all of them) because it can’t properly find the corruption, or the corruption is in the page itself, not really in the objects on the page. In those cases I would typically suggest trying to copy all the data from the page onto a new, freshly created page (typically I suggest creating a new blank page of the same name in a temporary test project so you can maintain all wire numbers and ID's exactly as they are without having to worry about duplication messages). Do not copy the page itself, as that would typically copy the corruption too, but copy the contents of the page and paste them onto the newly created page. Then see if the corruption exists in the new copy of that page. If not, usually you can delete the original page that is giving the error and then copy the new page (not just the contents) into the original project again using the commands in the Project Manager.