Das große WIE, Chart aktuallisieren, Daten in textfiles

[Stecky2000]

Kann es ggf. an meiner Ausstattung liegen?

Da mich mein Sohnemann nicht an meinen richtigen Rechner lässt, programmiere ich auf einem alten Pentium II mit 400 mhz und 768 mb RAM, mit scsi Platten.

Darauf W2K und Delphi 5 Enterprise,Firebird 2.1 Superserver.

Ich werde morgen früh gleich mal das mit dem next versuchen.

EDIT: Habe eben noch mal ohne NEXT versucht, klappt nicht.
Da beschreibt er nur den ersten Datensatz und geht nicht weiter.

Ich habe eben mal die Anwendung mit Firebird embedded auf den größeren PC kopiert (3 GHz Pentium-IV, 1GB RAM) da geht es in 4 Sekunden. Ich finde, das ist immer noch zu langsam.

[haentschman]

Hallo...

was mir aufgefallen ist, ist die Tatsache, daß du in den Schleifen jede einzelne Spalte der Tabelle änderst.

Auszug:

Delphi-Quellcode:

IBTable1.First;
   For i := 25 to 288 do
     begin
       IBTable1.Edit;
       IBTable1['AGRPMo']:= StrToFloat(StringGrid2.Cells[1, i]); 
       IBTable1['AGRPDi']:= StrToFloat(StringGrid2.Cells[2, i]);

versuche das mal mit IBTable1.AppendRecord(StringGrid2.Cells[1, i],......,StringGrid2.Cells[14, i]) d.h. den Datensatz in die Tabelle im Ganzen anhängen (Edit und Next einsparen) ...vieleicht geht das schneller. :gruebel:

die Verzögerung resultiert IMHO aus den Kombinationen mit den Schleifen und dem Ändern der einzelnen Spalten.

vieleicht hilft es ja... :hi:

PS: Ich sehe Dein Vorhaben als Import der vorhandenen Daten in die Datenbank. Solange die Daten richtig ankommen wären mir die Sekunden egal, da der Import ja sowieso nur einmal läuft und dann ja mit der Datenbank gearbeitet wird. :roll:

[DP-Maintenance]

Dieses Thema wurde von "Christian Seehase" von "Programmieren allgemein" nach "Datenbanken" verschoben.
Stellt sich doch eher als Datenbankproblem heraus

[Stecky2000]

Danke für den Tipp, werde es bei Gelegenheit testen. Leider kann ich Dir nicht Recht geben, es ist kein Import und findet keineswegs nur ein Mal statt.

Die Sache ist die....

Wir haben 4 Abteilungen, die das gleiche produkt bearbeiten, aber jeder zu einer anderen Zeit, mehr oder weniger. Im Endeffekt gibt es für jede Abteilung eine eigene Bedarfskurve für 24 Stunden im 5 Minuten Raster. Jede Abteilung hat verschiedene personalstärken und verschiede Dienstpläne.

Wenn ich einen Dienstplan ändere, sollen die Änderungen sofort in Grafiken angezeigt werden.
Dazu müssen verschiedene Dienstpläne einer gleichen Kategorie addiert werden, was ja unter einer Sekunde dauert, aber das Schreiben in die Datenbank dauert eben.

Ggf. gibt es die Möglichkeit, aus den Daten im StringGrid (RAM) Grafiken (Charts) zu erzeugen und zu verändern. Damit habe ich mich noch nicht befasst.

Zur Zeit geht meine Idee noch in die Richtung, die Daten in die Datenbank zu schreiben und das Chart bedient sich da mit Daten.

EDIT:

Verstehe ich Deinen Vorschlag richtig, er funzt nur wenn ich neue Datensätze anfüge?
Ich erzeuge die 288 Zeilen/Datensätze nur beim ersten mal, danach werden sie immer nur überschrieben.

EDIT2: Juhuuuu, ich glaube ich habs.... :wall: :wall:

Ich hab mir gedacht, wenn das Speicher in die DB so lange dauert, dann erzeuge ich die Chart direkt aus dem StringGrid un hab testweise eine Button mit diesem Code verwendet:

Delphi-Quellcode:

