SQL Delete mit 3 verknuepften Tabellen

Hi,

Post by Sven Hoffmann
Hab ein Problem mit einer SQL DELETE abfrage. Ich habe 3 Tabellen. In
meiner Haupttabelle hab ich ein Datum stehen (in den andren 2 nicht).
Ich brauche eine moeglichkeit alle Daten aus allen 3 Tabellen zu
Loeschen die aelter als z.B 2 Jahre sind. Die Tabellen sind
...

kommt darauf an, wie du die Tabellen verbunden hast. Günstigstenfalls hast
du Löschweitergabe, dann kannst du einfach den DS aus der Haupttabelle
löschen und alle anderen werden automatisch gelöscht.
Ansonsten bastle dir eine Abfrage, die die drei Tabellen JOIN't und lösche
dann. Geht das nicht, musst du erst die DS aus den Kind-Tabellen löschen
und dann halt den Hauptdatensatz.

Bis dann,
Olaf

--
My .02: www.Resources.IntuiDev.com

Sven Hoffmann

2006-01-12 13:57:04 UTC

Hallo Olaf

Löschweitergabe funktioniert leider nicht.

Bei den Kind-Tabellen steht kein Datum drin, woher weiss ich da,
welcher Datensatz aelter als z.B 2 Jahre ist?

Hab bisher noch nicht mit JOIN gearbeitet, wie muss das ungefaehr
aussehen?

Gruss Sven

Michael Zimmermann

2006-01-12 15:30:10 UTC

Hallo!

Post by Sven Hoffmann
Bei den Kind-Tabellen steht kein Datum drin, woher weiss
ich da, welcher Datensatz aelter als z.B 2 Jahre ist?
Hab bisher noch nicht mit JOIN gearbeitet, wie muss das
ungefaehr aussehen?

Ich würde grundsätzlich nicht aus einer Abfrage (d. i. einem
Resultset mit JOIN) löschen.

Du mußt für das direkte Löschen aus den Tabellen nur die
Bedingungen passend formulieren.

DELETE FROM
tblKind
WHERE
fiMutter IN (
SELECT
idMutter
FROM
tblMutter
WHERE
MutterAlter > 2
)

Dann

DELETE FROM
tblMutter
WHERE
MutterAlter > 2

Die SQL-Statements kannst Du mit CurrentDb.Execute
ausführen.

Gruß aus Mainz
Michael

unknown

2006-01-12 16:57:25 UTC

Post by Michael Zimmermann
Hallo!

Ich würde grundsätzlich nicht aus einer Abfrage (d. i. einem
Resultset mit JOIN) löschen.
Du mußt für das direkte Löschen aus den Tabellen nur die
Bedingungen passend formulieren.
DELETE FROM
tblKind
WHERE
fiMutter IN (
SELECT
idMutter
FROM
tblMutter
WHERE
MutterAlter > 2
)
Dann
DELETE FROM
tblMutter
WHERE
MutterAlter > 2
Die SQL-Statements kannst Du mit CurrentDb.Execute
ausführen.
Gruß aus Mainz
Michael

Hallo Michael, Hallo Sven,

vielleicht sollte man noch auf das Stichwort
"BeginTrans-, CommitTrans-, Rollback-Methoden"
in der OH hinweisen.

Habe nämlich ohne Transaktion schon inkonsistente Datenbestände erzeugt,
weil einer der Schritte nicht funktionierte.

Gruß Georg

Michael Zimmermann

2006-01-12 17:17:46 UTC

Hallo!

Post by unknown
vielleicht sollte man noch auf das Stichwort
"BeginTrans-, CommitTrans-, Rollback-Methoden"
in der OH hinweisen.
Habe nämlich ohne Transaktion schon inkonsistente
Datenbestände erzeugt, weil einer der Schritte nicht
funktionierte.

Mit referentieller Integrität in den Beziehungen wär's nicht
passiert.

Davon abgesehen aber guter ergänzender Hinweis.

Gruß aus Mainz
Michael

