UPDATE und LIMIT

Hi all,

kann es sein, dass bei PG es nicht möglich ist ein LIMIT oder OFFSET bei einem UPDATE zu setzen?

Folgendes bringt mir nämlich ein Fehler:

UPDATE ware SET id='$n_artnr',artikelnummern='$s_artnr' WHERE id='$ber' LIMIT 1

Gruß

hi,

laut doku (http://www.postgresql.org/docs/8.1/interactive/sql-update.html) geht das nicht. aber du kannst ja über den where teil genau einschränken welche ds geändert werden sollen…

cu tb.

Ich kopiere dort eine Zeile.
Damit die ID nicht wiederholt wird, ändere ich nachträglich jeweils 1 Zeile davon.
Aber wenn das so nicht geht muss ich wohl umdenken.

Ist es möglich bei einem INSERT … SELECT bestimmten Spalten eine Vorgabe zu geben, die als ausnahme von mir die Daten annimmt, statt vom SELECT?

naja selbst dann könntest du doch diese eine einzelne zeile genau indentifizieren. mir wäre das so wie du es machst viel zu gefährlich. woher weißt du welchen datensatz er nimmt…

das sollte auch gehen. musst halt einen wert hier in den insert einfügen (z.b. ein nextval) und den select entsprechend anpassen…

cu tb.

also wenn ich doch eine zeile kopiere habe ich 2 zeilen mit der selben ID.
da ist es ja egal, welche er davon nimmt, da es ja das selbe ist, hauptsache der nimmt eine davon, anstatt 2 :wink:

Ich verstehe nicht wie das aussehen soll.
Als Info: Ich möchte dabei keine Spalte angeben, die nicht von mir beeinflusst werden soll, weil ich das bei jeder Änderung der DB anpassen müsste[/code]

Kannst du mir bitte ein Beispiel geben wie du es meinst?

Naja…

ich habs als info improvisorisch mit PHP gelöst statt mit PG.

Wenn jemand aber etwas derartiges wüsste, wie das mit PG zu lösen wäre, wäre ich dankbar wenn es jemand schreiben würde.

Gruß

Hallo,

wie schaffst Du es mehrere Zeilen mit der gleichen ID zu erstellen ?



mfg

Fristo

indem er die zeile einfach id nennt und keinen primary key bzw unique key drauf legt :wink:

cu tb.

Hallo Xandrian,

die Frage war ja eigentlich an “Sy-” gestellt, um Ihn mal heraus zu fordern. Dann kann man nur hoffen, dass er Deine Antort gelesen hat. Gemeldet hat er sich ja noch nicht. Vielleicht denkt er gerade darüber nach.

Mich wundert es immer wieder, welchen Aufwand Entwickler einer Datenbank betreiben, damit sie inkonsistent wird. Und das Prinzip, erst denken, dann arbeiten, scheint bei den meisten eher in der umgekehrten Reihenfolge zu erfolgen.



mfg

fristo

fristo: g

Letztendlich könnte man sein Problem auch lösen, indem man in der WHERE Bedingung einen Subselect mit IN angibt und im Subselect dann exakt die Werte selected und limitiert, die man haben möchte.

Hallo ads,

hast Du die letzte Antwort vom Xandrian gelesen? Das trifft genau den Kern der Ursache. Man muss es halt auch verstehen.



mfg

fristo

fristo: Ja, hatte ich gelesen.

Die Diskussion im Thread wanderte immer mehr zum Design der Tabelle des OP ab (wobei ein vernünftiges Design in Ordnung ist).
Meine Antwort war eine mögliche Lösung für seine ursprüngliche Frage.

Hallo ads,

Weil es ein Design-Fehler ist. Weder Xandrian noch ich sind Föderer von inkonsistenten Datenbanken.



Nein, da ging es um LIMIT und OFFSET im UPDATE-Befehl. Ob er sich vorher die Doku angeschaut hat?

Lösung? Ja. - Gute? Nein. - Warum nicht? Führt wegen der Inkonsistenz der Datenbank zu weiteren Problemen. Ist damit jemand geholfen? Oder doch besser, das Design korregieren?




mfg

fristo

Ich auch nicht.
Wir können uns jetzt natürlich auch noch darum streiten, ob eine weitere Lösung hilfreich ist oder nicht.

Andreas