Arbeiten in einem temporären TJvMemoryData

[waldforest]

Hallo,
ich bin auf der Suche nach Lösungsansätzen, mit der ich folgende Herausforderung angehen kann.

Ich habe z.B. eine Artikeltabelle mit entsprechenden Mengen für Lagerbetsand, einem Normbestand und einem Mindestbestand.

1.) Nun wird über eine Abfrage eine Bestellempfehlung ausgesprochen werden, welche in einem Grid angezeigt und weiter verarbeitet werden soll

2.) Im Grid selber sollen durch eine zusätzliche Checkbox Datensätze ausgewählt werden können
3.) die Möglichkeit bestehen die Bestellmenge zu ändern
4.) eine Bestellung nach Bearbeitung ausgelöst werden.

Mein derzeitiger Ansatz:
1.) Abfrage mit berechnenden Colums für die erforderliche Bestellmenge
2.) auf das Abfrageergebnis lege ich eine TJvMemoryData, welches diese Daten über
jvmrydt1.LoadFromDataSet(zqry_TabellenEdit,-1, lmappend, True ) einliest.
Hiermit möchte ich unterrbinden, dass direkt in der Datenbanktabelle gearbeitet wird

Nun zu meinem Problem 3 ud 4.

wie bekomme ich zusätzliche Columns in die TJvMemoryData für eine Checkbox, sowie eine bearbeitbare Bestellmenge, denn die errechnete Bestellmene(aus 1.) ist nicht bearbeitbar.

Ein zweiter Ansatz wäre eine global tempory table in meiner Datenbank zu erstellen.

Ist dieser Ansatz sinnvoll, welche Alternativen würdet ihr empfehlen.?

[Perlsau]

Was sinnvoll wäre, kommt u.a. auch darauf an, ob die vorgeschlagene Bestellung abgespeichert werden können soll, bevor eine echte Bestellung nach Bearbeitung ausgelöst wird.

Mich würde näher interessieren: Wer empfiehlt wem eine ganz bestimmte Bestell-Zusammensetzung? Wenn ein Kunde etwas bestellt, gibt's dann Wenns und Abers? Das einzige Kriterium, das ich mir denken kann, wäre die Verfügbarkeit des bestellten Artikels: Hab ich's am Lager oder muß ich erst nachbestellen. Oder geht's etwa um diese Nachbestellung bei eurem eigenen Lieferanten? Wenn ja, dann würde ich diese Bestellungen auf jeden Fall in einer eigenen Tabelle führen, da man so leicht überprüfen kann, was wann von wem bestellt wurde. Dabei kannst du ja noch zwei weitere Datumsspalten mitführen:

1. Datum der Bestellungs-Zusammenstellung – pro Lieferant immer nur eine, da pro Lieferant ja auch stets eine gesonderte Bestellung rausgehen muß.
2. Datum der Bestellungs-Absendung – wann wurde die Bestellung ausgeführt.
3. Datum der Lieferung der bestellten Artikel

Sind alle drei Spalten mit Datumswerten befüllt – Nicht-Null erlauben –, gilt die Bestellung als abgeschlossen. Die einzelnen Artikel einer jeden Bestellung führst du selbstverständlich in einer separaten Tabelle: Bestell-ID, Artikel, Anzahl. Dito die einzelnen Bestellungen eurer Kunden.

[Dejan Vu]

Ich verstehe nicht, wieso
1. eine Spalte eines Memory-Datasets nicht bearbeitbar sein sollte
2. Du keine zusätzlichen Spalten in das Dataset einfügen kannst.

Wenn dann das 'LoadFrom' nicht mehr funktioniert, machst Du das eben per Hand:

Delphi-Quellcode:

Procedure CopyData(aSrc, aDest : TDataSet);
Begin
  aDest.DisableControls;
  Try
     aSrc.First;
     while not aSrc.Eof do begin
        aDest.Append;
        aDest['Field1'] := aSrc['Field1'];
        ...
        aDest.Post;
  Finally
     aDest.EnableControls;
  end
end;

Natürlich musst Du dafür sorgen, das die Zieltabelle leer ist (außer, Du willst sie erweitern). Auf diese Weise bist Du aber von der Quelltabelle vollkommen unabhängig, denn Du kannst so die Query jederzeit ändern und musst dann nur in dieser Routine das Mapping (also die Zuweisungen) anpassen. Die Zieltabelle (dein Memory-Dataset) bleibt davon unberührt.
Umgekehrt kannst Du nun auch die Memorytabelle in ihrer Struktur verändern, ohne die Query anfassen zu müssen. Beispielsweise mit zusätzlichen Feldern.

Zu Punkt 4: Du kannst im AfterPost-Event des Memorydatensatzes weitere Aktionen auslösen, aber das würde ich nicht tun. Stattdessen würde ich den Anwender die Bestellungen (im Memory) bearbeiten lassen und erst nach Bestätigung (OK-Taste, 'Wollen Sie die Bestellungen jetzt auslösen') gehst Du durch die Tabelle und führst für jeden Datensatz die Bestellung aus.

[Sir Rufo]

