Ändern von Datenmengen

[davar]

Hallo Leute,

erst mal sorry wegen der Überschrift, was besseres ist mir nicht eingefallen.. :)

Folgendes Problem:

ich verkaufe einem Kunden mehrere Artikel, diese werden in der Tabelle "verkauf" gespeichert (kundennummer, position, artikelnummer, menge, einzelpreis).

Nun soll eine Rechnung gedruckt werden, vorher jedoch sollen die Daten geändert werden. D.h, der Chef hat mit dem Kunden einen anderen Preis vereinbart als den normalen, also soll in der Rechnung ein anderer Betrag drinstehen (Position und Artikelnummer sollen so stehenbleiben, Menge und Einzelpreis sollen geändert werden können).

Also sollen die Daten aus der Tabelle "verkauf" geholt, geändert und in die geänderten Daten in die Tabelle "rechnung" gespeichert werden. Die Frage ist nun, wie mach ich das am sinnvollsten?

DBGrid, StringGrid, TEdits oder wie?

Hoffe, hab mich mehr oder weniger verständlich ausdrücken können..


MfG

davar

[s-off]

Hallo,

ich würde mir einen Assistenten basteln, der aufploppt, sobald Du auf den Button 'Rechnung drucken' klickst.
Dieser Assistent beinhaltet ein DBGrid. Dieses DBGrid füllst Du mittels eines SQL-Query mit den rechnungsrelevanten Daten.

Wenn Du nun den 'Rechnung drucken'-Button drückst, siehst Du also alle Daten strukturiert in dem Assistenten und nimmst ggf. Änderungen daran vor.
Wenn Du den Assistenten schliesst, lässt Du die Rechnung drucken und übernimmst die Änderungen in die DB.

[davar]

Ich habe ein DBGrid, was mit einem Query verbunden ist. Die Daten werden auch angezeigt, aber ich kann nichts darin ändern, obwohl Readonly auf false ist. Eine Ahnung, woran das liegen könnte?

[marabu]

Hast du ZQuery.RequestLive auf True gesetzt?

Grüße vom marabu

[davar]

Zitat:

Zitat von marabu

Hast du ZQuery.RequestLive auf True gesetzt?

Grüße vom marabu

hmm. jetzt kann ich die Daten ändern, und die nächste Frage ist, wie speichere ist das? :oops:

[s-off]

Der sollte das eigentlich automatisch speichern - spätestens dann, wenn Du den Datensatz im Grid wechselst.

[davar]

Zitat:

Zitat von s-off

Der sollte das eigentlich automatisch speichern - spätestens dann, wenn Du den Datensatz im Grid wechselst.

Tut er nicht. Das heisst, erst schon, aber wenn ich das Formular schließe und erneut öffne, also die Daten erneut aufrufe, wird es wieder zurückversetzt.

[s-off]

AutoEdit vom DataSet auf True?

[davar]

Zitat:

Zitat von s-off

AutoEdit vom DataSet auf True?

Yepp. Auch das ist true.

[Hoshy]

Mhhh, vielleicht...

..."CachedUpdates" versehentlich auf "true" stehen?
...benutzt Du ein ZUpdateSQL und rufst nicht "ApplyUpdates" auf?
...hat Deine Tabelle keine Primary Key und die property "WhereMode" steht auf "wmWhereKeyOnly"?
...suchst Du die Daten im SELECT aus mehreren Tabellen zusammen?
...greifst Du mit dem SELECT auf eine non-updatable view zu?

Das fällt mir spontan dazu ein. Du könntest auch mal versuchen, die property "IndexFieldNames" mit den Namen der Felder des Primary Key zu setzen (durch Semikolon getrennt). Das bringt's dann, wenn die Query den geeigneten Index - i. d. R. den Primärschlüssel - nicht automatisch erkennt (warum auch immer).

Gruß
Andi

[Jelly]

Das riecht mir sehr danach, dass Du vergisst die Transaktion zu committen.

