/
OBJ V9.0.1

OBJ V9.0.1

[#9041] Sperrprüfung Änderungsnummer in Objektgültigkeiten korrigiert

Bei der Sperrprüfung der Änderungsnummer  in den Objektgültigkeiten wurde eine vorher gesetzte Sperre fälschlicherweise als Fehler erkannt. Dies wurde korrigiert. Die Prüfung testet nun ob eine Lesesperre (shared) gesetzt werden könnte.

Nachtrag OBJ V9.4.1: falls gesperrt, wurde in der Meldung nicht der Benutzername welcher das Objekt sperrt, sondern das Sperrobjekt (ECAENRE) ausgegeben. Dies wurde nachgebessert.

[#9004] Keine Log-Initialisierung bei lesenden Stücklistenzugriffen

An verschiedenen Stellen in den ProNovia Produkten werden API Bausteine zum Lesen von Stücklisten verwendet (Material, Dokument, etc.). Die Log-Behandlung dieser Bausteine wird vor dem Aufruf jeweils nicht oder nicht korrekt initialisiert, weshalb im API Log des SAP Systems Fehlermeldungen auftreten können, dass eben die Initialisierung nicht korrekt ist. Zudem wurden die Log-Meldungen unnötigerweise in der Datenbank fortgeschrieben (Löschung nach 10 Tagen).

Dies wird in den Produkten gemäss den dieser Meldungen zugewiesenen Versionen korrigiert.

[#8947] Integration des SDF Pakets in OBJ

Um die Paketierung der ProNovia Produkte zu vereinfachen, also auch die Installation auf den Kundensystemen, wurde SDF in das OBJ Paket integriert. Eine separate Lizenzierung ist aber weiterhin notwendig. Das Customizing wurde ebenfalls in das OBJ Customizing integriert.

SDF V3.6 ist die letzte SDF Version welche mit separatem Paket verteilt wird / wurde. Nach Installation von OBJ V9 darf kein separates (und altes) SDF Paket mehr installiert werden.

[#8945] Suchhilfe /PRONOVIA/UTI_DOCSEARCH gibt Resultat falsch zurück

Die ProNovia Suchhilfe zur Verwendung der erweiterten Dokumentensuche (Transaktion CV04N) gibt den ausgwählten Treffer fälschlicherweise falsch zurück.

Dies wurde korrigiert.

[#8941] START_NEW_VALIDITY_RECORD nicht möglich wenn Revisionen nicht unterstützt

In den Serviceklassen für die Objektgültigkeiten (/PRONOVIA/CLA_OBJVAL_ROOT und abgeleitete), kann über die Methode START_NEW_VALIDITY_RECORD ein neuer Objektverwaltungssatz zu einer Änderung erzeugt werden. Bei Objekten, welche keine Revision erlauben, wird die Methode mit einem Fehler "revision not allowed" abgebrochen. 

Dies wurde korrigiert.

[#8839] Datumselemente: ungenutzte Zähler / fehlende Sperre

Im Bereich der zentralen Verwaltung der Datumselemente sind folgende Probleme / Fehler aufgetreten:

  • Zu einer Änderungsnummer können maximal 999 Datumselemente angelegt werden. Um ein neues Datumselement anzulegen wird von der entsprechenden Service-Methode der aktuell maximale Zähler bestimmt und um eins erhöht. Ist das Maximum erreicht wird ein Fehler ausgegeben (mit entsprechendem Text). Dabei kann es aber sein, dass existierende Datumslemente nicht mehr verwendet werden, also keine Zuordnungen mehr haben. Somit sind effektiv dann ggf. weniger Elemente als die maximale Menge von 999 verfügbar. 
  • Beim Anlegen eines Datumselements kann es wegen einer fehlenden Sperre in ganz seltenen Fällen zu einem DB Fehler "duplicate Key" kommen.

Dies wurde korrigiert:

  • Sind keine weiteren Zähler zu den Datumselementen verfügbar, werden neu nicht gebrauchte Zähler wiederverwendet, also das Datum und die Bezeichnung neu gesetzt.
  • Die Behandlung der Datumselemente wird neu über einen eigenen Sperrmechanismus kontrolliert.

© ProNovia AG | Imprint | Data Protection