unknown

2006-01-12 17:43:02 UTC

Post by Michael Zimmermann
Hallo!

Mit referentieller Integrität in den Beziehungen wär's nicht
passiert.
Davon abgesehen aber guter ergänzender Hinweis.
Gruß aus Mainz
Michael

Hallo Michael,
ich will nicht kleinlich sein. Referentieller Integrität (rI) hilft nur
bedingt.

Nochmal für Sven:
Tbl1: Datum EFKey SupKey .......usw.
Tbl2: EFKey (Primaerschluessel) ....usw.
Tbl3: SupKey (Primaerschluessel) ......usw.

Wenn das Löschen der Daten von Tbl2 klappt und von Tbl3 nicht, dann kann ich
bei rI nicht Tbl1 löschen. Die rI ist gewahrt, aber ohne die Daten von Tbl2
ist der Datenbestand trotzdem Mist.
Dies verhindert eine Transaktion. Wenn was schiefgeht kann man vorherige
Änderungen ungeschehen machen.
Aber lieber Transaktionen bauen statt Löschweitergabe.

Gruß Georg

Josef Poetzl

2006-01-12 18:04:20 UTC

Hallo!

Post by Michael Zimmermann

Mit referentieller Integrität in den Beziehungen wär's nicht
passiert.

[...]

Post by unknown
Tbl1: Datum EFKey SupKey .......usw.
Tbl2: EFKey (Primaerschluessel) ....usw.
Tbl3: SupKey (Primaerschluessel) ......usw.
Wenn das Löschen der Daten von Tbl2 klappt und von Tbl3 nicht, dann kann ich
bei rI nicht Tbl1 löschen. Die rI ist gewahrt, aber ohne die Daten von Tbl2
ist der Datenbestand trotzdem Mist.

Mit RI hättet Du aber auch den DS aus Tbl2 nicht löschen können, wenn
ein Wert aus EFKey noch in Tbl1 verwendet wird.
=> Es kann höchstens DS in den Tabellen Tbl2 und Tbl3 geben, die
nirgendwo verwendet werden. - Aber das ist meist zulässig. ;-)

Post by unknown
Dies verhindert eine Transaktion. Wenn was schiefgeht kann man vorherige
Änderungen ungeschehen machen.
Aber lieber Transaktionen bauen statt Löschweitergabe.

Ich mag die Löschweitergabe auch nicht -
aber trotzdem sollte (besser: muss ;-) man RI verwenden.

mfg
Josef

--
EPT: (Access Error Prevention Table) http://access.joposol.com/
FAQ: (Access-FAQ von Karl Donaubauer) http://www.donkarl.com/

unknown

2006-01-12 18:42:56 UTC

"Josef Poetzl" <***@joposol.com> schrieb im Newsbeitrag news:***@joposol.com...
Hallo Josef

Post by Josef Poetzl
[...]

Post by unknown
Tbl1: Datum EFKey SupKey .......usw.
Tbl2: EFKey (Primaerschluessel) ....usw.
Tbl3: SupKey (Primaerschluessel) ......usw.

[...]
Mit RI hättet Du aber auch den DS aus Tbl2 nicht löschen können, wenn
ein Wert aus EFKey noch in Tbl1 verwendet wird.
=> Es kann höchstens DS in den Tabellen Tbl2 und Tbl3 geben, die
nirgendwo verwendet werden. - Aber das ist meist zulässig. ;-)

Habe mich durch die Bezeichnung Tbl1 irritieren lassen. Hier sind ja EFKey
und SupKey die Fremdschlüssel und nicht umgekehrt %-)

Post by Josef Poetzl
Ich mag die Löschweitergabe auch nicht -
aber trotzdem sollte (besser: muss ;-) man RI verwenden.

Volle Zustimmung.

auch mfg Georg

Michael Zimmermann

2006-01-12 19:52:25 UTC

Hallo!

Post by Michael Zimmermann

[ Transaktion ]

