Model browser issue because of transactions?

[J_Pfeifer_]

I'm having a problem where the program creates a ton of features based on a couple of sketches to create the output. All of the outputs seem to take effect. However every so often the model browser refuses to update with the items used to create them.  This then transfers across all documents until inventor is restarted. 

Am I doing something wrong with transactions? has anyone experienced this before? 

Is there a way to forcefully update the model browser in anyway?

Unfortunately unless I recreate something similar as an example. I cannot post the current model or pictures of the model / browser. 

I found the below reference but in the discussion the poster seems to have placed a transaction in the middle. My transaction starts and ends at the very start and end of the program. 

force-model-browser-to-update-with-new-geometry 

[ekeatingLWGGE · Accepted solution]

I had a similar issue if for some reason the code did not get to the end transaction statement. Nothing would update until I restarted the computer.

I ended up putting the whole program in a try: statement with a catch that included a end transaction object.  

Could there be another thing that is preventing the transaction from finishing? 

[J_Pfeifer_]

I had briefly skimmed the documentation thinking I had understood the use of transactions. However you're 100% correct, there were places that were checks or terminations within the program that did not have a transaction abort. This led to the weird behavior in question. Once I had gone through and added the proper aborts and otherwise, I have not encountered the issue again. 

More specifically the following section from the API help "Start, End, and Abort Transactions"

• Each start transaction should be paired with an end or abort transaction. Inventor becomes unstable if the StartTransaction is not paired with a corresponding End or Abort. If any of the API calls fail, i.e. return a bad error code, then the command should handle the error and take care to call EndTransaction. Applying this rule consistently is particularly critical, since even a simple API call can fail rather unexpectedly. In the event that the error is not recoverable, the command should abort the transaction. Aborting the transaction means that the transaction was cancelled prior to completion. The sample below indicates how an error condition should be handled within the scope of a transaction.