Gleiche Datensätze per SQL löschen

[m***@yahoo.de]

Hallo!

Gesetzt den Fall man hat eine Tabelle in der identische Datensätze
vorkommen (also ohne eindeutige Suchschlüssel).

Ist es möglich nur mit SQL die doppelt vorkommenden Datensätze zu
löschen, so dass von jedem mehrfach vorkommenden Datensatz nur einer
übrig bleibt?

Ich glaube nicht, oder??

Viele Grüße,
Max Weinland

[Josef Poetzl]

Hallo!

Post by m***@yahoo.de
Gesetzt den Fall man hat eine Tabelle in der identische Datensätze
vorkommen (also ohne eindeutige Suchschlüssel).

Warum erweiterst Du nicht die Tabelle mit einem Autowert-Feld, um
dieses Problem zu beheben?

mfg
Josef

[m***@yahoo.de]

Das wäre eine Lösung.
Mir geht es aber auch um die grundsätzliche Frage ob hier tatsächlich
ein Fall vorliegt der mit SQL alleine unmöglich zu lösen ist.

[Josef Poetzl]

Hallo!

***@yahoo.de schrieb:
[identische DS können nicht per SQL-Anweisung gelöscht werden]

Post by m***@yahoo.de
Mir geht es aber auch um die grundsätzliche Frage ob hier tatsächlich
ein Fall vorliegt der mit SQL alleine unmöglich zu lösen ist.

Ich vermute, dass das so ein Fall ist.

Beispiel:
Tabelle tabTest
ID | Feld1 | Feld2
1 | abcd | 1234
1 | abcd | 1234

DELETE FROM tabTest Where ID = 1
löscht sicher alle DS mit ID=1.

So etwas wie
DELETE TOP 1 FROM tabTest Where ID = 1
gibt es imo nicht.

SQL will Datensätze "massenweise" bearbeiten.
Weiters will SQL den DB-Entwickler ein wenig bestrafen, wenn er beim
Tabellenentwurf grobe Fehler gemacht hat. ;-)
(Im obigen Beispiel fehlt nämlich ein Unique-Key, damit das Problem
mit dem identischen DS gar nicht auftreten kann.)

mfg
Josef

[Henry Habermacher [MVP Access]]

Hallo Josef

Post by Josef Poetzl
(Im obigen Beispiel fehlt nämlich ein Unique-Key, damit das Problem
mit dem identischen DS gar nicht auftreten kann.)

Ich denke, dass es mit einer Nummerierung der Records gemäss FAQ machbar
wäre, werde das jetzt aber nicht ausprobieren.

Einfacher geht es nämlich so, dass man folgenden Weg geht:

Eine Tabellenerstellungsabfrage daraus machen, welche folgendermassen
aussieht:
SELECT DISTINCT DuplikatsTabelle.* INTO TempTable FROM DuplikatsTabelle;
(Duplikate verschwinden)

Dann ein
DELETE FROM DuplikatsTabelle;

Dann
INSERT INTO DuplikatsTabelle SELECT * FROM TempTable;

Schliesslich dann
DROP TempTable;

Also alles SQL Statements und schon hat man eine gesäuberte Tabelle.

Per VBA oder Makro können diese Befehle auch hintereinander in einem
Aufwisch auf eine Tabelle losgelassen werden.

Gruss
Henry

[Josef Poetzl]

Hallo!

Post by Henry Habermacher [MVP Access]
Eine Tabellenerstellungsabfrage daraus machen, welche folgendermassen
SELECT DISTINCT DuplikatsTabelle.* INTO TempTable FROM DuplikatsTabelle;
(Duplikate verschwinden)
Dann ein
DELETE FROM DuplikatsTabelle;
Dann
INSERT INTO DuplikatsTabelle SELECT * FROM TempTable;
Schliesslich dann
DROP TempTable;
Also alles SQL Statements und schon hat man eine gesäuberte Tabelle.

