Daten aus 2 Spalten miteinander tauschen
Tobias Meyer
tausenden Tabellen, Abfragen und was hat alles dazu gehört. Ich habe keine
große SQL Erfahrung und hab mich bis jetzt immer gut durchgeschlängelt doch
nun weiß ich nicht mehr weiter. Ich stelle mein Problem mal vereinfacht dar:
Tabelle mit Autoid mit fast 2000 Einträgen und darin 2 Spalten von Typ char
mit länge 20. Die erste Spalte heißt Identnummer und die 2 Spalte heißt
internenummer. Ich habe nun die Aufgabe die 2 Spalten miteinander zu
tauschen also aus interne Nummer soll Identnummer werden. Dabei sollen die
Daten nur erhalten bleiben. Ein einfaches umbenennen scheitert da die
Spalten noch mit etlichen anderen Tabellen und Co verknüpft sind. Die
Inhalte der Spalten müssen getauscht werde da das dazugehörige Programm nur
eine Suche nach Spalte Identnummer zulasst wir aber umstellen müssen auf
Suche per Identnummer. Da gibt es doch sicherlich nen Sql Befehl um die 2 zu
tauschen.
Danke für jedliche Hilfe ihr rettet mir mein Leben.
cu
starbird
Felix Saphir
Hallo Tobias,
Tut mir leid, so einen Salat les' ich mir nicht durch. Bitte bring
Deinem Outlook bei, daß es ein Charset deklariert. Unter
<http://oe-faq.de/?StepbyStep> erfährst Du, wie das geht; wesentlich
scheint der Abschnitt kurz vor "Problemkind Zeilenumbruch" zu sein.
Felix
Dominik Echterbruch
> Tabelle mit Autoid mit fast 2000 Einträgen und darin 2 Spalten von Typ char
> mit länge 20. Die erste Spalte heißt Identnummer und die 2 Spalte heißt
> internenummer. Ich habe nun die Aufgabe die 2 Spalten miteinander zu
> tauschen also aus interne Nummer soll Identnummer werden. Dabei sollen die
> Daten nur erhalten bleiben.
Das ist grundsätzlich eine ziemlich dumme Idee, wenn man (wie du
schreibst) noch tausende andere Tabellen und Programme außen rum hat,
die möglicherweise auf diese Daten referenzieren. Dann hast du zwar
vielleicht die Spalten getauscht und durchsuchst brav die interne
Nummer, aber dafür findest du bei deiner Suche rein gar nichts mehr,
weil die Referenzen flöten gegangen sind.
In deinem eigenen Interesse: Ändere die Abfrage, die die Suche
durchführt und lass die Daten in Ruhe! Du kommst sonst in Teufels Küche.
Grüße,
Dominik
--
Wo kämen wir denn da hin, wenn jeder nur fragte "Wo kämen wir denn
da hin?", aber niemand ginge, um zu sehen, wohin wir kämen, wenn wir
gingen?
(Autor unbekannt)
Tobias Meyer
das Problem ist es handelt sich hier um eine Bürosoftware wo der Quellcode nicht offen liegt. Sie basiert nur auf Firebird 2.0.
Daduch konnte ich mich mit den standardisierten Daten einloggen um überhaupt auf die db zugreifen zu können.
Ich hab also keinen Zugriff auf das eigentliche Programm um dort den Quellcode zu wechseln und damit die Abfräge zu änden. Oder muß
die Abfrage per Sql erfolgen dann wäre das was änderbar ist denn da kann ich eingreifen. Falls das nicht der Fall ist dann bleibt
mir wohl nur eins übrig den kompletten Datenbestand wohl in ein dump zu bringen. Die Tabellen zu leeren und das veränderte Dump
einspielen. Würde diese Variante klappen?
Nen schönen Tag noch
Tobias Meyer
"Dominik Echterbruch" <new...@crosslight.de> schrieb im Newsbeitrag news:121455742...@proxy00.news.clara.net...
Jens Kieselbach
> Tabelle mit Autoid mit fast 2000 Einträgen und darin 2 Spalten von Typ char
> mit länge 20. Die erste Spalte heißt Identnummer und die 2 Spalte heißt
> internenummer. Ich habe nun die Aufgabe die 2 Spalten miteinander zu
> tauschen also aus interne Nummer soll Identnummer werden. Dabei sollen die
> Daten nur erhalten bleiben. Ein einfaches umbenennen scheitert da die
Hallo Tobias,
sind die 2 erwähnten Spalten Bestandteil von irgendwelchen Constraints
(primary key, foreign key, unique)? Falls ja, dann solltest du, wie
Dominik schon geschrieben hat, die Finger davon lassen.
Ansonsten könntest du die Daten relativ einfach über eine temporäre
Spalte kopieren. Klar sollte sein, dass du vorher ein Backup von der
Datenbank machst und die Sache erstmal auf einem wieder eingespielten
Backup testest. Das ist bei Firebird ja mit gbak ziemlich einfach zu machen.
Beispiel (nicht getestet):
alter table foo add temp char(20);
update table foo set temp = spalte1;
update table foo set spalte1 = spalte2;
update table foo set spalte2 = temp;
alter table foo drop temp;
Ach ja, ich garantiere natürlich für nichts.
Gruß
Jens
Tobias Meyer
Im Moment so auf die schnelle kann ich das nicht sagen ob die bestanteile von Constraints sind das werde ich nacher mal mit einer
demoversion der db hier auf meinen heimrechner testen. Wenns dort geht dann am Mo in der Firma. Nen Backup ist selbstverständlich,
bin ja nicht blöd. Das wird bei uns täglich gemacht und vor jeder änderung sowieso ein.
Danke für den Tipp
Werde hier evtl Erfolg und Nichterfolg posten
Nen schönen Tag
Tobias
"Jens Kieselbach" <wrax...@abwesend.de> schrieb im Newsbeitrag news:6ckfmlF...@mid.individual.net...
Michael Ziegler
Zunächst mal: Bitte http://learn.to/quote .
Zum Thema:
Tobias Meyer wrote:
> das Problem ist es handelt sich hier um eine Bürosoftware wo der
> Quellcode nicht offen liegt.
Muss deine Software die Tabelle irgendwann mal bearbeiten? Wenn nicht
könntest du die Originaltabelle umbenennen und dann eine View mit dem
alten Namen definieren, die deine Vertauschung durch geschicktes SELECT
vornimmt, wobei die eigentlichen Daten aber nicht geändert werden. Das
geht natürlich nur wenn entweder kein Programm diese Tabelle updaten
muss - halte ich mal für ausgeschlossen - oder du allen Programmen die
Namensänderung beibringen kannst. Ob das möglich ist kannst nur du
beurteilen.
Michael
Dominik Echterbruch
>
>> das Problem ist es handelt sich hier um eine Bürosoftware wo der
>> Quellcode nicht offen liegt.
>
> Muss deine Software die Tabelle irgendwann mal bearbeiten? Wenn nicht
> könntest du die Originaltabelle umbenennen und dann eine View mit dem
> alten Namen definieren, die deine Vertauschung durch geschicktes SELECT
> vornimmt, wobei die eigentlichen Daten aber nicht geändert werden.
Das Problem bleibt aber das selbe: Er ändert die Daten, die für die
Referenzierung der Datensätze in anderen Tabellen verwendet werden.
Dominik Echterbruch
>
> das Problem ist es handelt sich hier um eine Bürosoftware wo der
> Quellcode nicht offen liegt.
Dann beauftrage den Hersteller, dir eine Lösung zu liefern. Im
Allgemeinen sind Closed-Source Anwendungen ja nicht kostenfrei. Ergo muß
man damit leben, auch Kosten für Änderungen zu haben. Und eins sollte
dir klar sein: Allein deine Sucherei und Testerei ist wahrscheinlich
schon teurer, als ein Patch durch den Hersteller. Von den unabsehbaren
Spätfolgen mal gar nicht zu sprechen.
Tobias Meyer
im Moment gibt es wichtiger Probleme in der Firma und Privat und ich muß das evtl. DB Problem an die Seite schieben. Ich werde die
hier geposteten Beiträge berücksichtigen und werde sobald ich neues weiß mich wieder hier melden. Danke für all eure Post und ich
denke spätestens am Wochenende darf ich euch wieder behelligen.
Nen schönen Tag noch
Tobias
"Tobias Meyer" <TobiasMey...@web.de> schrieb im Newsbeitrag news:g40glf$997$1...@online.de...
Dieter Noeth
> alter table foo add temp char(20);
> update table foo set temp = spalte1;
> update table foo set spalte1 = spalte2;
> update table foo set spalte2 = temp;
> alter table foo drop temp;
Wieso so umständlich?
SQL ist doch keine Programmiersprache :-)
update table foo set spalte2 = spalte1,spalte1 = spalte2;
Dieter
Christian Kirsch
Und das hast Du ausprobiert?
Hier jedenfalls gibt es nicht ganz das, was man vielleicht haben möchte:
mysql> create table foo (col1 char(1), col2 char(1));
Query OK, 0 rows affected (0.00 sec)
mysql> insert into foo values ('a','b');
Query OK, 1 row affected (0.00 sec)
mysql> update foo set col1=col2, col2=col1;
Query OK, 1 row affected (0.00 sec)
Rows matched: 1 Changed: 1 Warnings: 0
mysql> select * from foo;
+------+------+
| col1 | col2 |
+------+------+
| b | b |
+------+------+
1 row in set (0.00 sec)
Wie gesagt: nicht ganz. Wenn Du erreichen wolltest, dass in Spalte1 und
Spalte2 dasselbe steht - dann hast Du das natürlich geschafft.
Harald Fuchs
Christian Kirsch <c...@bru6.de> writes:
Interessant - dasselbe SQL gibt bei PostgreSQL folgendes aus:
col1 | col2
------+------
b | a
(1 row)
Weiß jemand, was der Standard dazu sagt?
Dieter Noeth
>> update table foo set spalte2 = spalte1,spalte1 = spalte2;
>>
>
> Und das hast Du ausprobiert?
Muss man etwas ausprobieren, was zu den Grundlagen eines RDBMS gehört?
Das wäre ungefähr so, wie zu überürüfen ob 1 + 1 auch wirklich 2 ergibt.
> mysql> insert into foo values ('a','b');
> Query OK, 1 row affected (0.00 sec)
>
> mysql> update foo set col1=col2, col2=col1;
> Query OK, 1 row affected (0.00 sec)
> Rows matched: 1 Changed: 1 Warnings: 0
>
> mysql> select * from foo;
> +------+------+
> | col1 | col2 |
> +------+------+
> | b | b |
> +------+------+
> 1 row in set (0.00 sec)
>
>
> Wie gesagt: nicht ganz. Wenn Du erreichen wolltest, dass in Spalte1 und
> Spalte2 dasselbe steht - dann hast Du das natürlich geschafft.
Aua.
Das ist nur wieder ein Zeichen dafür, dass mysql noch weit davon
entfernt ist, ein "richtiges" DBMS zu sein.
Dieter
Dieter Noeth
>> Wie gesagt: nicht ganz. Wenn Du erreichen wolltest, dass in Spalte1 und
>> Spalte2 dasselbe steht - dann hast Du das natürlich geschafft.
>
> Interessant - dasselbe SQL gibt bei PostgreSQL folgendes aus:
>
> col1 | col2
> ------+------
> b | a
> (1 row)
>
> Weiß jemand, was der Standard dazu sagt?
Na klar, das gleiche, was PostgreSQL und jedes andere RDBMS
zurückliefert. Zwing mich jetzt bitte nicht, den genauen Wortlaut
rauszusuchen, den SQL Standard zu lesen ist eine Quälerei...
Und wie du siehst, haben sich die mysql-Entwickler das vermutlich auch
nicht angetan ;-)
Dieter
Christian Kirsch
> Christian Kirsch wrote:
>
>>> update table foo set spalte2 = spalte1,spalte1 = spalte2;
>>>
>> Und das hast Du ausprobiert?
>
> Muss man etwas ausprobieren, was zu den Grundlagen eines RDBMS gehört?
gehören sollte... Sorry, mir war das tatsächlich neu, deshalb habe ich
es ausprobiert. Hätte ich vielleicht besser nicht getan :-(
> Das wäre ungefähr so, wie zu überürüfen ob 1 + 1 auch wirklich 2 ergibt.
>
Das ist keineswegs eine unumstößliche Wahrheit. Innerhalb der
natürlichen Zahlen und ihrer Obermengen ... ja. Aber in Z1... eher
nicht, da ist 1+1 äquivalent zu 0 ;-)