Mit referentieller Integrität in den Beziehungen wär's
nicht passiert.
Davon abgesehen aber guter ergänzender Hinweis.

ich will nicht kleinlich sein.

Löblicher Vorsatz. Bei Diskussionen mit mir aber nur bedingt
durchzuhalten. ;-)

Post by unknown
Referentieller Integrität (rI) hilft nur bedingt.

Sie verhindert zuverlässig, daß Mutterdatensätze gelöscht
werden, deren PS in Kindtabellen als FS verwendet wird.
Das ist ihr Job. Sie verhindert nicht, daß Kinddatensätze
keine Mutter haben können (NULL-Wert im FS).

Wenn man 1:n-Beziehungen zusätzlich zur RI sauber aufbaut,
nämlich mit Eingabepflicht im FS bzw., falls Kinder ohne
Mutter zulässig sein sollen, die Beziehung in einer eigenen
Tabelle abbildet, sind inkonsistente Daten ausgeschlossen.

Nebenbei sollte es selbstverständlich sein, in einer
Hierarchie (1:n-Kaskade) von unten nach oben zu löschen
und nicht in der Mitte anzufangen.

(Siehe auch Anmerkungen von Josef, was wann gelöscht werden
kann.)

Falls sich Dein Beispiel auf die Referenztabelle in
m:n-Beziehungen bezieht, sieht die Sache prinzipbedingt
etwas anders aus. Falls Du dort z. B. Beziehungsdaten,
die vor einem bestimmten Datum in der Referenztabelle
liegen, löschtest, verlörest Du allerdings die Information,
zwischen welchen Masterdatensätzen Du gerade die Beziehung
aufgehoben hast. Da aber die Master sowohl der einen wie
der anderen Seite ja in weiteren m:n-Datensätzen vorkommen
können, wäre es auch nicht wünschenswert, solche Master zu
löschen. Allenfalls könnte - nicht muß - eine Anforderung
bestehen, Master zu löschen, denen in der Referenztabelle
gar kein DS entspricht. Das ist aber etwas anderes, berührt
nicht die RI und läßt sich über eine Unterabfrage einfach
lösen.

Post by unknown
Aber lieber Transaktionen bauen statt Löschweitergabe.

Völlig Deiner Meinung. Die RI soll nicht die
Transaktionierung überflüssig machen, sondern die
DB vor unsinnigen Aktionen schützen. Wenn keiner Unfug
macht, um so besser.

Gruß aus Mainz
Michael

Sven Hoffmann

2006-01-13 07:00:34 UTC

Hallo zusammen,

Interessante Diskussion, wenn ich auch nicht alles versteh :-). Die RI
muss man doch ueber Tools / Relationships (englische Version)
erstellen? (Korrigiert mich bitte wenn ich Falsch lieg)
Aber wenn ich das probier bekomm ich folgende Fehlermeldung:

Microsoft Office Access can't create this relationship and enforce
referential integrity.
Data in the table "Tabelle1" violates referential integrity rules.

Zu Michaels loesungsansatz:

DELETE FROM
tblKind
WHERE
fiMutter IN (
SELECT
idMutter
FROM
tblMutter
WHERE
MutterAlter > 2
)

Dann

DELETE FROM
tblMutter
WHERE
MutterAlter > 2

Muss ich praktisch 3 seperate CurrentDb.Execute basteln die ich
nacheinander ausfuehr oder ist das in einem Zug machbar?

Vielen Dank

Gruss Sven

Sven Hoffmann

2006-01-13 07:24:34 UTC

Hallo nochmal,

Hab jetzt mal folgendes probiert:

CurrentDb.Execute "(DELETE * FROM TblEF WHERE TblDatas.EFKey IN_
(SELECT EFKey FROM TblDatas WHERE [TblDatas.DDate]<Date()-9;))"

Verursacht Laufzeitfehler '3061'
Too few parameter.Expected 1

Gruss Sven

unknown

2006-01-13 08:23:24 UTC

Hallo Sven,