Auf eine Gefahr möchte ich aber hinweisen: Falls es eine
Löschweitergabe zu anderen Tabellen gibt, ist das Ergebnis der
Löschabfrage nicht besonders erfreulich.
Weiters besteht die Möglichkeit, dass einige DS nicht gelöscht werden
können, weil sich andere Datensätze darauf beziehen. (wegen
referentieller Integrität)

mfg
Josef

[Philipp Stiefel]

Post by Josef Poetzl
Auf eine Gefahr möchte ich aber hinweisen: Falls es eine
Löschweitergabe zu anderen Tabellen gibt, ist das Ergebnis der
Löschabfrage nicht besonders erfreulich.
Weiters besteht die Möglichkeit, dass einige DS nicht gelöscht
werden können, weil sich andere Datensätze darauf beziehen.
(wegen referentieller Integrität)

Dieser grundsätzlich richtige Hinweis, ist in diesem Szenario
aber nicht zutreffend. Soweit ich dem Thread entnehmen konnte,
ist das ganze Problem nur entstanden, weil es keinen eindeutigen
Schlüssel in der Tabelle gibt. Ohne eindeutigen Schlüssel gibt
es aber weder Referenzielle Integrität noch Löschweitergabe.

Gruß
Phil

[Henry Habermacher [MVP Access]]

Josef

Post by Josef Poetzl
Auf eine Gefahr möchte ich aber hinweisen: Falls es eine
Löschweitergabe zu anderen Tabellen gibt, ist das Ergebnis der
Löschabfrage nicht besonders erfreulich.

Löschweitergabe geht nur mit eindeutigem Schlüssel (PK/FK) in Beziehungen.
Ist hier also nicht weiter zu betrachten.

Post by Josef Poetzl
Weiters besteht die Möglichkeit, dass einige DS nicht gelöscht werden
können, weil sich andere Datensätze darauf beziehen. (wegen
referentieller Integrität)

RI wird's wohl aufgrund des fehlenden PKs hier auch nicht geben.

Henry

[Andreas Bruhn]

Moin moin!

Post by m***@yahoo.de
Hallo!
[identische DS können nicht per SQL-Anweisung gelöscht werden]

Post by m***@yahoo.de
Mir geht es aber auch um die grundsätzliche Frage ob hier tatsächlich
ein Fall vorliegt der mit SQL alleine unmöglich zu lösen ist.

Ich vermute, dass das so ein Fall ist.

Dafür vermute ich, dass das ein Fall ist, der möglicherweise nicht mit
SQL zu lösen ist. Wobei ich noch die Frage hätte: Was ist mit SQL
gemeint? Der SQL-Standard oder die jeweilige Implementierung des
SQL-Standard bei einer Datenbank.

IMHO hat bei jedem(?) DBMS eine Tabelle immer eine interne Spalte mit
einem eindeutigen Wert. Auch wenn das nicht durch den Standard
gefordert wird.

Wenn dann der Wert dieser internen Spalte über SQL-Befehle erreichbar
ist, dann können auch die Duplikate gelöscht werden (z.B. in einer
Stored Procedure). Wenn man mit SQL nicht an die Spalte herankommt,
dann sieht es natürlich schlecht aus.

Ciao,

Andreas

[Henry Habermacher [MVP Access]]

Hallo Andreas

Post by Andreas Bruhn
IMHO hat bei jedem(?) DBMS eine Tabelle immer eine interne Spalte mit
einem eindeutigen Wert. Auch wenn das nicht durch den Standard
gefordert wird.
Wenn dann der Wert dieser internen Spalte über SQL-Befehle erreichbar
ist, dann können auch die Duplikate gelöscht werden (z.B. in einer
Stored Procedure). Wenn man mit SQL nicht an die Spalte herankommt,
dann sieht es natürlich schlecht aus.

