Hier werde ich Informationen bereitzustellen, die mir bei meiner Entwicklungsarbeit aufgefallen sind. Aber auch Neuigkeiten, die für Sie von Interesse sein könnten.

Beispiele:

  • Thema: ‚outer join‘ bei ‚freidefinierbaren Datenexporten‘
    Die Aufgabenstellung lautet: Einen Datenexport erstellen, bei dem zu den Vertriebsbelegen auch der Name des zuständigen Vertreter mit ausgegeben werden soll. Klingt sehr einfach – und war auch bis zu pA4.x allein über zwei Tabellen, die  V_BelegKopf zu realisieren, der man nun noch die Adressdaten des Vertreters hinzugeben musste.
    Heute bedarf es (und das muß nicht schlechter sein) der V_BelegKopf, der V_BelegKopfVert, der S_Vertreter, sowie der S_Adresse. Diese vier Tabellen müssen nun miteinander verbunden werden. Führend dabei ist die (oberste) Tabelle V_BelegKopf. Die V_BelegKopfVert ist eine ‚abhängige Tabelle‘, was der Datenexport bei Anlage selbst erkennt. Und jetzt kommt es: Die dritte Tabelle ist die S_Vertreter. Die muß – wie auch die vierte Tabelle, unter der S_Vertreter – mit dem Häkchen ‚outer join‘ versehen werden.
    Warum ?  Der ‚outer join‘ sorgt dafür, dass jeder (!) Datensatz von V_BelegKopf ausgegeben wird. Nicht nur die Datensätze, zu denen es auch einen Vertreter gibt. Eben genau das wäre ansonsten der Fall gewesen, wenn das Häkchen nicht gesetzt worden ist.
  • (21.11.2022)  Wo finde ich in proALPHA 7.x die mir seit Jahren vertrauten Tabellen und Felder ? 
    Angedroht wurde es ja schon vor etwa 15 Jahren – nämlich dass manche Tabellen und Felder irgendwann im Zuge der dann notwendigen Datenbank-Neustrukturierung anders aufgebaut sein werden. Bei Datenbank-Tabellen, wie der ML_KOBLA, mochte manch einer nicht darüber nachdenken, was das dann bedeuten würde. All die vielen Listen und Auswertungen, die eben auf dieser extrem umfangreichen Tabelle aufgebaut worden sind, würden dann irgendwie komplett neu erstellt werden müssen.  Und genau da sind wir heute mit der 7er-Version.
    Am Beispiel der früheren ML_Kobla will ich aufzeigen, wie man denn an all seine Felder kommt. Denn zum einen gibt es die ML_Kobla nicht mehr und zum anderen finden sich in der Nachfolge-Tabelle nicht mehr all die Felder, die zuvor in ‚Kobla‘ waren. Und darum mache ich das mal an dem Feld ‚BuchungsSchlüssel‘ fest.
    Heute ist es die MLL_Movements, die der früheren Tabelle ML_Kobla am nächsten kommt.  Hier stehen die meisten Felder zur Verfügung, die wir auch von früher kennen. Wie die Tabelle selbst, so heißen auch die meisten Feldnamen anders. Das beginnt alleine schon damit, dass hier kein for-each mit .. where firma = ‚100‘ beginnen kann. Heute heißt es in dieser Tabelle dann where company = ‚100‘.
    Wie auch immer …..   „Es gibt das Feld Buchungsschlüssel nicht mehr !“   Ich benötige es aber !!!!! Wo ist es und wie heißt es ??
    Die Lösung:
    Das die Tabelle jetzt MLL_Movements heißt kann man über die bekannte Tasten-Kombination ‚Strg & Z‘ im Eingabefeld der normalen pA-Fenster herausfinden. Bei dem BuchungsSchlüssel ist das jedoch nicht möglich, weil es sich hier um ein Auswahlfeld handelt.
    Wenn ich nun in den DatabaseExplorer gehe und dort die Tabelle MLL_Movements aufrufe, finde ich dort auch manche Felder mit einer Object-ID. Diese sind ein Zeichen für den ‚Verzweig‘ zu einer anderen Tabelle. Die Feld-Namen sind weitgehend sprechend. So gibt es dort auch das Tabellenfeld ‚MEM_PostingCode_Obj‘ – eben den Verweis auf die Tabelle MEM_PostingCode:
    Rufen Sie die jetzt mal im Database-Explorer auf !  –> „Im Feld ‚MEM_PostingCode_ID‚ finden Sie auch den Buchungsschlüssel wieder !“
    Ein anderer Weg zum Ziel ist der, einen freidefinierbaren Datenexport auf Basis der Tabelle MLL_Movements zu erstellen. Dem Tabellenaufruf fügen Sie noch eine weitere ‚untergeordnete‘ Tabelle hinzu. Welche da infrage kommen, können Sie im Eingabefeld des weiteren Tabellen-Namens mit Strg & A‘ herausfinden. Speziell in diesem Fall wird dort auch die Tabelle ‚MEM_PostingCode‚ angeboten – und hier sogar mit dem Hinweis ‚Buchungsschlüssel‘.
    Ansonsten …. einfach mal alle dort aufgeführten, infrage kommenden Tabellen im DatabaseExplorer aufrufen und nachsehen, welche Felder dort angeboten werden.
  • Thema: Report in eine Anfrage einbinden
    Auch da musste ich erst nachfragen und musste dann erst einmal die alten Strukturen in meinem Kopf entfernen, bis ich verstanden habe wie es heute – ab Version IZ2016, bzw. Analyzer 9.0 funktioniert.
    Früher war es so, dass man im Register-Kärtchen ‚Reporte‘, in einer Anfrage die gewünschten Reporte so einfügen konnte, dass man von dort aus über ein Explorer-Fenster die gewünschte Report-Vorlage sucht und auswählt und dann die Anfrage speichert.
    Heute ist das an sich komplett anders (siehe dazu die ‚Top 5‘ der Version 2016, aber unbedingt auch ‚Mit Tabelle synchronisieren‘ in der Hilfe (!)) : Sie haben eine Anfrage ‚funktional‘  soweit fertig gestellt, dass Sie diese unter einem neuen Anfrage-Namen abspeichern könnten. Auf dem bisherigen Wege können Sie an dieser Stelle keinen Report mehr einsetzen – auch, wenn alles noch so auszusehen scheint wie bisher. Sie speichern also die Anfrage ‚ohne‘ Report-Eintrag ab. Dann führen Sie diese neue Anfrage aus – klicken auf ‚Ändern‘ der Anfrage – setzen das Häkchen für  ‚Mit Tabelle synchronisieren‘ – suchen dann aus dem Register ‚Ergebnisse‘ über den Button ‚Report‘ wie bisher die gewünschte Vorlage aus und rufen diese auf – Klicken dann auf dem noch offenen Anfrage-Fenster auf ‚Anfrage ändern‘ und haben jetzt auch die gewünschte Vorlage mit in die Anfrage eingebunden.
    Kommt mir noch etwas gewöhnungsbedürftig vor – mag aber auch daran liegen, dass der beschriebene Weg zum Ziel auch noch etwas einfacher zu machen werde. Die Funktion hier ist aber definitiv die, dass die Vorlagen über das Synchronisieren der Anfrage erstellt wird.
  • Fehlerhinweis beim Öffnen einer Analyzer-FOX-DateiDie Tabelle XY.fox ist nicht auf der Basis der für Ihren Rechner eingestellten Sortierung ‚Deutsch (Deutschland) /Wörterbuch‘ sortiert. Vermutlich wurde die Tabelle auf einem Rechner mit einer anderen Betriebssystemversion erzeugt, die unterschiedliche Sortiertabellen enthält.
    Der Fehler, bzw. insbesondere die Erklärung dafür, ist nicht recht nachvollziehbar. Zumindest nicht in dem Fall, wo dieser Fehler beim Anwender aufgetreten ist. Grund dieser Aussage: Aus zwei problemlos (ohne Fehler-Hinweis) zu öffnenden .fox-Dateien wurde mittels eines JOIN eine dritte FOX-Datei erzeugt. Eben diese – soeben erstellte Datei – lässt sich nur noch mit dieser Meldung öffnen. Schlimmer noch: Per Batch ausgeführt, wird die Aufruf-Aktion nicht durchgeführt (in meinem Falle ein -insert) und die folgende Ergebnis-Tabelle bleibt leer – und somit alle folgenden Teil-Ergebnisse ebenso.
    Manuell lässt sich diese Meldung schlicht durch den ‚OK-Button‘ schließen, sodass das Programm dann ohne weitere Probleme weiterarbeitet. Hierzu wurde am 25.02.2016 ein Call bei proALPHA aufgemacht.
    Erklärung/Lösung folgt so bald wie möglich.
    Heute, 14.März 2016 hat sich zu dem Call noch nichts bewegt.
    Aus der Not heraus erfolgt mein neuer Ansatz jetzt auf der Basis, dass ich nicht ausschließen kann, dass diese Problematik erst dann auftritt, wenn zuvor eine Umformatierung der Programm-Version stattgefunden hat. Beispiel: Die Tabelle wurde als IZ2015-Version erstellt und dann als Analyzer8.2-Version abgespeichert.
    In jedem Falle ist es so, dass der in der Meldung angezeigte Lösungsansatz ’speichern Sie die Tabelle noch einmal‘ nicht zum Ziel führt.
    Ich warte mal weiter auf eine Antwort und Lösung. Bis dahin gehe ich den ein oder anderen eigenen Ansätzen mal weiter nach.
  • FOX-Datei in die Vorlage ( XY.fot -insert YX.fox -query Anfrage1 ) laden und dann eine Anfrage ausführen. Danach ist das Ergebnis völlig falsch = Thema: doppelte Attribut-Namen, bzw. Importnamen sind doppelt.
    Eine detaillierte Erläuterung folgt hier noch (29.02.2016)
  • Es geht um Batch-Scripte: Der im Folgenden beschriebene Fehler konnte erst nach mehrwöchiger Recherche zu zweit gefunden und behoben werden. Der Grund ist (zumindest mir bis heute) nicht logisch nachvollziehbar, wie mir auch das Programmverhalten nicht nachvollziehbar erscheint. Denn mit dem Analyzer läuft es , mit InfoZoom jedoch nicht. Ebenfalls vorweg: Es hat nichts mit der Befehlsfolge, oder der Art des Befehls zu tun, es liegt auch nicht an einer der InfoZoom-Versionen, es hat auch nichts mit dem Betriebssystem zu tun (Win7, -8, -10).Beschreibung: Innerhalb einer Batch-Datei lautet einer der ersten Einträge :
    set infozoom = "C:\Program Files (x86)\humanIT\InfoZoom 2016\InfoZoom.exe"

    Bei dieser Zeile wird der Variablen ‚infozoom‘ der Aufrufpfad für das Programm InfoZoom zugewiesen.
    Wird anstelle von InfoZoom an dieser Stelle der Analyzer gestartet – funktioniert das ohne Probleme. Wird – so wie hier – jedoch eine InfoZoom-Version gestartet, funktioniert der Batch-Ablauf im übernächsten (?!) Schritt nicht. Zuvor wird InfoZoom noch gestartet und es wird bspw. eine Vorlage in das Programm geladen. So weit – so gut. In die Vorlage dann noch eine fox-Datei zu laden, oder überhaupt noch eine weitere Datei zu laden, geht nicht mehr. Der Batch-Lauf bleibt stehen – so, als würde im Hintergrund ein Fenster aufgehen, welches erst noch bestätigt werden müsste.
    Die Lösung ist so einfach, wie unerklärlich :

    set infozoom="C:\Program Files (x86)\humanIT\InfoZoom 2016\InfoZoom.exe"

    So geht es ! Lassen Sie die beiden ‚Leerzeichen‘ vor und hinter dem ‚Gleichheitszeichen‘ in der Pfad-Zuweisung weg !!!

  • Wussten Sie, dass Ihnen die jeweils aktuellen Analyzer-Versionen kostenlos im Zuge des Softwarepflege-Programms von proALPHA zur Verfügung stehen.
  • Wussten Sie, dass die aktuelle Vollversion des ‚Analyzer‘  nun auch “ interaktive Diagramme“ hat, über die Sie in die Tabellen-Daten ‚hinein-zoomen können.
  • Wussten Sie das man sich manche Probleme beim ‚Join‘ und der weiteren Verarbeitung ersparen können, wenn Sie a) ausschließen, das es zu
    mehrfach gleichen Attributnamen kommt, indem nicht nur die ’sichtbaren‘ Namen geändert werden, sondern auch die Export-Bezeichnungen. –> siehe dazu weiter oben ‚doppelte Attribut-Namen‘
  • Wussten Sie das bei bei der Abarbeitung von Batch-Dateien offenbar einen Unterschied zwischen dem Analyzer und InfoZoom gibt ?!  –> siehe dazu weiter oben ‚Batch-Scripte‘
  • Wussten Sie das InfoZoom die Vollversion des proALPHA-Analyzer ist ?

An dieser Stelle werden also mit der Zeit immer mehr Informationen, Tipps und Hinweise von mir eingetragen.

Ich könnte mir hier auch eine Liste vorstellen, in der ich die bisherigen – und aktuellen Projekt-Themen, bzw. -Aufträge aufrliste. Das könnte Ihnen als Anregung dienen, oder Sie doch zur Nachfrage nach weiteren Informationen anregen. Ich fange einfach mal an:

Januar-Februar 2016 = Umstellung eines Kunden von pA 4.3 auf 6.1 und damit verbunden die Übernahme der wesentlichen Analyzer-Auswertungen. Nicht nur auf die neue pA-Version, sondern damit auch auf die aktuelle Analyzer-Version 8.3 (entspricht IZ2015). In dem Zusammenhang geht es um die Lieferantenbewertung, diverse Umsatz-Auswertungen, neue Kennzahlen-Berichte, sowie eine Produktionsauftrags-Auswertung.