6.0.417.4 (Patch)


  • DigaSQL.dll 3.20.3498.0 (recommended)

Known problems

  • For BCSService and WebDigAIRange no new version is available. A support for the new node type EndpointStory is not ready yet.

New Features (only 6.1.434.0)

  • BCS does now support a login with a DPE token (classic + secure). For more information please see: BCSTechManual Chapter 6.4.7 "BCS and DPE Tokens" and/or BCS programmers manual chapter 2.6 "Login/Logout" and/or DigParam.rtf description for parameter "BroadcastServer\...\General\DPETokenUrl". (OIA-1704)

  • Implemented support for the new node type (=tagname) "EndpointStory" and the new start mode "SyncStart". They are implemented for regionalization and for multi-channel distribution. In an EndpointStory individual elements for different distribution endpoints or regions can be scheduled. (OIA-2275)

  • So far, the start type Floating and the start modes Manual and Sequenced were not inherited from a group or story to its children. A new experimental parameter (→BroadcastServer\Default\Setting\StartAttributeInheritance) has been added. If set to "Regular" these start attributes are inherited, too. Hint: for a correct workflow the clients must be aware of this new behaviour of BCS. This is only the case for clients of the release 6.1. (CCD-43401/OIA-2180)

Fixed Issues (both, 6.1.434.0 and 6.0.417.4)

  • When the parameter BroadcastServer\...\IP\OwnIPAddress was used (set to something different than together with (secure) WebSockets, then the background worker "AutoInsertFutureDays" did no longer work, because it could not get a connection to the own BCS server. (OIA-1750)

  • When a WebSocket-connected buddy BCS did disconnect without a proper logout, the master BCS did still think that a buddy is connected and it did reject new connection attempts of a buddy server with the error code -7 (CCD-43366)

  • BCSGUI: When switching between master and buddy BCS, the upper view with the list of connected clients was not updated but was empty.

  • When a client inserted a node directly to a day trash, BCS always deleted the delete info (like the user or the delete timestamp).

  • Mitigation of the still unsolved problem that sometimes (in very rare cases) the root node looses its tagname.