Frequently asked questions

In diesem Kapitel dreht sich alles um Fragen und Probleme, welche uns in regelmäßigen Abständen erreichen. Unter anderem werden wir hier auch bekannte Fehler-Stacktraces auflisten und deren Fehlerbehebung.

Anleitungen

Für eine Performance-Analyse und eine Stackoverflow Analyse gibt es unter Knowledge bereits eine Dokumentation.

FrameworkStudio Repository Backup bereitstellen

1. Öffnen Sie Microsoft SQL Management Studio, um auf die FrameworkStudio Repository-Datenbanken zugreifen zu können.
2. Wählen Sie die Datenbank aus, an welcher Sie sich auch im Framework Studio anmelden.
3. ContextMenü der Datenbank im SQL Management Studio öffnen - Tasks - Back up ...
4. Backup type: Full auswählen!
5. Ggf. Speicherort auswählen und OK drücken
6. Die erstellte Backup-Datei auf dem FTP hochladen und uns benachrichten, dass das Backup hochgeladen wurde.

Framework Studio

Framework Studio stürzt beim Initializing ab - Fehlercode c06d007e

Dies ist ein bekanntes Problem ab FS 4.5.34. Bei Verwendung von Framework Studio über die Console oder TeamViewer auf einem Windows Server 2016 oder Windows Server 2019 kommt es zu Abstürzen.

Wir nutzen intern den CefSharp Browser, welcher wiederum auf Basis des Chromium Browsers arbeitet. Chromium hat die intern verwendete Windows SDK upgedatet und verwendet nun die Windows SDK Version 10.0.26100.1742. Die Datei d3dcompiler_47.dll im neuen SDK versucht Versionen der Universal C Runtime (UCRT) dynamisch zu laden, die auf älteren Systemen standardmäßig nicht vorhanden sind. Dies führt zu Abstürzen der Anwendung.

Sollte Framework Studio auf Windows Server 2016/2019 mit Zugriff per Console oder TeamViewer abstürzen, so kopieren und ersetzen Sie die DLL im Programmverzeichnis durch die Version aus dem Compatibility Ordner:

• d3dcompiler_47.dll - Version 10.0.22621.2428

Diese Änderung muss nach jeder Installation und jedem Update vorgenommen werden!

Da Windows Server 2019 bereits seit Januar 2024 aus dem Mainstream-Support gefallen ist, wird es von CefSharp keine Lösung geben. Aus diesem Grund empfehlen auch wir das Update auf eine neuere Windows Server Version.

Exception Code Analysis has been disabled in this code editor

Code Analysis has been disabled in this code editor because generating code took too long (17,5s)!
Exception in diagnostics task:
System.Exception: Error creating code for NV.ERP.MM.Sales.cfrmSalesOrder

Bei dieser Meldung im Output-Fenster handelt es sich um einen Schutz-Mechanismus und nicht um einen "Fehler".

Der Code-Editor führt recht aufwändige Analysen durch, damit die (potentiellen) Compile-Error unmittelbar beim Bearbeiten im Code kenntlich gemacht werden. Dauert diese Analyse zu lange kann das dazu führen, dass Framework Studio praktisch lahmgelegt wird, sobald im Code-Editor getippt wird. Arbeiten ist dann nicht mehr möglich. Um genau diese Blockade zu verhindern, schalten wir diese Analyse ab, wenn die Ermittlung beim ersten Aufruf länger als 10 Sekunden oder bei einem erneuten Aufruf länger als 5 Sekunden dauert.

Im genannten Beispiel waren es 17,1 Sekunden.

Java Applikation

Betriebssystem MacOS Applikation Unterstützung

MacOS unterstützen wir seit einiger Zeit nicht mehr. Wir gewährleisten auch keinen Support hierfür . Auf eigenes Risiko kann natürlich mit Java 8 ein Betrieb von eNVenta ERP versucht werden.

Änderungen sind hier in der Zukunft nicht geplant.

Java-Exception: null

Beim Start der Java-Applikation wird folgender oder ähnlicher Fehler ausgegeben:

Java-Exception: null
 
  at  FrameworkSystems.FSJavaClient.DevControl.LayoutComponentDefault.<init>(LayoutComponentDefault.java:54)
  at  FrameworkSystems.FSJavaClient.DevControl.LayoutComponentDefault.<init>(LayoutComponentDefault.java:43)
  at  FrameworkSystems.FSJavaClient.DevControl.LayoutComponentDefault.<init>(LayoutComponentDefault.java:39)
  at  FrameworkSystems.FSJavaClient.UIWrapper.UIItem.createLayoutComponent(UIItem.java:449)
  at  FrameworkSystems.FSJavaClient.UIWrapper.UIItem.getLayoutComponent(UIItem.java:443)
  at  FrameworkSystems.FSJavaClient.UIWrapper.support.UIContainerSupport.setChildrenAtDevControl(UIContainerSupport.java:30)
  at  FrameworkSystems.FSJavaClient.UIWrapper.UIDockPanel.resumeVch(UIDockPanel.java:57)
  at  FrameworkSystems.FSJavaClient.UIWrapper.visualControlHierarchy.VchSuspendManager.resume(VchSuspendManager.java:67)
  at  FrameworkSystems.FSJavaClient.DevForm.<init>(DevForm.java:407)
  at  FrameworkSystems.FSJavaClient.DevRequest.Response(DevRequest.java:1065)
  at  FrameworkSystems.FSJavaClient.DevRequest.Start(DevRequest.java:603)
  at  FrameworkSystems.FSJavaClient.FSViewer.init(FSViewer.java:267)
  at  FrameworkSystems.FSJavaClient.FSViewerSession.run(FSViewerSession.java:87)
  at  java.awt.event.InvocationEvent.dispatch(InvocationEvent.java:301)
  at  java.awt.EventQueue.dispatchEventImpl(EventQueue.java:758)
  at  java.awt.EventQueue.access$500(EventQueue.java:97)
  at  java.awt.EventQueue$3.run(EventQueue.java:709)
  at  java.awt.EventQueue$3.run(EventQueue.java:703)
  at  java.security.AccessController.doPrivileged(Native Method)
  at  java.security.ProtectionDomain$JavaSecurityAccessImpl.doIntersectionPrivilege(ProtectionDomain.java:74)
  at  java.awt.EventQueue.dispatchEvent(EventQueue.java:728)
  at  java.awt.EventDispatchThread.pumpOneEventForFilters(EventDispatchThread.java:205)
  at  java.awt.EventDispatchThread.pumpEventsForFilter(EventDispatchThread.java:116)
  at  java.awt.EventDispatchThread.pumpEventsForHierarchy(EventDispatchThread.java:105)
  at  java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:101)
  at  java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:93)
  at  java.awt.EventDispatchThread.run(EventDispatchThread.java:82)