Post by Sven Hoffmann
Hallo zusammen,
Interessante Diskussion, wenn ich auch nicht alles versteh :-). Die RI
muss man doch ueber Tools / Relationships (englische Version)
erstellen? (Korrigiert mich bitte wenn ich Falsch lieg)

Jow!

Post by Sven Hoffmann
Microsoft Office Access can't create this relationship and enforce
referential integrity.
Data in the table "Tabelle1" violates referential integrity rules.

Aha !RI doch nicht eingeschaltet.

Jetzt hast du Fälle in
Tbl1: Datum EFKey SupKey .......usw.
wo EFKey nicht in
Tbl2: EFKey (Primaerschluessel) ....usw.
oder SupKey nicht in
Tbl3: SupKey (Primaerschluessel) ......usw

enthalten ist.

Post by Sven Hoffmann
[...]

Verständnisfrage

Post by Sven Hoffmann

Post by Sven Hoffmann
Loeschen die aelter als z.B 2 Jahre

damit ist doch sicherlich die Tbl1 gemeint und wenn nix mehr auf die anderen
Tabellen zeigt, auch dort das überflüssige Zeug.

Post by Sven Hoffmann
Muss ich praktisch 3 seperate CurrentDb.Execute basteln die ich
nacheinander ausfuehr oder ist das in einem Zug machbar?

3 Execute

[BeginTrans] Zur Sicherheit

1. Ececute Löschen von Tbl1 alles was älter als 2 Jahre (mit
Fehlerparameter)
2. Ececute Löschen von Tbl2 auf die Kein Satz von Tbl1 zeigt (mit
Fehlerparameter)
3. Ececute Löschen von Tbl3 auf die Kein Satz von Tbl1 zeigt (mit
Fehlerparameter)

wenn Fehler [Rollback] (alles zurück und nachsehen was schief läuft)
sonst [Commit] (jetzt durch die Datenbank alles in einem Rutsch löschen)

Jetzt Klara?

Gruß Georg

Sven Hoffmann

2006-01-13 10:52:23 UTC

Hallo Georg,

Die Botschaft hör' ich wohl, allein mir fehlt das Wissen :-)

Wie muss das ganze denn ungefaehr aussehen? Hoer grad zum ersten mal
von BeginTrans und Rollback.
Loeschen von Tbl1 bekomm ich hin .Wie muss ich dann aber das loeschen
von Tbl 2+3 machen?

