AW: [Allegro] A99-Update-Ergänzungen

[Fischer, Thomas]

Hallo Herr Eversberg,

meine aktuellen Update-Versuche mit a99 (immer noch 32.7, aber jetzt vom 15.8.) auf meinem Win 7 /64bit-Rechner führen immer noch zu schwer kontrollierbaren Problemen - teils schon beim Update (hängenbleiben) teils beim Speichern (Absturz).
(Das hat mit den gestrigen Problemen nichts zu tun - andere Datenbank, anderer Rechner, andere Daten).
Tut sich (tun Sie?) da noch etwas? (Ich hatte Ihnen am 8.8. ein Testpaket geschickt.)

Mit freundlichen Grüßen
Thomas Fischer


> -----Ursprüngliche Nachricht-----
> Von: allegro-bounces at biblio.tu-bs.de [mailto:allegro-bounces at biblio.tu-bs.de] Im
> Auftrag von Bernhard Eversberg
> Gesendet: Mittwoch, 8. August 2012 13:35
> An: Allegro-C Diskussionsliste
> Betreff: Re: [Allegro] A99-Update-Ergänzungen
>
> Am 08.08.2012 12:05, schrieb Fischer, Thomas:
> >
> > ich muss noch einige Ergänzungen zu der gestrigen Mail nachtragen.
> >
> > 1. Die gestrigen Erfahrungen bezogen sich auf einen Win 7 / 64 bit
> > Rechner. Ich habe heute den gleichen Update auch meinem Win XP
> > (Mac-Parallel Desktop) laufen lassen, da ist das vollständig
> > durchgelaufen, ohne Fehler am Anfang oder Ende und ohne den Speicher
> > (und damit die Buttons) zu tangieren.
> Aha! Hier war das ein 7'32er, dann muß ich mal den 64er noch bemühen.
>
> > Die Abbrüche an dem Win
> > 7-Rechner fanden immer nach relativ großen Datensätzen statt, wenn
> > Sie wollen, schicke ich Ihnen die Daten.
> >
> Kann nicht schaden. Bei meinen Tests waren welche dabei mit 5.800 Byte
> Länge. Richtig lang ist das nicht.
>
> > 2. Bei dem Update läuft eine sehr flotte Anzeige mit, die manchmal
> > länger wurde, aber nicht zu lesen war. Wird das irgendwo
> > hingeschrieben? Was kann das bedeuten?
> Das ist nur, damit man sieht: es passiert was. Die laufende Nr. wird
> da gezeigt sowie die interne Satznummer. (Der Fortschrittsbalken läßt
> sich in dem Fall nicht gut nutzen, weil bei der sequentiellen
> Durcharbeitung das Programm nicht feststellen kann, wieviel Prozent
> schon geschafft sind.)
>
> > Soweit ich sehe, wurden alle
> > Datensätze erkannt und es gab keine Dubletten. (Die Prüfung auf
> > Dubletten "mehr als 1" in dem Register mit den Indentnummern dauert
> > übrigens unangenehm lange, man kann sich zwischenzeitlich einen
> > Kaffee holen gehen. Ließe sich da etwas machen?)
> >
> Das ist mir neu. Ist das konsistent?
> Lange kann's beim Speichern dauern, wenn ein neuer
> Speicherort gesucht werden muß im Reg. 1, und es dort viele Leersätze
> gibt ((//-Zeilen), aber alle in anderen Dateien.
>
> > 3. Das Speichern danach (knapp 30.000 Datensätze) dauert sehr lange
> > und erfolgt immer noch ohne visuelle Rückmeldung.
> >
> Da müßte man noch was machen können.
>
> > 4. Die Suche mit srch funktioniert auf dem XP-Rechner nicht, ich
> > bekomme die Meldung
> >
> > --------------------------- srch.exe - Einsprungpunkt nicht gefunden
> > --------------------------- Der Prozedureinsprungpunkt
> > "DecodePointer" wurde in der DLL "KERNEL32.dll" nicht gefunden.
> > --------------------------- OK ---------------------------
> >
> > (srch.exe vom 11.7.2012 aus dem aktuellen inst-all.exe) Vielleicht
> > habe ich da auch eine minderwertige "KERNEL32.dll"?
> Oder wir müßten auch da mit der statischen Einstellung kompilieren.
>
> >
> > Mit srch16 wird mir ein Fenster angezeigt, in dem ich die gewünschten
> > Dateien auswählen kann:
> >
> Ja, aber das geht eben unter Win'7/64 nicht und Linux.
>
> B.E.
>
>
> _______________________________________________
> Allegro mailing list
> Allegro at biblio.tu-bs.de
> http://sun250.biblio.etc.tu-bs.de/mailman/listinfo/allegro