wir haben ein Tortendiagramm, das mit LL7 erstellt, mit LL8 zuletzt bearbeitet und mit LL10 problemlos gedruckt werden konnte. Nun versuchen wir dieses Formular mit LL17 zu drucken und erhalten den Fehler “LL_ERR_BADDATABASESTRUCTURE”. Wenn wir das Formular mit dem LL17-Designer nur öffnen, neu speichern und wieder schliessen, tritt der Fehler nicht auf.
Nur zur Vollständigkeit: wir übergeben zur Design- und Laufzeit die gleichen Datenstrukturen, eventuell ist die Fehlerbeschreibung hier etwas ungenau.
Hat jemand das gleiche Verhalten beobachten können? Wenn ja, konnte es behoben werden? Wenn ja, wie?
Das könnte evtl. was mit den Änderungen in der .NET-Komponente zu tun haben… schau mal in das ProgUpdate.pdf rein. Da stehen immer die Änderungen drinnen. Hier hatte sich in der Version 15 bspw. das Databinding ein wenig angepasst, so dass man hier ggf. die Property AdvancedDatabinding setzen muss. Vielleicht hilft das ja bereits?
Seit LL10 hat sich eine Menge geändert, sicherlich auch combit-Dateiintern. Für mich klingt es logisch nach so langer Zeit die Projektdateien im neuen Format zu speichern. Bei uns im Hause geschieht das seit LL9 vorsorglich nach jedem Upgrade. In Version 16 gab es einen für uns relevanten Bugfix durch ein Servicepack - auch hier war das erneute Speichern der Projekte notwendig um diese in vollem Umfang nutzen zu können.
Die Umschreibung des Fehlers ist sicher an der Stelle irreführend, ich persönlich würde das aber nicht weiter beachten sondern die Dateien auf den neuesten Stand bringen.
Die DOTNET-Komponenten benutzen wir zwar nicht, die Fehler-Meldung scheint aber auf diesen Bereich hinzuweisen.
In der Tat haben wir auch feststellen können, dass sich Strukturen in der Beschreibungsdatei von LL17 (.lst, .crd, .lbl) geändert haben (und sollen). Da es sich um “einfache” Textdateien handelt können wir sogar in selbstangepassten Formularen der Anwender alle Ändernungen per Skript ändern, so dass die Formulare unter LL17 genau so ausgedruckt werden wie unter LL10. Einzige Ausnahme sind die Charts, in denen die Definition nicht im Klartext sondern komprimiert und/oder verschlüsselt abgelegt werden (LLCHART = …). Natürlich werden wir, wenn sich keine andere Lösung findet, die Formulare öffnen, speichern und neu verteilen. Allerdings ist dann absehbar, dass einige Anwender, die Formulare angepasst oder verändert haben, das selbst machen müssen.
Das bedeutet Aufwand in der Kommunikation und eventuell bei der Durchführung, die wir uns gerne erspart hätten.
Wenn es denn keine andere Lösung gibt, muss es wohl so sein.
Gruß,
Th. Neldner
