Inoffizielles deutsches Xbase-Forum

Hallo Zusammen,

habe in letzter Zeit mit einer Clipperanwendung unter WIN XT folgendes Problem

Wenn das Programm einen Index erstellen will - index on field to path+datei - kommt die Meldung Out of memory.
Das Programm ist ein Warenwirtschaftssystem und täglich 8 Stunden im Netzwerk auf drei Geäten in Betrieb.
Der Fehler tritt unregelmäßig auf. Oft wochenlag nicht, dann wieder mehrmals täglich.

Kennt wer das Problem und hat dafür eine Lösung ?
Bin für jede Anreguing Dankbar
Gofi

Gofi hat geschrieben:Wenn das Programm einen Index erstellen will - index on field to path+datei - kommt die Meldung Out of memory.

Cl*pper benötigt "real" Mode RAM der bis 640Kb geht.
Wenn ich in der CMD/DOS Box dann MEM eingebe zeigt er mir ca. 600Kb womit man ein "kleines" Cl*pper Programm noch laden kann.

Nun gibt es unter Windows aber kaum eine Trick um mehr Speicher im CMD/DOS Fenster zu bekommen den 640kb ist nun mal die Grenze bei "real" Mode.

Das es "mal funktioniert" und dann wieder nicht sagt mir das dass Cl*pper Programm "so eben gerade" läuft und schon 1-2Kb RAM es wohl ausmachen.
Zum Index erstellen sollte man also rebooten um möglichst viel "freien" Speicher zu haben.

ansonsten :
1.) aus der Config.NT und Autoexec.NT alles raus was man nicht braucht
2.) KEYb... gegen K3 oder anderen "kleineren" Keyboard Treiber wechseln
3.) Wenn du den Source hast könnte man versuchen das Cl*pper EXE in Overlays zu "zerlegen" und es mit TLink (Borland Linker) oder Blinker wie zusammenbauen ... bringt paar Kb.

... aber wenn du eh den Source haben sollte benutzte doch Xbase++ !

Hallo Jimmy,

600 KByte DOS Speicher sind sehr viel !

Wobei mein XP 655360 Bytes mit 620928 max für Programme ausgibt.
Unter reinem DOS und auch Win98 hat man nie so viel gehabt und dieser wird auch sofort wieder freigegeben,
sobald ein DOS Fenster geschlossen wird. JEDES DOS Fenster erhält im übrigen soviel Speicher.
Mit Netzwerktreiber war ich oft um die 400 KByte ...

Jedes neue DOS Fenster verhält sich wie ein eigener Clipper 87 PC - nur die Systemauslastung ist hoch ...

Es könnte sein, dass zuviel Speicher (auf der Festplatte) frei ist und eine interne Abfrage auf noch freien Speicher
überläuft ...

brandelh hat geschrieben:600 KByte DOS Speicher sind sehr viel !

aber nicht für S87, den da gab es ja noch keine "Memory Manager" oder GC wie bei Xbase++
Wenn ich nicht irre musste ich wenigsten noch 32kb "im Block" haben um ein "Index on" durchzuführen, aber der Speicher "fragmentiert" mit der Zeit.
Deshalb der Tip "am Anfang" das "Index On" laufen lassen.

"Der" Grund für den Umstieg auf Cl*pper v5.x war der "real" Mode, das sich erst mit Exospace/Blinker v2.x "extend" Mode gelegt hat.

Frage : konnte S87 mit EMS umgehen ? ... man kann doch die CMD/DOS Box auf EMS konfigurieren ...

Hi Jimmy,

möglich dass du so riesige EXE hattest, dass du deshalb den Exospace nutzen musstest, aber "normale" Programme sind auch noch mit 400 KB gelaufen. Ich wollte nur sagen, dass ein DOS Programm unter DOS nie so viel Speicher hatte wie es heute in einer DOS (CMD) Box hat. Alle meine Programme mussten sich damals den Speicher noch mit Netzwerktreibern (IBM NetBios), Maus und Tastaturtreiber etc. teilen und liefen mit 400 KB gut.

Gofi - liegen die Quellen dieses Programmes vor oder habt Ihr nur die kompilierte Anwendung?