Das mag wohl sein, nur ist diese RowID, oder wie immer Du dieses Feld nennen
willst, in Jet nicht sichtbar/verfügbar. Sicher müsste es sowas geben, damit
Access intern die Datensätze überhaupt vernünftig ansprechen kann, aber
eben, intern - nicht extern in Jet. Dies ist in einigen anderen RDBMS auch
so. Oracle ist hier eher ein Ausnahmefall, wenn ich mich richtig erinnere.
Ein RDBMS verhindert nicht, dass ein DB Design nicht normalisiert ist. Was
der Benutzer zu sehen bekommt und womit er arbeiten kann, ist das
entscheidende. Und wenn der Benutzer mit eindeutigen Zeilennummern arbeiten
will, soll er doch bitte einen PK und z.B. eine Identity Spalte (AutoNumber)
definieren. Wenn allerdings die Daten von einem anderen System (z.B. von
einer Excel Datei) angeliefert werden, kann es eben durchaus solche
Duplikate drin haben, welche ja auch einfach beseitig werden können.

Gruss
Henry

[Andreas Bruhn]

Am Tue, 10 May 2005 19:15:28 +0700 schrieb Henry Habermacher [MVP

Post by Henry Habermacher [MVP Access]
Hallo Andreas

Post by Andreas Bruhn
IMHO hat bei jedem(?) DBMS eine Tabelle immer eine interne Spalte mit
einem eindeutigen Wert. Auch wenn das nicht durch den Standard
gefordert wird.
Wenn dann der Wert dieser internen Spalte über SQL-Befehle erreichbar
ist, dann können auch die Duplikate gelöscht werden (z.B. in einer
Stored Procedure). Wenn man mit SQL nicht an die Spalte herankommt,
dann sieht es natürlich schlecht aus.

Das mag wohl sein, nur ist diese RowID, oder wie immer Du dieses
Feld nennen willst, in Jet nicht sichtbar/verfügbar.

Wie man vielleicht am nicht zitierten Teil meines Postings sieht, war
ich so frei und habe bei der Antwort den Gruppennamen ein wenig
ignoriert und mich an einer RDBMS-übergreifenden Antwort versucht. Für
Access kannte ich die richtige Antwort nämlich nicht, sondern konnte
nur für ...

Post by Henry Habermacher [MVP Access]
Sicher müsste es sowas geben, damit Access intern die Datensätze
überhaupt vernünftig ansprechen kann, aber eben, intern - nicht
extern in Jet. Dies ist in einigen anderen RDBMS auch so. Oracle
ist hier eher ein Ausnahmefall, wenn ich mich richtig erinnere.

Interbase/Firebird sprechen, bei dem das auch geht. (Ich hatte noch
den Verdacht, dass genau diese Frage nach dem Löschen von Duplikaten
in einem meiner Interbase-Bücher gestellt und beantwortet wurde und
deswegen erstmal in den Büchern gesucht.)

Post by Henry Habermacher [MVP Access]
Ein RDBMS verhindert nicht, dass ein DB Design nicht normalisiert
ist. Was der Benutzer zu sehen bekommt und womit er arbeiten kann,
ist das entscheidende. Und wenn der Benutzer mit eindeutigen
Zeilennummern arbeiten will, soll er doch bitte einen PK und z.B.
eine Identity Spalte (AutoNumber) definieren. Wenn allerdings die
Daten von einem anderen System (z.B. von einer Excel Datei)
angeliefert werden, kann es eben durchaus solche Duplikate drin
haben, welche ja auch einfach beseitig werden können.

Ja!

Tschüss,
Andreas

[Henry Habermacher [MVP Access]]

Hallo Max

Post by m***@yahoo.de
Gesetzt den Fall man hat eine Tabelle in der identische Datensätze
vorkommen (also ohne eindeutige Suchschlüssel).
Ist es möglich nur mit SQL die doppelt vorkommenden Datensätze zu
löschen, so dass von jedem mehrfach vorkommenden Datensatz nur einer
übrig bleibt?
Ich glaube nicht, oder??

Doch, das geht. Starte mal den Duplikatssuche Assistenten. Der kann diese ja
auch auflisten, also kann man diese auch löschen. Allerdings ist das nicht
ganz so einfach, wenn der Datensatz komplett idenitisch ist, sich also nicht
um ein einziges Feld unterscheidet, aber das wird wohl kaum der Fall sein,
oder?

Gruss
Henry