[davar]

Zitat:

Zitat von Hoshy

Mhhh, vielleicht...

..."CachedUpdates" versehentlich auf "true" stehen?
...benutzt Du ein ZUpdateSQL und rufst nicht "ApplyUpdates" auf?
...hat Deine Tabelle keine Primary Key und die property "WhereMode" steht auf "wmWhereKeyOnly"?
...suchst Du die Daten im SELECT aus mehreren Tabellen zusammen?
...greifst Du mit dem SELECT auf eine non-updatable view zu?

Das fällt mir spontan dazu ein. Du könntest auch mal versuchen, die property "IndexFieldNames" mit den Namen der Felder des Primary Key zu setzen (durch Semikolon getrennt). Das bringt's dann, wenn die Query den geeigneten Index - i. d. R. den Primärschlüssel - nicht automatisch erkennt (warum auch immer).

Gruß
Andi

Ich fang gleich an zu heulen..

Ich lad mal die ganzen Eigenschaften der Komponenten hoch, vielleicht erkennt jemand den Fehler..

[Hoshy]

Zitat:

Ich lad mal die ganzen Eigenschaften der Komponenten hoch

Nix außergewöhnliches zu sehen :?
Poste doch mal bitte das SQL Statement...

Übrigens, wieso heissen Deine Zeos Komponenten alle TZZirgendwas? Meine heissen TZirgendwas...Welche Version der ZEOS benutzt Du denn?

[Sharky]

Hai davar,

ich habe in dem WaWi das ich mal geschrieben habe für die "Vorgangserfassung" immer eine Grid (eigentlich VirtualStringTree) für die Positions anzeige und einfache Edits für die Dateneingabe verwendet (siehe Bild).

Ausserdem habe ich das in der DB anders eingetragen als Du. Ich habe nur eine Tabelle für die Vorgänge gehabt.

Uff... jetzt wird es etwas OT aber ich hoffe man verzeiht mir wenn ich einen allgemeinen Tip geben?

Wie ist denn der "normale" Ablauf eines Verkaufes:

1. Kunde droht mit Auftrag
2. Daraufhin werden dem Kunden Angebote erstellt
3. Aufgrund eins Angebotes bestellt der Kunde
4. Nach der Bestellung wird aus dem Angebot eine Auftragsbestätigung erstellt
5. Es wird ein (Teil)lieferschein erzeugt
6. Aus dem Lieferschein wird eine Rechnung erzeugt

Für jede Aktion muss ein Datensatz in der Vorgangstabelle erzeugt werden.
Man braucht also ersteinmal eine Tabelle in der die Vorgänge gespeichert werden.

Code:

tbl_vorgangsarten
-----------------
id                : PK
bezeichnung       : (Angebot, Auftragsbestätigung, Lieferschein, Rechnung)

tbl_projekt
-----------
id                : PK
bezeichnung       : Ein Text oder eine Vorgangsnummer
fk_adress_id      : Verknüpfung zur Adressentabelle

tbl_vorgang 
-------------
id                : PK
fk_projekt_id     : Verknüpfung zu tbl_projekt
fk_vorgangsart_id : Die Vorgangsart
datum             : Naja, das Datum halt

tbl_vorgangpos
--------------
id                : PK
fk_vorgang_id     : Verknüpfung mit den einzelnen Vorgängen
pos               : Position
fk_arktikel_id    : Verknüpfung mit den Artikeln in dem Vorgang
preis             : Preis des Artikels
menge             : Menge

Bei den Vorgangspositionen müssen natürlich noch alle anderen Felder rein.
Wenn jetzt ein neuer "Verkauf" beginnt wird als erstes ein neues Projekt erzeugt. Beim Vorgang (Angebot, AB, Rechnung) wird die Referenz zum Projekt hinterlegt. Du kannst also zu einem Projekt mehrere Angebote haben welche sich in ihren Positionen unterscheiden. Jedes dieser Angebote kann nun in eine Auftragsbestätigung gewandelt werden. Dafür wird einfach ein neuer Eintrag in der tbl_vorgang erzeugt und die Positionen werden kopiert.

