<div dir="ltr"><div dir="ltr"><div><br></div><div>Verlautbarung 307 zur allegro-Entwicklung                    2019-01-24<br></div><div>--------------------------------------------------------</div><div><br></div><div>Ergebnismengen konservieren und rekonstruieren</div><div>-------------------------------------------------------------------</div><div><br></div><div>Eine Frage wurde eingereicht, ob man denn eine Ergebnismenge irgendwie</div><div>"konservieren" könne. Der Wunsch ist, genauer gesagt, daß eine gerade</div><div>mit einiger Mühe aufgebaute Ergebnismenge genau so und nicht anders</div><div>irgendwann später, vielleicht sogar nach Monaten oder Jahren, wieder</div><div>hervorgeholt werden könnte. Oder auch, um sie einem anderen Nutzer</div><div>zukommen zu lassen, damit der sie einlesen kann und nicht selber</div><div>aufbauen muß - das ist ja nicht immer ganz einfach.</div><div><br></div><div>Nun kann man zwar schon lange die Liste der internen Satznummern der aktuellen Erg.Menge mit dem Befehl</div><div><br></div><div>  write in   (s. h xcstring=ix)</div><div><br></div><div>hinausschreiben in eine (vorher mit  open x xyz.set  geöffnete) Datei</div><div>xyz.set (s. h xcstring=ix), und bald darauf oder später mit  </div><div><br></div><div>  read set xyz.set   (s. h xread=read set)</div><div><br></div><div>wieder einlesen - die Erg.Menge ist dann plötzlich wieder da.</div><div>Der Haken bei dieser Sache: Es können einige oder alle Sätze falsch</div><div>sein! Und zwar dann, wenn zwischenzeitlich eine Gesamt-Erneuerung</div><div>gemacht wurde, denn dann kriegen alle Sätze eine neue interne Nummer.</div><div>INTERNE Nummer! Die Nummer in #00 bzw. der Primärschlüssel ändert</div><div>sich dabei nicht! Denn der Inhalt des Datensatzes bleibt insgesamt</div><div>völlig unverändert. Die "interne Nummer" ist diejenige, die unten in</div><div>der Statuszeile zu sehen ist, im zweiten Feld von rechts. Da steht </div><div>z.B.  10806/2 L288 </div><div>Das bedeutet: Der Satz hat die interne Nummer 10806, steht in der</div><div>Datei 2 und ist 288 Bytes lang. Diese Nummer 10806 kann sich bei</div><div>der Gesamterneuerung ändern, aber diese internen Nummern sind es, die</div><div>in einer .set-Datei stehen. </div><div>Daraus wird klar: für eine Dauer-Konservierung eignet sich die</div><div>interne Nummer nicht. Was sich eignet, ist einzig der Primärschlüssel.</div><div>Zwar kann man auch diesen mutwillig ändern, aber nur auf eigene </div><div>Gefahr, deshalb wird davon abgeraten: er wäre dann u.U. nicht mehr</div><div>eindeutig, und eindeutig muß er sein, sonst verliert er seine </div><div>wichtigste Eigenschaft. Und nur dank dieser kann man auch die hier</div><div>gestellte Aufgabe lösen!</div><div><br></div><div>Ergo blieb nichts übrig, als einen neuen FLEX zu schreiben. Was er tun</div><div>soll, ist klar: die Primärschlüssel, nicht die internen Nummern, in </div><div>eine Datei schreiben. Diese kann ein zweiter FLEX später wieder </div><div>einlesen und die zugehörigen (evtl. veränderten) internen Satznummern </div><div>dann ermitteln, um damit die Ergebnismenge zu rekonstruieren.</div><div><br></div><div>Der neue FLEX heißt "emkon.flx" (von "ErgebnisMenge KONservieren")</div><div>und er konserviert die aktuelle Ergebnismenge. Das macht er so:</div><div>Er speichert die Primärschlüssel der Sätze in eine Datei xyz.erg,</div><div>wobei xyz ein frei wählbarer Name ist, und der Dateityp .erg wurde</div><div>für diesen Zweck neu erfunden.</div><div>Die erste Zeile dieser Datei ist dann der Titel der Erg.Menge, so wie </div><div>er in der Liste (Alt+e) zu sehen ist und auf dem Balken unten rechts, </div><div>z.B. also  "per shakespeare?"   (Der Name der Datei muß nichts zu tun</div><div>haben mit dem Titel der Ergebnismenge, der vom Suchbefehl herrührt.)</div><div>Man ruft also auf:</div><div><br></div><div>  X emkon    Dann wird man nach einem Dateinamen gefragt. </div><div><br></div><div>Der Dateiname ist ganz beliebig, es muß nur ein zulässiger Name xyz</div><div>sein, den man einer Datei geben kann, ohne daß Windows aufmuckt.</div><div>Noch'n Tip: Der Titel der Erg.menge kann recht lang und komplex werden.</div><div>Man kann ihn aber ändern! Um den Namen der aktuellen Erg.Menge zu</div><div>ändern auf, sagen wir, "Goethe's Werke", müßte man nur eingeben:</div><div>  x set RGoethe's Werke</div><div><br></div><div>Kaputtgehen kann nichts - es gibt keine Schreibvorgänge in der Datenbank.</div><div><br></div><div>ACHTUNG: Die Dateien kommen alle in den Datenbankordner (DbDir), also</div><div>z.B.  c:\allegro\demo2! Denn es kann sein, daß später mal jemand anders</div><div>genau diese Erg.Menge braucht, und dann soll sie ihm ohne Umstände</div><div>sofort zugänglich sein.</div><div>Natürlich kann man sich eine solche Datei auch sonstwohin</div><div>kopieren, wenn man sie auf Nummer sicher haben will.</div><div><br></div><div>   ******</div><div><br></div><div>Irgendwann später, vielleicht erst nach Jahren ...</div><div><br></div><div>... kommt der Moment, wo man die Erg.Menge wieder braucht.</div><div>Dazu muß ein zweiter FLEX ran, der die .erg-Datei einlesen und</div><div>die Erg.Menge rekonstruieren kann. Er heißt  emrek.flx  (von</div><div>"ErgebnisMenge REKonstruieren")</div><div>Ist der Name der .erg-Datei z.B. "xyz.erg", dann ist zum</div><div>Rekonstruieren einzugeben:</div><div><br></div><div>  X emrek xyz</div><div><br></div><div>und nach kurzer Zeit taucht die Ergebnismenge auf, als ob nichts</div><div>gewesen wäre, mit dem Titel, den sie beim Konservieren hatte.</div><div><br></div><div><br></div><div>Die beiden FLEXe  kann man sich abholen:</div><div>  X gf emkon.flx   und   X gf emrek.flx</div><div>Sie sind vollständig kommentiert, damit sie auch brauchbar sind</div><div>als Vorlage für ähnliche Zwecke.</div><div><br></div><div>Das Verfahren eignet sich auch für solche Fälle, daß ein Kollege aus</div><div>einer anderen Abteilung anruft und eine bestimmte Erg.Menge braucht,</div><div>die er selber nicht zustandebringt. Als Kenner der Materie kann man</div><div>die Menge rasch zusammenstellen, dann konservieren, den Kollegen</div><div>zurückrufen und sagen, "OK Alter, gibt mal ein  X emrek xyz!"</div><div>Cool, oder?</div><div><br></div><div>---------------------------------------------------------------</div><div><br></div><div>Am besten, um ein Gefühl dafür zu kriegen, gleich abholen und </div><div>ausprobieren. Hier die vollständige Beschreibung eines Beispiels:</div><div><br></div><div>DemoBank starten</div><div>In Suchbefehlszeile eingeben:  all drama?</div><div>Ergebnismenge entsteht, links sieht man bei Alt+e als letzte Zeile:</div><div>76 : all drama?    Das ist der "Titel" der Erg.Menge</div><div><br></div><div>Dann diese konservieren, unter dem beliebigen Dateinamen "schauspiel"</div><div>  X emkon schauspiel</div><div><br></div><div>Der Titel und die Primärschlüssel der aktuellen Erg.Menge "all drama"</div><div>werden gespeichert in schauspiel.erg</div><div>(Den neu ausgedachten Dateityp  .erg  gab es bislang nicht.)</div><div><br></div><div>Merke: Der Dateiname (schauspiel.erg) muß nichts zu tun haben mit</div><div>dem Ergebnismengentitel (all drama)</div><div>In der Datei schauspiel.erg (schauen Sie rein mit  h schauspiel.erg)</div><div>steht als erste Zeile der Erg.Mengentitel "all drama?".</div><div>So beginnt die Datei:</div><div><br></div><div>all drama?       Titel der Erg.Menge</div><div>378477277        Prim.Schl. des ersten Satzes</div><div>875208           Prim.Schl. des zweiten Satzes</div><div>...</div><div><br></div><div>Danach irgendeine andere Erg.Menge machen oder sonstwas anderes tun,</div><div>a99 beenden, neu starten, und dann eingeben:</div><div><br></div><div>  X emrek schauspiel</div><div><br></div><div>Es dauert je nach Umfang einige Sekunden, dabei entsteht die</div><div>Erg.Menge, die wieder den Titel  76 : all drama?  hat. Und inhaltlich </div><div>identisch ist mit derjenigen, die man konserviert hatte. Auch falls</div><div>keiner der Sätze noch die alte interne Nummer hätte.</div><div>Der emrek.flx hat eine Datei  schauspiel.set  erzeugt und diese dann</div><div>als "PRESTO"-Erg.Menge eingelesen. Sie beginnt so:</div><div><br></div><div>all drama?   Der Befehl zur Erzeugung der Menge</div><div>45           interne Nr. des ersten Satzes</div><div>101          interne Nr. des zweiten Satzes</div><div><br></div><div>Eben diese internen Nummern können nach längerer Zeit anders lauten,</div><div>die Primärschlüssel aber nicht - es sei denn man hat die Nummern in</div><div>der #00 verbotener Weise geändert, dann kann's nicht klappen.</div><div><br></div><div>ABER was ist, wenn in den Jahren seit Erstellung der Konserve</div><div>ein oder mehrere Titel gelöscht wurden?</div><div>Dann wirft  emrek.flx  im Anzeigefeld Meldungen aus:</div><div>    Satz  ...  ist nicht mehr da!</div><div>wobei  ...  der Prim.Schl. des nicht mehr auffindbaren Satzes ist.</div><div>Evtl. kann man diesen dann, wenn's einen interessiert, z.B. in einer</div><div>alten Sicherungskopie wiederfinden. Die neu erstellte Erg.Menge </div><div>enthält dann logischerweise nur die noch vorhandenen Datensätze.</div><div><br></div><div>Nachwort</div><div>Ein Schlauberger könnte jetzt fragen: "Wieso wurden denn nicht gleich</div><div>bei der Erfindung der Ergebnismengen in den .set-Dateien die Primär-</div><div>schlüssel verwendet und nicht die internen Nummern? Dann hätte man</div><div>sich jetzt die Arbeit sparen können für diese neuen FLEXe und hätte</div><div>schon längst die Erg.Mengen beliebig lange aufbewahren können!"</div><div><br></div><div>Nun, von Sitzung zu Sitzung werden sie ja längst aufbewahrt, wenn in</div><div>der .ini-Datei steht</div><div>SaveResults=1</div><div>Nur nach einer Gesamterneuerung, da stimmen einige Nummern u.U. nicht</div><div>mehr. Aber schlimmer noch: Primärschlüssel MUSS man gar nicht haben, es</div><div>geht auch ohne. Am Anfang der Entwicklung gab es sie noch nicht!</div><div>Erst mit der Erfindung des Updating mußte man sie einführen.</div><div>Man kann aber noch heute eine Datenbank ohne Primärschlüssel</div><div>konfigurieren und betreiben! Nur updaten geht dann nicht. Konservieren</div><div>leider auch nicht ... Ein Grund mehr, vom Verzicht auf Primärschlüssel</div><div>abzuraten.</div><div>Übrigens werden die Erg.mengen von Sitzung zu Sitzung nicht im DbDir </div><div>und nicht in .set-Dateien aufbewahrt, sondern in den cat.*-Dateien im</div><div>eigenen Arbeitsverzeichnis. Die haben eine ganz andere Struktur, die</div><div>aber auch auf den internen Nummern fußt. Sie sind so konstruiert,</div><div>daß der Start einer neuen Sitzung immer schnell geht und nicht umso</div><div>länger dauert, je mehr Erg.Mengen man aufbewahrt hat. Das wäre so,</div><div>wenn man es mit .erg-Dateien machen würde.</div><div><br></div></div></div>