procedure TMainForm.Button3Click(Sender: TObject);
var
i: Integer;
begin
     for i:=1 to 289 do
         Series1.Add(StrToFLOAT(StringGrid2.Cells[1,i]));
end;

Das erzeugt die Chart unter einer Sekunde. Theoretisch könnte ich die Fertigen Inhalte aus dem StringGrid statt in eine DB in ein Textfile schreiben. Somit kann ich die Daten für Excel usw. verwenden, die Frafiken sind schnell und das ist es eigentlich was ich will.

[haentschman]

ah ja... :gruebel:

- ich hatte verstanden, daß du dich von dem Textformat kpl. verabschieden möchtest. IMHO wäre das sinnvoll.

Zitat:

Wenn ich einen Dienstplan ändere, sollen die Änderungen sofort in Grafiken angezeigt werden.

- die neuen Daten / Änderungen könnten direkt in der Datenbank ablaufen.

Zitat:

Wir haben 4 Abteilungen, die das gleiche produkt bearbeiten, aber jeder zu einer anderen Zeit, mehr oder weniger.

- Datenbank (außer embedded) ist multi User fähig. Alle arbeiten mit der gleichen Datenbank. Damit fällt ein Import flach und alle Daten sind sofort aktuell.
- wenn die Daten einmal in der Datenbank sind macht der Chart in ms eine Grafik draus :-D

- somit müßtest du die bestehenden Daten nur einmal vom Text in die Datenbank importieren und gut. :thumb:

Zitat:

Verstehe ich Deinen Vorschlag richtig, er funzt nur wenn ich neue Datensätze anfüge?
Ich erzeuge die 288 Zeilen/Datensätze nur beim ersten mal, danach werden sie immer nur überschrieben.

...selbstverständlich nur mit hinzufügen der Datensätze. Davon bin ich ja beim Import ausgegangen.

Empfehlung: überdenke bitte dein Konzept mit der Datenhaltung. Mischen Text / Datenbank und hin- und herkonvertieren ist unperformant. Nur eine Datenbank ist IMHO der richtige Weg.

PS: warum liegen die Daten nur in Textform vor.

Hoffe trotzdem Denkanstöße vermittelt zu haben... :hi:

[Stecky2000]

Hallo Leute, sorry dass ich so lange gebraucht habe, bis ich geantwortet habe.

Ich bin allen sehr dankbar für die Hilfe und die Tipps.

Ich denke aber, dass ich z. T. nicht richtig verstanden werde, was definitiv nur an mir liegt.
Ich hoffe, Ihr seid mir nicht böse.

Ich bin an deutschlands größtem Flughafen für einen Bereich mit über 2000 Mitarbeitern für Personalbedarfsplanung und Dienstplangestalltung zuständig.

Vor vielen Jahren, hatten wir einen Studenten der Informatik studiert hat. Der hat damals ein Dienstplanprogramm auf Excel-Basis programmiert, mit Makros und einem Pascal Modul für die Berechnung.

Das Ding ist in die Jahre gekommen, ich musste es erweitern und den neuen Bedürfnissen anpassen.
Leider ist es sehr Fehlerträchtig, wegen tausender von Formeln, Bedarf eines besonderen Laufwerkbuchstabens etc.. Ich bin mittlerweile der einzige der das Ding noch bedienen kann.

Im Endeffekt bekomme ich aus Excel 5 Bedarfskurven über 24 Stunden. 4 für unsere 4 untergeordneten Abteilungen, eine Addition dieser 4. Das ganze muss man sich X 7 Tage vorstellen.

Im Endeffekt funktioniert es so, dass man immer aufbauend auf den Dienstplänen der vergangenen Saison aufsetzt und Änderungen durchführt um die Abdeckungskurve, die von den ganzen Dienstplänen erzeugt wird, optimal an die Bedarfskurve anzupassen.

Jetzt stelle sich einer vor, pro Abteilung gibt es verschieden Dienstplantypen:
Stamm in Gruppen
Stamm in Einzeldienstplänen
Stamm Verfügungsschichten
Fremd eine bestimmten Fa.
Fremd Studenten

In den Gruppenplänen werden z.T. in einem Plan über 300 MA verwaltet, in Einzeldienstplänen 1 MA.