Du möchtest also Bestell-Vorschläge erstellen und der/die Benutzer sollen diese dann bearbeiten.
Aus diesen Bestellvorschlägen werden dann Bestellungen generiert.

Im Mehrnutzerbetrieb kann es fatal sein, wenn diese Vorschläge nicht systemweit bekannt sind, denn dann können mehrere User Artikel doppelt und dreifach bestellen.

Für einen Bestellvorschlag werden übrigens weitere Informationen benötigt, ausser dem Lagerbestand, Norm- und Mindest-Bestand.

Die Mengen aus noch offenen Bestellungen und die Mengen aus offenen Kundenaufträgen (soweit es das in der Anwendung gibt) und evtl. die Menge an unverkäuflichen Artikeln (Reklamationen).

Zusammengefasst benötigst du beim Bestellvorschlag die Menge die real zum Verkauf zur Verfügung steht.

Diese Informationen sammelst du und schreibst diese in die Bestellvorschlag-Tabelle, die dann von den Benutzern bearbeitet werden kann. Zusätzlich kannst du auch eine Spalte hinzufügen, wo der User hinterlegen kann, ob und warum dieser Bestellvorschlag nicht angenommen wird.

Ist der Bestellvorschlag abgearbeitet, dann erzeugst du daraus die Bestellung.

Bei einem neuen Bestellvorschlag werden alte nicht bearbeitete Bestellvorschläge entsprechend deaktiviert.

[waldforest]

Hallo,
jetz brauche ich doch noch mal Hilfe bei meiner SQL Abfrage.

Was will ich hier erreichen.
Ich muss die empfohlene Bestellmenge wie folg berechnen.

Normmenge - Lager_ist - bereistbestellt + Rückstände

Mein Lager umfasst ca 10 000 Artikel.

Aktuell habe ich meine Abfrage wie folgt aufgebaut, läuft auch, wenn in der Rückständetabelle, bereistbestellte-Tabelle nur wenige Einträge vorhanden sind schnell. Sobald aber in den Tabellen der Rückstände bzw. bereist bestellten viele Einträge (> ca. 50) ist dies mit langen Wartezeiten verbunden.

Nun bin ich was SQL betrifft noch am Anfang meiner Lernkurve, und denke, dass sich hier noch etwas optimieren lässt. Leider kann Firebird im Wherer keine Alias verabeiten.

Hat jemand einen Tipp wie ich hier im WHERE optimieren kann ?

SQL-Code:

Select A.Art_ID, A.Art_HERSTNR, A.Art_LIEFERANT_ID, A.Art_VKTEXT_DE AS VKText, 
((SELECT ( (A.Art_Lag_NORM-A.Art_Lag_IST) - IIF(SUM(N.NBEST_BESTM) IS NULL, 0, SUM(N.NBEST_BESTM))FROM NACHBESTELLUNG N WHERE N.NBEST_Art_ID = A.Art_ID)+
(SELECT IIF(SUM(r.Art_MENGE) IS NULL, 0, SUM(r.Art_MENGE)) FROM RUE_Art r WHERE R.Art_ID = A.Art_ID  )) as Empfehlung, 
(A.Art_Lag_NORM-A.Art_Lag_IST) AS Bedarf, 
SELECT IIF(SUM(r.Art_MENGE) IS NULL, 0, SUM(r.Art_MENGE) ) FROM RUE_Art r WHERE R.Art_ID = A.Art_ID) as Rueckstand, 
SELECT (IIF(SUM(N.NBEST_BESTM) IS NULL, 0, SUM(N.NBEST_BESTM))-IIF(SUM(N.NBEST_LIEFERMENGE) IS NULL,0,SUM(N.NBEST_LIEFERMENGE)))  FROM NACHBESTELLUNG N WHERE N.NBEST_Art_ID = A.Art_ID) as Bestellt ,
A.Art_Lag_IST , A.Art_Lag_MIN , A.Art_Lag_NORM WHERE A.Art_Lag_IST + (SELECT IIF(SUM(N.NBEST_BESTM) IS NULL, 0, SUM(N.NBEST_BESTM))) FROM NACHBESTELLUNG N 
WHERE N.NBEST_Art_ID = A.Art_ID)  - (SELECT IIF(SUM(r.Art_MENGE) IS NULL, 0, SUM(r.Art_MENGE)) FROM RUE_Art r WHERE R.Art_ID = A.Art_ID  )) <= A.Art_Lag_MIN and A.Art_LIEFERANT_ID = :xLiefernat_ID;

Ich habs jetzt temporär mit einem Filter gelöst und die Where nur auf den
A.Art_LIEFERANT_ID = :xLiefernat_ID gesetzt. Geht sicher eleganter ??

[Sir Rufo]

Es ist etwas suboptimal, wenn du das SQL-Statement im Delphi-Quelltext präsentierst, wenn es eigentlich nur um das SQL-Statement geht.

Pack das Statement doch bitte einzeln in SQL-Code-Tags
[ CODE="SQL" ]
[ /CODE ]
(Leerzeichen vor und nach den eckigen Klammern müssen weg)

SQL-Code:

select *
from foo
where bar is null

und schwupps kann man das ganz wunderbar lesen