Kannst du mir ein Beispiel geben. Das in der Hilfe macht mich nicht
ganz gluecklich ;-(

Gruss Sven

Michael Zimmermann

2006-01-13 12:16:22 UTC

Hallo!

Post by Sven Hoffmann
Die Botschaft hör' ich wohl, allein mir fehlt das Wissen
:-)
Wie muss das ganze denn ungefaehr aussehen? Hoer grad zum
ersten mal von BeginTrans und Rollback.
Loeschen von Tbl1 bekomm ich hin .Wie muss ich dann aber
das loeschen von Tbl 2+3 machen?
Kannst du mir ein Beispiel geben. Das in der Hilfe macht
mich nicht ganz gluecklich ;-(

Dim wsd as dao.workspace
Dim dbd as dao.database
Dim tSQL as string

set wsd = workspaces(0)
set dbd = CurrentDb

wsd.BeginTrans
with dbd
tSQL= _
"DELETE FROM tbl1 ..."
.Execute tSQL
tSQL= _
"DELETE FROM tbl2 ..."
.Execute tSQL
tSQL= _
"DELETE FROM tbl2 ..."
.Execute tSQL
end with
wsd.CommitTrans

Gruß aus Mainz
Michael

unknown

2006-01-13 12:53:59 UTC

Hallo Sven,
Michael war schneller als ich ;-(

Aber...
da du nicht weißt wo die Glocken hängen, habe ich vielleicht ein Beispiel
was es noch deutlicher macht.

Ich hänge bei db.execute gewophnheitsmäßig den Parameter "dbFailOnError" an.
Hier weis ich nicht ob er nicht überflüssig ist.

Gruß Georg

Sub LeerProzedur()
Dim db As Database
Dim wrksp As Workspace

On Error GoTo Err_LeerProzedur

' Standard-Arbeitsbereich bestimmen.
Set wrksp = DBEngine.Workspaces(0)
Set db = CurrentDb

' Umschließende Transaktion starten.
wrksp.BeginTrans

BeginTrans 'Start der Transaktion
'Tbl1 löschen
db.Execute "DELETE Tbl1.Tb1Datum " & _
"FROM Tbl1 " & _
"WHERE (((Tbl1.Tb1Datum)<#1/1/2004#))", dbFailOnError

db.Execute "DELETE FROM Tbl3 " & _
"WHERE Tbl3.SupKey In (SELECT Tbl3.SupKey " & _
"FROM Tbl3 LEFT JOIN Tbl1 ON Tbl3.SupKey = Tbl1.SupKey " & _
"WHERE Tbl1.SupKey Is Null)", dbFailOnError

db.Execute "DELETE FROM Tbl2 " & _
"WHERE Tbl2.EFKey In (SELECT Tbl2.EFKey " & _
"FROM Tbl2 LEFT JOIN Tbl1 ON Tbl2.EFKey = Tbl1.EFKey " & _
"WHERE Tbl1.EFKey Is Null)", dbFailOnError

Exit_LeerProzedur:
wrksp.CommitTrans

Exit Sub

Err_LeerProzedur:
MsgBox Err.Description & Err.Number
wrksp.Rollback
Resume Exit_LeerProzedur

End Sub

Michael Zimmermann

2006-01-13 14:06:26 UTC

Hallo!

Post by unknown
Ich hänge bei db.execute gewophnheitsmäßig den Parameter
"dbFailOnError" an. Hier weis ich nicht ob er nicht
überflüssig ist.

Ohne dbFailOnError werden Fehler einfach übergangen.
Mit dbFailOnError bekommst Du im Fehlerfall einen
Laufzeitfehler, den Du abfangen und auswerten kannst.

Was sinnvoller ist, hängt von den jeweiligen Umständen ab.

Gruß aus Mainz
Michael

unknown

2006-01-13 14:40:00 UTC

Hallo Michael,
dann so wie ichs mache. In jedem Fall Fehler abfangen und dann errornumber
abfragen und ggf. übergehen. An sonsten zumindestens mal die
Fehlerbeschreibung als Msgbox anzeigen.

Gruß Georg aus Köln

Michael Zimmermann

2006-01-13 15:05:17 UTC

Hallo!

Post by Michael Zimmermann
Ohne dbFailOnError werden Fehler einfach übergangen.
Mit dbFailOnError bekommst Du im Fehlerfall einen
Laufzeitfehler, den Du abfangen und auswerten kannst.
Was sinnvoller ist, hängt von den jeweiligen Umständen
ab.

dann so wie ichs mache.

:-)

Post by unknown
In jedem Fall Fehler abfangen und dann errornumber
abfragen und ggf. übergehen. An sonsten zumindestens
mal die Fehlerbeschreibung als Msgbox anzeigen.

Das kann man so pauschal nicht sagen. Es kann sein, daß
in einer bstimmten Situation nur bestimmte Fehler möglich
sind, die keine "Fehler" im eigentlichen Sinne sind, sondern
durchaus Bestandteil Deines Kalküls. Wenn diese Situation
keine Reaktion erfordert, ist ein dbfailonerror überflüssig.

Das kannst Du daran ermessen, wie oft hier gefragt wird,
wie man bei RunSQL die Fehlermeldungen temporär abschalten
kann.

Gruß aus Mainz
Michael

Olaf Rabbachin

2006-01-13 19:43:57 UTC

Hi,

Post by unknown
Sub LeerProzedur()
Dim db As Database
Dim wrksp As Workspace
On Error GoTo Err_LeerProzedur
' Standard-Arbeitsbereich bestimmen.
Set wrksp = DBEngine.Workspaces(0)
Set db = CurrentDb
' Umschließende Transaktion starten.
wrksp.BeginTrans
BeginTrans 'Start der Transaktion

BeginTrans doppelt (wenn auch ohne wrksp) gemoppelt hält besser? :-)