Jetzt ändere ich an einem Plan eine Zeit. Dann muss ich ein Makro ausführen welches wiederum ein Pascal Modul aufruft und Berechnungen durchführt, dauert ca. 5 Sek.. Dann muss ich den Plan mit den berechneten Daten speichern und schliessen. Danach muss ich die Exceldatei mit den Grafiken aufrufen die alle Dienstpläne dieser Abteilung einliest und in der Kurve darstellt.
Danach noch die Exceldatei mit den Grafiken für alle 4 Abteilungen aufrufen, aktualisieren, speichern....

Ist sehr aufwendig.

Wenn man mal zum Schluss gekommen ist, müssen die Dienstplandaten in eine von der Personalabteilung verwendetes und vom Betriebsrat abgenommenes Excelsheet übernommen werden (copy-paste).

Die Daten der Abdeckung wiederum in ein Excelsheet welches in einem Word Dok verankert ist....


Meine Idee ist ein DPL-Programmwelches eine Saisonverwaltung besitzt, mit kopieren, löschen etc. (hab ich bereits programmiert). Die Dienstpläne sollen in einem dynamisch erzeugtem Menü nach Abteilungen und verschiedenen anderen Unterkategorien geordnet dargestellt werden (hab ich bereits programmiret).
Es soll bei Änderung einer Date in einem Dienstplan sofort im Hintergrund die Abdeckungskurve berechnen und gleichzietig von Dienstplan erzeugte Bedarfe (Pause, Dienst- und Gruppengespräche) berechnen.
Zusätzlich berechnet es online verschiedenste Daten die im Plan angezeigt werden (hab ich bereits programmiert).

Dann kommt der teil den ich hier versucht habe umzusetzen.

Es soll die Berechnungen sofort in Charts umsetzen und zwar wenn möglich ohne Wartezeit. Und das gelingt mir mit der Datenbank nicht.

Ich bin dabei ein Modul zu schreiben, welches ausgehend vom geänderten Plan nur diese Dienstplankategorie, der betroffenen Abteilung neu berechnet und zwar im RAM im StringGrid und sofort im Chart visualisiert.
Ich stelle mir 4 StringGrids im Hintergrund vor, nicht visuell ;-), für die Daten jeweils aller Dienstplankategorien einer jeweiligen Abteilung. Und dann noch ein 5 StringGrid zur Addition der 4 Abteilungsstringgrids und Visualisierung in einem Gesamt-Chart.

Letztendlich speichern die Pläne alle ihre Daten in Textfiles mit Komma getrennt ab. Es gibt Textfiles für Dienstplandaten und welche für die Kurvendaten. Wenn es schlimm kommt, ändere ich einen Einzeldienstplan, in dessen Kategorie 25 - 30 Pläne existieren. Diese werden dann eingelesen, berechnet und ins StringGrid geschrieben. Das dauert unter einer Sekunde. Gehe ich auf die DB dauert es zwischen 5 und 10 Sekunden.

Das bedeutet, für mich sieht es danach aus, als ob eine Lösung mit Textfiles und StringGrids definitv schneller ist als eine Datenbanklösung.

Desweiteren gibt es eigentlich keinen Bedarf, die Daten in einer Datenbank zu halten ausser die Darstellung in eine Grafik und die ist im StringGrid schneller.

Dennoch gibt es bestimmt viel Potential, die Berechnung der Dienstpläne weiter zu beschleunigen.

So, lange Geschichte, aber mir war es wichtig zu erklären, warum ich mich so entschieden habe wie ich es habe. Ich bin der Nutzer des Programmes, mein eigener Kunde. Und mein Hauptaugenmerk liegt auf der Performance. Dennoch bin ich wirklich sehr dankbar für Eure Hilfe und Eure Gedult.
Ich hoffe Ihr seid mir nicht böse, wenn ich nicht jeden Rat annehme und meinen Kopf durchsetze und unterstützt mich trotzdem weiter wenn ich Fragen habe.

Ich habe bereits viel hier von Euch mitnehmen können, z.B. das Anzeigen im StringGrid abweichend vom tatsächlichen Inhalt (OWNERDRAW), das Speichern der Daten in Textfiles, dynamische Menüs etc..

Also, in diesem Sinne.