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
- Öffnen Sie Microsoft SQL Management Studio, um auf die FrameworkStudio Repository-Datenbanken zugreifen zu können.
- Wählen Sie die Datenbank aus, an welcher Sie sich auch im Framework Studio anmelden.
- ContextMenü der Datenbank im SQL Management Studio öffnen - Tasks - Back up ...
Backup type: Fullauswählen!- Ggf. Speicherort auswählen und
OKdrücken - Die erstellte Backup-Datei auf dem FTP hochladen und uns benachrichten, dass das Backup hochgeladen wurde.
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.
Java-Applikation 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.
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.
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-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.
Exception Code Analysis has been disabled in this code editor because generating code took too long (17,1 s)
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.
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.