Post by unknown
'Tbl1 löschen
db.Execute "DELETE Tbl1.Tb1Datum " & _
"FROM Tbl1 " & _
"WHERE (((Tbl1.Tb1Datum)<#1/1/2004#))", dbFailOnError
db.Execute "DELETE FROM Tbl3 " & _
"WHERE Tbl3.SupKey In (SELECT Tbl3.SupKey " & _
"FROM Tbl3 LEFT JOIN Tbl1 ON Tbl3.SupKey = Tbl1.SupKey " & _
"WHERE Tbl1.SupKey Is Null)", dbFailOnError
db.Execute "DELETE FROM Tbl2 " & _
"WHERE Tbl2.EFKey In (SELECT Tbl2.EFKey " & _
"FROM Tbl2 LEFT JOIN Tbl1 ON Tbl2.EFKey = Tbl1.EFKey " & _
"WHERE Tbl1.EFKey Is Null)", dbFailOnError

Das statement für Tbl1 muss natürlich an den Schluss, denn sonst kommst du
an die DS aus Tbl2 und Tbl3 nicht heran. :-)

Post by unknown
wrksp.CommitTrans

Und das müsste anders herum laufen:

wrksp.CommitTrans

Post by unknown
Exit Sub
MsgBox Err.Description & Err.Number
wrksp.Rollback
Resume Exit_LeerProzedur
End Sub

Würde ich auch anders herum machen:

wrksp.Rollback
MsgBox Err.Description & Err.Number

... um die Transaktion sofort zu beenden, ansonsten "hängt" sie genau so
lange herum, bis sich der vollkommen geplättete Benutzer nach stundenlangem
Haareraufen endlich dazu entschliesst, doch den OK-Knopf zu klicken. ;-)

Bis dann,
Olaf

--
My .02: www.Resources.IntuiDev.com

unknown

2006-01-14 09:00:51 UTC

Hallo Olaf

Post by unknown
[..]
wrksp.BeginTrans
BeginTrans 'Start der Transaktion

BeginTrans doppelt (wenn auch ohne wrksp) gemoppelt hält besser? :-)

Hatte ich übersehen. Könnte aber vielleicht zu einem Fehler führen, da es
jetzt eine geschachtelte Transaktion ist.

Post by unknown
'Tbl1 löschen
[..]>

Das statement für Tbl1 muss natürlich an den Schluss, denn sonst kommst du
an die DS aus Tbl2 und Tbl3 nicht heran. :-)

Vollkommen richtig.

Post by unknown
wrksp.CommitTrans

wrksp.CommitTrans

Auch hier richtig. Sonst mach ich ja im Fehlerfall erst ein Rollback und
dann noch ein Commit.
Werd nochmal die Original-Prozedur die ich im Kopf hatte überprüfen. Hab das
ganze aus dem Kopf an meinem "Hausfrauentag" = Überstundenabbau geschrieben.

Post by unknown
Exit Sub
MsgBox Err.Description & Err.Number
wrksp.Rollback
Resume Exit_LeerProzedur
End Sub

wrksp.Rollback
MsgBox Err.Description & Err.Number
... um die Transaktion sofort zu beenden, ansonsten "hängt" sie genau so
lange herum, bis sich der vollkommen geplättete Benutzer nach

stundenlangem

Post by Olaf Rabbachin
Haareraufen endlich dazu entschliesst, doch den OK-Knopf zu klicken. ;-)

Auch richtig, aber ...

In der Original-Prozedur steht hinter der Message-Prozedur ein Stop und es
ploppt VBA hoch. In der Anwendung wird nämlich "Management by Turnschuh"
betrieben. Man rennt zum Anwender oder läßt sich die Sache über Fernwartung
zeigen. Auch auf die Gefahr hin dass die Anwendung hängt. Hier nicht ganz so
tragisch, weil für diese Aktion nur einer mit der Applikation arbeitet.

