UPDATE macht es nicht so wie ich es will

[Sir Rufo]

Ist zwar ein wenig OT aber hier mal ein paar Beispiele für die Tabellen

Zitat:

[table]Name|Number
Klaus|24
Anton|90
Peter|60[/table]

Name	Number
Klaus	24
Anton	90
Peter	60

Zitat:

[table="head"]Name|Number
Klaus|24
Anton|90
Peter|60[/table]

Name	Number
Klaus	24
Anton	90
Peter	60

Zitat:

[table="head;sort=1"]Name|Number
Klaus|24
Anton|90
Peter|60[/table]

Name	Number
Anton	90
Klaus	24
Peter	60

Zitat:

[table="head;autonum=1;autonumtitle=ID;sort=1d"]Name|Number
Klaus|24
Anton|90
Peter|60[/table]

ID	Name	Number
1	Peter	60
2	Klaus	24
3	Anton	90

Zitat:

[table="head"]Name|Number
{colsp=2}Jungens
Klaus|24
Anton|90
Peter|60
{colsp=2}Mädels
Sabine|45
Karla|34[/table]

Name	Number
Jungens
Klaus	24
Anton	90
Peter	60
Mädels
Sabine	45
Karla	34

[lu maak]

hallo furtbichler,

habs getestet,jetzt steht überall in zuglänge 680.


merci.



---------------
Toll, jetzt weiss ich wie man eine Tabelle setzt.
Und wie schauts aus mit Antworten zu meinem eigentlichen Problems?

[Perlsau]

Zitat von Sir Rufo:

Ist zwar ein wenig OT aber hier mal ein paar Beispiele für die Tabellen

Wow
Endlich mal eine gescheite Anleitung für Tabellendarstellung im Foren-Editor Wollte dich schon immer mal danach fragen. Herzlichen Dank dafür

[DeddyH]

Zum Thema: wieso ein Feld befüllen, das sich aus den vorhandenen Daten errechnen lässt? Was ist denn, wenn sich einmal smm in irgendeinem Datensatz ändern sollte? Dann muss man das Ganze noch einmal machen oder hat falsche Daten. Da fände ich ein berechnetes Feld oder eine View irgendwie sinnvoller.

[jobo]

@DeddyH:
Ein View/berechnetes Feld ist meistens vorzuziehen.
Ein redundantes Feld per explizitem Update zu befüllen würde man höchstens aus Performancegründen o.ä machen. Dann allerdings ist man gezwungen, die Datenintegrität mit geeigneten Ersatzmaßnahmen zu wahren. Also Trigger bspw.. sonst gibt es (irgendwann) böse Überraschungen

[lu maak]

Hi DeddyH, jobo,

weil es sich errechnen läßt sind sie immer aktuell, kann es und soll auch befüllt werden.
Der berechnete Wert soll sichtbar in der Tabelle erscheinen und bei Änderung sich anpassen.
Desweiteren findet der Wert für weiteren Vergleiche/Berechnungen Verwendung.



Hallo Furtbichler,
habe mit deinem vorgeschlagenen Code weiter 'rumgespielt':

Update garnitur set zuglaenge = SELECT sum(smm) FROM garnitur WHERE x.zuggarnitur = garnitur.zugname where typ="L"

Man(n) glaubst nicht, so funktioniert es und mit dem angehängten where steht der Wert nur in der Lokzeile.

Genau so wollte ich das haben!

Was ich allerdings nicht verstehe, das ohne dem definierten Alias. Setze ich x hinter from gibts wieder kuriose Werte.
Egal. Habe komplette Datenbank gelöscht und mit neuen Daten getestet. Es geht immer noch.

Vorab gibts ein Eigenschulterklopf
und Merci für alle Anderen.



Übrigens: Schöne Tabelle, werde es das nächste Mal anwenden.

[jobo]

Also ich glaubs auch nicht.
Das X fehlt in Deinem Statement als Alias Definition. Insofern kann der Zugriff also Verwendung des Alias eigentlich nicht funktionieren.
Und wenn er so wie gedacht funktionieren würde, ist es natürlich ein Unterschied, wo er definiert wird, beim Update oder beim Subselect.

Hast Du nicht einfach ein Copy/Paste Fehler hier im letzten Post?

P.S.: Eben weil er einfach berechnet werden kann, müsste er nirgendwo hart eingetragen werden, das Vorgehen ist eigentlich so Standard.

[lu maak]

Hi Jo,


der Query funktioniert so wie er da steht. Im AbsDbManager als auch in Delphi.
Ein 'as irgendwas' alleine macht noch kein Mecker, aber das er sich aufrufen läßt?
Möglicherweise sowas wie NULL oder NIL, und vergleicht mit nix, mär wasess ned?
Erinnert mich an die gute alte Z80 Zeit, ab und an kam jemand und hatte wieder
undokumentierte exotische Opcodes zusammen gewurschtelt. Bei den heutigen CPU's
gibts das nicht mehr.

Egal. Lassen wir das erstmal.

Gruß
lu maak

[DeddyH]

Zitat von lu maak:

Hi DeddyH, jobo,

weil es sich errechnen läßt sind sie immer aktuell, kann es und soll auch befüllt werden.

Den Satz habe ich nicht verstanden.

Zitat von lu maak:

Der berechnete Wert soll sichtbar in der Tabelle erscheinen und bei Änderung sich anpassen.

Also sind die von jobo angesprochenen Mechanismen angesagt (Trigger etc.). Also gut, nehmen wir mal an, es existiert ein Trigger, der bei INSERT, UPDATE und DELETE feuert (also allen Kommandos, die die Summe beeinflussen). Fügen wir mal ein paar Datensätze mit gleichem garniturnamen in die leere Tabelle ein und schauen, was dabei passiert:
1. DS wird 2 mal geändert, erst durch das INSERT und dann durch den Trigger.
2. DS wird 2 mal geändert, der 1. durch den Trigger nochmals.
3. DS wird 2 mal geändert, die vorhandenen 2 durch den Trigger auch.
Etc. pp.
Man muss daher bei größeren Änderungsoperationen zunächst den Trigger deaktivieren, wenn man bis Weihnachten noch fertig werden will. Nun bauen wir uns eine View garnitursummen:

SQL-Code:

SELECT 
  garniturname, SUM(Menge * mm) AS smm
FROM
  garnitur
GROUP BY
  garniturname

Nun kann man das zusammenjoinen:

SQL-Code:

SELECT 
  G.Typ, G.Garniturname, G.Menge, G.mm, S.smm
FROM
  garnitur G
JOIN
  garnitursummen S ON S.Garniturname= G.Garniturname
WHERE
  G.Typ = 'L'

Ist das jetzt schlechter so?