Das ganze ist auf den ersten Blick zwar ein unnötiger Aufwand; aber Du wirst dich darüber freuen wenn dein Programm einmal komplexer wird. So siehst Du zum Beispiel auf einen Blick alle Angebote die zu einem Projekt erstellt wurden. Auf den Ausdrucken für den Kunden steht neben der Angebots-, AB-, Lieferschein- und Rechnungsnummer immer die Projektnummer dabei. Dadurch kann man alles in der DB finden.

Ach ja, noch etwas zu den Verkaufspreisen. Speichere diese nicht in der Tabelle der Artikel sondern wieder in einer eigenen.

Code:

tbl_artikel
-----------
id                : PK
nummer            : Artikelnummer
bezeichnung       : Artikelbezeichnung

tbl_artikel_preise
------------------
id                : PK
fk_artikel_id     : Verknüpfung zum Artikel
preis             : Artikelpreis
datum             : Datum ab wann de Preis gültig ist

So hast Du ganz nebenbei eine History eurer VKs.
Bei den Vorgangspositionen ist es eventuell noch Sinnvoll eine Spalte zu haben in der ein Flag darüber auskunft gibt ob der Preis für diese Position vom Standardpreis abweicht. Dies kannst Du aber auch über eine Abfrage der Preistabelle ermitteln.
Wichtig ist es aber auf den Ausdrucken für den Kunden zu vermerken das es sich um einen Sonderpreis handelt.

So, das ist jetzt nur einmal schnell runtergeschrieben (Sonntags, halb zehn in Deutschland *g*).
Wenn Du noch genauer darüber reden möchtest sage mir bitte bescheid. Dann löse ich dieses Posting aus dem Thread und mache dafür einen eigenen auf!

[davar]

Zitat:

Zitat von Hoshy

Zitat:

Ich lad mal die ganzen Eigenschaften der Komponenten hoch

Nix außergewöhnliches zu sehen :?
Poste doch mal bitte das SQL Statement...

Übrigens, wieso heissen Deine Zeos Komponenten alle TZZirgendwas? Meine heissen TZirgendwas...Welche Version der ZEOS benutzt Du denn?

Keine Ahnung, warum die Komponenten so heissen, ich glaub es müsste die modifizierte Version für DElphi 3 sein.

Also das SQL Statement sieht so aus:

Delphi-Quellcode:

DBs.verbinden;
DBs.query.SQL.text:= 'SELECT * FROM `kundendaten_stamm`';
DBs.query.Open;

und "verbinden" in der unit "DBs" so:

Delphi-Quellcode:

procedure TDBs.verbinden;
begin
db.Host:= 'localhost';
db.Login:= 'root';
db.Password:= '';
db.Database:= 'daten';
db.Connected:= True;
end;

MfG

davar

[Hoshy]

"kundendaten_stamm" ist die Tabelle selbst und nicht eine view, richtig?

Doof, jetzt fällt mir erstmal auch nix mehr ein, musst Du einfach mal ein bißchen rumprobieren:

- Kannst Du die TZransaction-Komponente einfach mal weglassen?
- Statt der ZQuery mal eine ZTable versuchen?
- Statt "SELECT *" mal ein "SELECT feld, feld, feld" ausführen?
- Mal ein ZUpdate an die Query hängen?
- Mal ausprobieren, ob Du überhaupt irgendwie was in die DB schreiben kannst (mit Delphi)?

Oder fängst Du irgendwo alle Exceptions ab, indem Du z. B. sowas machst, und dehalb merkst Du nicht, dass was schiefgeht:

Delphi-Quellcode:

try
  ZQuery1.Post;
except
end;

Oder änderst Du in den Datensätzen beim Editieren vielleicht den Wert des Primärschlüssels und deswegen geht was schief?