Knowledge Base
cancel
Showing results for 
Search instead for 
Did you mean: 

When upgrading the AS results in an empty database

Issue

When upgrading the AS results in an empty database

Environment

StruxureWare Building Operation 1.0.0.173 to 1.1.0.264
StruxureWare Building Operation 1.1.0.362 to 1.2.0.767
 

Cause

When upgrading the database, the ES upgrades just fine, but when upgrading the AS, the result is an empty database.

Resolution

StruxureWare Building Operation 1.0.0.173 to 1.1.0.264
The problem is caused by the initial engineering of the system being carried out on an old AS that was not LON or BACnet specific, copying into new hardware at R1.0 then when upgraded to R1.1 the upgrade fails due to the wrong type of AS being used (LON or BACnet). This practice is not common place and rather rare.

When the trace log is examined, they find that the upgrade fails due to the fact that an illegal object type is attempted to be created – a BACnet interface. This is not legal in an AS-L. The reason that this occurs is that the backup file is from an AS-L that had been restored from a 1.0 AS-B backup file.

Check Lessons Learned Article #5579. The issue you face could possibly be a procedural one and this article clearly defines the steps.

StruxureWare Building Operation 1.1.0.362 to 1.2.0.767
The solution is identifying problems with a period, space, or other character in names. Placing a period at the end of a name or accidentally having a space at the end is suggesting something is following or further action. If using BACnet, please see the note below. Problems with bindings which were still in tact when values were removed also are a potential issue and not properly removed. 
 

Work Around:

  1. Backup AS
  2. Upgrade PC to 1.2
  3. Open Device Administrator
  4. Upgrade AS to 1.2
  5. DO NOT close Device Administrator
  6. Open StruxureWare Workstation
  7. Log into AS
  8. If Database is Blank go back to Web Browser
  9. Connect to AS
  10. Log in
  11. In the top right hand corner of the screen select Setting>Device Configuration
  12. Select the Server Log tab
  13. Click “Get all log files”
  14. Once downloaded, open “trace” using Notepad
  15. Click Edit>Find
  16. Type the word “nsp.csc.UpgradeManager ERROR:”
  17. The error lines run from date stamp to date stamp so isolate the line beginning with the year and ending with the next instance of the year. Here is an example:

    2012-08-29 16:39:32.990 [32] nsp.csc.UpgradeManager ERROR:    Error Parsing Dump Objects:  RecoverableException: source/Path.cppy) ) Error: Invalid_Path (0x10001), module Coml(11), moduleCode 0, dispString "Heatsink Temp.", techString "Path& Path::Append(const UTF8String& name)" 

  18. The “dispString “_______”” section of this line will give you the object name that contains an illegal character.
  19. Downgrade the AS back to 1.1
  20. Locate the dispString object and change the name so that it does not contain any illegal characters. This is typically a name ending in a period. NOTE: when the rename dialogue pops up, it will indicate that an illegal character is present to confirm you are modifying the right object.
  21. Backup the AS
  22. Re-Upgrade the AS to 1.2
  23. If the upgrade fails, repeat steps 9-20 or call product support. Be prepared to provide a Db backup at 1.1 as well as the trace file from the 1.2 failed upgrade.

BACnet Note: A BACnet device including an object name "East Duct Max." is no longer valid because of the illegal character at the end of the name. Before upgrading the ES from 1.1 to 1.2, remove any full stops/periods from any object names. "East Duct Max." is changed to "East Duct Max"  Other illegal characters include *°?|/"<> or ~ and an object cannot begin or end with a white space or period. Select TPA-SBO-12-0008.00 - ES upgraded from 1.1 to 1.2 loses database to review this TPA.

Tags (3)
Labels (1)
Version history
Revision #:
2 of 2
Last update:
‎2018-09-10 05:34 AM
Updated by:
 
Contributors