Hallo,
habe den Source-Code
ist ein grosses Programm (Warenwirtschaft mit allem was dazu gehört - Auftragbearbeitung,Bestellung Fakturierung)
Besteht aus 30 Programmen, die in Grundmodul und 7 Overlays aufgeteilt sind (plink86). Gesamtgröße ca 242 KB
Das Programm hat auf Win98, WIN NT und bis vor Kurzem auch auf WIN XT eigentlich klaglos funktioniert (zumindest kamen keine
Klagen von den usern).

Hallo, Gofi.

Wochenlang nicht, dann mehrmals täglich - das weist auf zweierlei hin: Erstens wächst der Speicherbedarf der Applikation über ihre tägliche Nutzungsdauer hinweg, vor allem, wenn man nicht sehr sauber programmiert hat, aber bei C87 gab es in diesem Zusammenhang meiner Erinnerung nach recht viele Bugs. Vermutlich würden diese Fehler nicht auftreten, wenn die Benutzer vor dem Re-Indexieren das Programm verlassen und neu starten würden. Und zweitens ist ein INDEX ON ... TO tatsächlich - abhängig von der Größe der zu indexierenden Tabelle!! - ein speicherfressender Prozess. Die Meldung "Out of memory" bedeutet also schlicht das, was sie sagt: Der Applikation steht nicht mehr genügend Hauptspeicher zur Verfügung. Und sie kann ja längst nicht den gesamten verfügbaren Speicher adressieren.

Mit Clipper 5.2 dürfte dieses Problem nicht auftreten, erst recht nicht in Verbindung mit Blinker. Eigentlich sollte sich diese Applikation, sofern sie keine Drittbibliotheken nutzt, auch nativ mit Xbase++ (Textmodus) kompilieren lassen, dann gäbe es sowieso keine Speicherprobleme mehr.

Gofi hat geschrieben:habe den Source-Code

das ist doch schon mal sehr gut !
wie ist es mit 3PP Zusatz Lib´s ?

Gofi hat geschrieben:Besteht aus 30 Programmen, die in Grundmodul und 7 Overlays aufgeteilt sind (plink86). Gesamtgröße ca 242 KB

das ist schon ganz schon "gross" wenn man 7 Overlays hat ...

man könnte mit Memory(0) vor dem "Index ON" abfragen ob mind. 32kb "free" sind.

Frage : "wann/warum" ist das "Index ON" notwendig ? ist die Routine "im Overlay" ?

Hi,

wenn du den Source-code hast und keine Zusatzbibliotheken verwendet wurden,
wäre es sehr sinnvoll den Umstieg auf Xbase++ durchzuführen. CLIPPER und DOS sind tot !

In der Wissensdatenbank habe ich einen Artikel von der DEVCON MIG_01 veröffentlicht, der
das beschreibt. Wenn Xbase++ nicht vorhanden ist, kannst du dir die Testversion holen und sehen
was du in einer oder zwei Wochen machen kannst. Wenn Clipper nicht allzusehr vergewaltigt wurde,
sollte es möglich sein eine 1:1 Umsetzung in 4 Wochen durchzuziehen und Ihr habt die nächsten Jahre Ruhe !

Xbase++ Grundversion, eventuell noch die XbToolsIII sollten reichen.
Falls Ihr nicht selbst ran wollt, findet Ihr hier sicher einen der das macht.

Alles andere ist verlorene Zeit, 7 Overlays ... =D>

Wer es nicht lassen will, könnte versuchen einen Blinker für Clipper zu bekommen.
Mit diesem Linker konnte man einige Grenzen sprengen, aber ich bin mir nicht mehr sicher ob der mit S87 funktioniert. Wir sind damals sehr schnell komplett auf Clipper 5.x umgestiegen.

Hallo,

Blinker ging auch mit Summer 87.

Aber nicht auf den Technology-Partner-Link
von Alaska-Software klicken.

Der geht, wie so häufig, ins Leere.

Vielleicht hier: http://www.grafxsoft.com/

Gruß
Jürgen

Also so groß ist das Programm nun auch wieder nicht. (Meine Warenwirtschaft, erst Clipper 5.2 nun xHarbour besteht aus 81 Programmdateien mit ca 6 MB Code)
Blinker kann dir womöglichn helfen, kann aber für C87 keine ProtectedMode Version erstellen. Und in der zeit, die Du für eine ev. Umstellung auf Clipper 5.2e brauchst, kannst es auch locker nach xharbour rüber ziehen.