Ursache Systemvoraussetzung

Seit Version FS 4.5 verwendet FrameworkStudio den JxBrowser. Hierzu gibt es folgenden Hinweis in unserer Neuheiten-Dokumentation: https://frameworksystemsgmbh.github.io/fsdocs/v4.5/articles/neuheiten-4-5.html#neues-browser-control---austausch-des-javafx-browsers

Deshalb haben wir die unterstützten Windows Versionen nach oben setzen müssen. Bitte sehen Sie sich hierfür unsere Systemvoraussetzungen. in der Dokumentation an.

Lösung: Systeme auf die Systemvoraussetzungen updaten.

Sollte ein Update kurzfristig nicht möglich sein, kann der jxBrowser mit folgendem Ausdruck im FS Client Launcher durch den alten Browser ersetzt werden.

-Dfs.browser.legacy=1

Caution

Langfristig müssen Sie jedoch Ihr System auf die entsprechenden Systemvoraussetzungen updaten, da der alte Browser in Zukunft deaktiviert wird. Der alte Browser deckt nicht alle Funktionen ab, welche eNVenta benötigt. Hier ist deshalb mit Einschränkungen zu rechnen.

Ursache Citrix Environment

Es gibt ein bekanntes Problem bei unserem neuen JxBrowser Control in Zusammenhang mit Citrix. Die Dokumentation, um dieses Problem lösen können, finden Sie hier oder hier bei Citrix direkt.

Es ist notwendig die Citrix API Hooks auszuschalten.

Java-Client friert bei Nutzung von ARM-Prozessoren ein

Wenn der Java-Client ohne ersichtlichen Grund immer wieder einfriert, sollte geprüft werden, ob der genutzte Prozessor auf der ARM-Architektur basiert. Diese wird von unserer bereitgestellten Azul JavaRuntime nicht unterstützt.

Print Service

Drucker wird im Namen mit ## ERR ## angezeigt

Der Print-Service prüft beim Hochfahren alle konfigurierten Drucker. Wenn dabei ein Fehler auftritt (z.B. weil der Drucker nicht mehr existiert), wird der Name des betroffenen Druckers mit der Kennung ## ERR ## versehen. Um sicher zu gehen, können Sie auch die Log-Datei des Print-Service prüfen.

Mit der PrintServiceConfigEditor.exe können Sie diese Drucker aus der Konfiguration entfernen. Nach einem Neustart des Print-Service werden die gelöschten / nicht mehr existenten Drucker im Runtime-Repository auf gelöscht gesetzt. Anschließend sollten Sie auch in eNVenta nicht mehr angeboten werden.

Publish2Go

Absturz mit System.TypeLoadException: Error loading provider assembly

Beim Starten eines Publish2Gos kann es zu folgender Exception kommen:

System.TypeLoadException: Error loading provider assembly
Path: ...\P2Go_XXX\bin\xxx.dll
Type: xxxx ---> System.IO.FileLoadException: Could not load file or assembly '...\P2Go_XXX\bin\xxx.dll' or one of its dependencies. 
Operation is not supported. (Exception from HRESULT: 0x80131515) ---> System.NotSupportedException: An attempt was made to load an assembly from a network location which would have caused the assembly to be sandboxed in previous versions of the .NET Framework. 
This release of the .NET Framework does not enable CAS policy by default, so this load may be dangerous. If this load is not intended to sandbox the assembly, please enable the loadFromRemoteSources switch.

Diese Exception kommt daher, dass eine dll von einem Netzwerkpfad geladen werden soll. In älteren Versionen von .NetFramework wurden solche dlls automatisch in einem anderen Modus geladen, in den aktuellen Versionen ist dies nicht mehr der Fall.

Lösung

Im Hauptverzeichnis des Publish2Go, in dem auch die Publish2Go.exe liegt, muss die Publish2Go.exe.config angepasst werden.

Öffnen Sie die Datei dazu z.B. in Notepad oder Notepad++ und fügen zum <runtime> Knoten folgendes hinzu: <loadFromRemoteSources enabled="true"/>.

Beispielhaft hier der Aufbau der Publish2Go.exe.config:

<?xml version="1.0" encoding="utf-8"?>
<configuration>
        <appSettings>
               [...]
        </startup>
        <runtime>
               <loadFromRemoteSources enabled="true"/>
               <assemblyBinding [...]>