Vielen Dank für das genaue lesen.

Olaf Rabbachin

2006-01-15 22:53:16 UTC

Hi,

Post by unknown
Werd nochmal die Original-Prozedur die ich im Kopf hatte überprüfen. Hab das
ganze aus dem Kopf an meinem "Hausfrauentag" = Überstundenabbau geschrieben.

kenne ich - passiert mir ständig. :-)

Post by Olaf Rabbachin
... um die Transaktion sofort zu beenden, ansonsten "hängt" sie genau so
lange herum, bis sich der vollkommen geplättete Benutzer nach
stundenlangem Haareraufen endlich dazu entschliesst, doch den OK-Knopf
zu klicken. ;-)

Auch richtig, aber ...
In der Original-Prozedur steht hinter der Message-Prozedur ein Stop und es
ploppt VBA hoch. In der Anwendung wird nämlich "Management by Turnschuh"
betrieben. Man rennt zum Anwender oder läßt sich die Sache über Fernwartung
zeigen. Auch auf die Gefahr hin dass die Anwendung hängt. Hier nicht ganz so
tragisch, weil für diese Aktion nur einer mit der Applikation arbeitet.

ROFL! Betriebssport einmal anders.

Bis dann,
Olaf

--
My .02: www.Resources.IntuiDev.com

unknown

2006-01-23 09:10:13 UTC

Hallo Olaf

Post by unknown
'Tbl1 löschen
[..]>

Das statement für Tbl1 muss natürlich an den Schluss, denn sonst kommst du
an die DS aus Tbl2 und Tbl3 nicht heran. :-)

Vollkommen richtig.

Widerruf! Als ich am Strand von Binz spazieren ging fiel es mir wie wie
Schuppen aus den Haaren. Tbl2 und Tbl3 verhalten sich zu Tbl1 wie
"Nachschlagetabellen". In Tbl1 sind die PK von Tbl2 und Tbl3 FK. Daher doch
erst Sätze aus Tbl1 löschen und dann die Sätze von Tbl3 löschen auf die kein
Satz von Tbl1 zeigt.

Gruß Georg

Olaf Rabbachin

2006-01-23 10:33:09 UTC

Hi,

Post by unknown
'Tbl1 löschen
[..]>

Das statement für Tbl1 muss natürlich an den Schluss, denn sonst kommst

Post by Olaf Rabbachin
an die DS aus Tbl2 und Tbl3 nicht heran. :-)

Vollkommen richtig.

Auwei, ein Urlauber auf Rügen. :-)
Es geht nur um den Grundsatz - wenn nur nach Datum (das nur in Tbl1
vorhanden ist) gelöscht werden kann, brauchst du die ID des DS in Tbl1, um
in Tbl2 und Tbl3 die DS zu löschen, die mit dem in Tbl1 verbunden sind.
Hätte Sven hingegen RI mit Löschweitergabe, bräuchtest man sich ja ganz
einfach gar nicht darum zu kümmern, denn das Löschen eines DS aus Tbl1
würde automatisch die damit verbundenen in Tbl2 und Tbl3 gleichsam
"beseitigen".
Oder muss ich auf nakten Fusses am Sandstrand wandern und habe etwas
übersehen ..?

Bis dann,
Olaf

--
My .02: www.Resources.IntuiDev.com

unknown

2006-01-23 18:14:00 UTC

Hey Olaf,

"Olaf Rabbachin" schrieb im Newsbeitrag > Es geht nur um den Grundsatz -
wenn nur nach Datum (das nur in Tbl1

Post by Olaf Rabbachin
vorhanden ist) gelöscht werden kann, brauchst du die ID des DS in Tbl1, um
in Tbl2 und Tbl3 die DS zu löschen, die mit dem in Tbl1 verbunden sind.
Hätte Sven hingegen RI mit Löschweitergabe, bräuchtest man sich ja ganz
einfach gar nicht darum zu kümmern, denn das Löschen eines DS aus Tbl1
würde automatisch die damit verbundenen in Tbl2 und Tbl3 gleichsam
"beseitigen".
Oder muss ich auf nakten Fusses am Sandstrand wandern