Da ich xbase ++ eher weniger kenne würde ich dir raten das ganze mal einfach mit xHarbour kompilieren zu lassen. Wenn Du keine zusätzlichen Libs und sonst keine bösen Gimmicks verwendest, sollte es in max. einigen Tagen laufen.

Die Frage ist halt, wieviel Aufwand Du in das Prog noch reinstecken willst/musst. Aber wenn es noch länger laufen muß, wirst Du um eine Konvertiertung nach xHarbour oder Xbase++ nicht herum kommen. Und für Gui ist in jedem Fall eine komplette Neuentwicklung notwendig.

mfg Michael Hagl

Hallo Gofi,

hier muß ich Michael absolut zustimmen. Ich investiere in meine Clipper-Anwendung auch so gut wie keine Zeit mehr, sondern in Xbase++ GUI. - Es gibt Vista64, Windows7 64-Bit - hierbei laufen KEINE DOS-Programme mehr. Und mit GUI ist dies eine Neuentwicklung - aber wirst daran nicht vorbeikommen.

Hi,

es gibt das Programm DOSBOX (oder Treiber ?), mit dem habe ich eine Clipper unter Win7 Home Premium 64 Bit zum Laufen bekommen, aber dennoch bleiben die bekannten Clipperprobleme

Dieses Phänomen tritt zuweilen auf und die Ursache ist ja hinlänglich bekannt ( Speicher, Indexpuffer ect. )

Eine mögliche Lösung klingt zwar brachial ( und sie ist es auch ) aber sie funktioniert klaglos.
Vorraussetzung:
BLINKER und wenn möglich einen selbstgestricken Scriptinterpreter wobei du den gerne von mir haben kannst.

Vorgangsweise:
Swappen, via Scriptinterpreter Index aufbauen ( oder auch jeden beliebigen anderen sourcecode zur Laufzeit
ausführen ), retour ins Programm und weiter gehts ohne Abflug.

Anstelle eines Scripts kannst du natürlich auch eine kompilierte EXE aufrufen aber die ist halt wieder
fix codiert und lä0t keinerlei Flexibilität hinsichtlich Sourceänderung ohne Kompilat zu.

ahoi und prost, flanelli

hi,

ich musste mal , unter Win7, an die Autoexec.NT und Config.NT ... es ging um Z/Y und EMS
nun habe ich dies entdeckt. wenn man nun MEM in der CMD Box eingibt hat man auch EMS 1024KB

btw. mit Notepad (Editor) als Administrator öffnen/speichern ... sonst meckert er

Das ding hatte ich auchschon aber unter win98se

und zwar war das phänomen verschwunden nachdem ich das programm in eine andere datei umgebung gesetzt hatte.
der fehler liegt defenetive im dos dateisystem und mit sicherheit auch schon bei ibm soweit konnte ich den fehler zurückvefolgen.

man muss überlegen das das windows unter ibm entstanden ist ,es ist mit fast 100 PROZENT eine sequenz im dateinamen.

dieser fehler tritt nur auf wenn 2 path+dateinamen in der sortiereinfolge hintereinander liegen ,dann wird die sortier seqenz nicht abgeschlossen soweit konnte ich dem hier folgen.

setzt das program mal mit subst in einer anderen datei umgebung vileicht geht das.

gpk

Ich nutze für die reine MS-DOS(e) DosBox in Verbindung mit D-Fend Reloaded, die einem mit allen Einstellungen eine MS-DOS-kompatible Umgebung mit 632kB freien konventionellen Speicher bietet. Da manch ein Kunde noch mit Raritäten ankommt, die nur noch auf einem 386/486er laufen, was man sicher aber nicht mehr hinstellen kann.

Ich habe noch einen alten c64 Emulator wenn du möchtest kann ich dir den auf den server posten -lol-
ist kompatible mit der 1541.

im ernst ist sicher das der fehler sich mit geschliffen hat bis ins xp, hast du schon eine andere umgebung probiert.
ich hatte am schluss mit dem debzgger weitegesucht es war nichts zu finden

dann habe ich einige verzeichniss bäume gelöscht und dann ging es wieder.

zum beispiel chr(0) im dateiname und dann ist sense.

oder such mal ordnereinträge wo nur die extension aber kein dateiname angegeben ist ( chr(0) )
hatte ich bei mir auch gefunden, unklar ist was dann indexiert wird wenn kein dateiname vorhanden ist