Vielleicht {;-o

Post by Olaf Rabbachin
und habe etwas
übersehen ..?

Im Skript werden erst alle alten Datensätze in Tbl1 gelöscht.
Und dann... in Tbl2 und Tbl3 die DS deren PK n i c h t mehr in Tbl1
vorhanden sind.
Sozusagen Löschweitergabe von Hand. Die Löschweitergabe ist mir mehr als
suspekt.

Das Wandern wird dir erlassen. Bin nach einer Woche abgehauen. Nicht wegen
Kälte oder Schnee, sondern wegen des dunklen Wetters.
Viele Grüße aus dem sonnigen und (relativ) warmen Köln.
Georg

Olaf Rabbachin

2006-01-23 23:16:03 UTC

Hi,

Post by unknown
Im Skript werden erst alle alten Datensätze in Tbl1 gelöscht.
Und dann... in Tbl2 und Tbl3 die DS deren PK n i c h t mehr in Tbl1
vorhanden sind.
Sozusagen Löschweitergabe von Hand.

ach so, klar - das ginge natürlich auch. Sprich, du löschst dann auch
gleich die DS, die evt. (unverbunden) gewünscht darin verbleiben sollen.
:-)
Ich kann mir zwar keinen Grund vorstellen, warum man derartige DS noch in
der TBL haben wollte, aber ...

Post by unknown
Die Löschweitergabe ist mir mehr als suspekt.

... warum das?

Post by unknown
Das Wandern wird dir erlassen. Bin nach einer Woche abgehauen. Nicht wegen
Kälte oder Schnee, sondern wegen des dunklen Wetters.

Aber Hiddensee war doch wohl Pflichtprogramm, oder?

Post by unknown
Viele Grüße aus dem sonnigen und (relativ) warmen Köln.

Da schau her - komme gerade aus Köln. Bist du nicht im PASS
(www.sqlpass.de)?

Bis dann,
Olaf

--
My .02: www.Resources.IntuiDev.com

unknown

2006-01-24 01:04:35 UTC

"Olaf Rabbachin" schrieb im Newsbeitrag

Post by Olaf Rabbachin
[..]
ach so, klar - das ginge natürlich auch. Sprich, du löschst dann auch
gleich die DS, die evt. (unverbunden) gewünscht darin verbleiben sollen.
:-)
Ich kann mir zwar keinen Grund vorstellen, warum man derartige DS noch in
der TBL haben wollte, aber ...

Wenn Tbl2 und Tbl3 nicht gelöscht werden sollen, dann brauch ich eh nur
Tbl1 zu löschen und kann die beiden anderen Tbl von Hand bereinigen.

Post by unknown
Die Löschweitergabe ist mir mehr als suspekt.

... warum das?

Ist mir oft zu undurchsichtig. Befürchte "chaos on your fingertip"

Post by Olaf Rabbachin
[..]

Post by unknown
Aber Hiddensee war doch wohl Pflichtprogramm, oder?

Längst bei anderen Besuchen im Sommer erledigt. Nur 7 Tage Binz mit
Spazierengehen um den See und an der See.

Post by Olaf Rabbachin
[..]
Da schau her - komme gerade aus Köln. Bist du nicht im PASS
(www.sqlpass.de)?

Ist wohl nichts für mich.
Sitze im Moment nach auf dem alten Zug Access und VBA. Habe zwar schon
Schulungen für .NET besucht und muss auch hin und wieder Daten aus oder in
SQL-Server holen, aber zum richtigen Arbeiten mit diese Sachen bin ich nicht
gekommen. Die Altlasten lassen es nicht zu.

Gruß Georg

Olaf Rabbachin

2006-01-13 10:40:40 UTC