Löschweitergabe per VBA

[Thomas Winkler]

Hi,

ich will per VBA die Löschweitergabe bestimmter Verknüpfungen setzen.
Mein Ansatz ist vereinfacht dieser:

Dim rel As DAO.Relation

For Each rel In CurrentDb.Relations
rel.Attributes = (rel.Attributes Or dbRelationDeleteCascade)
Next rel

Nur leider tritt bei der Zuweisung der Laufzeitfehler 3219 ("Unzulässige
Oepration") auf.

Wie kann ich nun die Löschweitergabe einer Verknüpfung setzen?

THX

Thomas

--
"Access? Damit arbeite ich nicht. Das ist doch nur ein abgespecktes Excel."

[André Minhorst]

Hi Thomas,

Post by Thomas Winkler
ich will per VBA die Löschweitergabe bestimmter Verknüpfungen setzen.
Dim rel As DAO.Relation
For Each rel In CurrentDb.Relations
rel.Attributes = (rel.Attributes Or dbRelationDeleteCascade)
Next rel
Nur leider tritt bei der Zuweisung der Laufzeitfehler 3219 ("Unzulässige
Oepration") auf.
Wie kann ich nun die Löschweitergabe einer Verknüpfung setzen?

wenn es auch per ADO und DDL sein darf:

http://www.access-entwicklerbuch.de/2007/index.php?page=buch&bookpage=Kap_08/05_02.html

Siehe dort unter Funktion 'CREATETABLEMitANSI92'.

Ciao
André

[Thomas Winkler]

Hi,

Post by André Minhorst
http://www.access-entwicklerbuch.de/2007/index.php?page=buch&bookpage=Kap_08/05_02.html
Siehe dort unter Funktion 'CREATETABLEMitANSI92'.

Wie Du schon in der Diskussion mit Karl mitbekommen hast, löst Dein
Vorschlag mein Problem nicht.

Allerdings habe ich inzwischen weiter experimentiert und habe eine
funktionierende Lösung gefunden. Allerdings bereitet sie mir ein wenig
Bauchschmerzen, wegen eineiger Probleme (sind das überhaupt welche), die
"On Error Resume Next" erfordern. Was meint ihr dazu?

(BTW: Hab die Sub extra so benannt, dass Karl sein "ALTER CONSTRAINT"
bekommt :-)

Public Sub alterConstraint(ByRef strRelationName As String, ByRef
lngAttributes As Long)
Dim relOld As DAO.Relation
Dim relNew As DAO.Relation
Dim fldOld As DAO.Field
Dim fldNew As DAO.Field
Dim prp As DAO.Property

'Das ist nötig, da sich nicht alle Properties übertragen lassen
On Error Resume Next

For Each relOld In CurrentDb.Relations
If LCase(relOld.Name) = LCase(strRelationName) Then
Set relNew = CurrentDb.CreateRelation

'Properies der Relation übertragen
For Each prp In relOld.Properties
If LCase(prp.Name = "attributes") Then
relNew.Properties(prp.Name) = lngAttributes
Else
relNew.Properties(prp.Name) = relOld.Properties(prp.Name)
End If
Next prp

'Felder übertragen
For Each fldOld In relOld.Fields
Set fldNew = relNew.CreateField(fldOld.Name)

'Properties der Felder übertragen
For Each prp In fldOld.Properties
fldNew.Properties(prp.Name) = fldOld.Properties(prp.Name)
Next prp

relNew.Fields.Append fldNew
Next fldOld

CurrentDb.Relations.Delete relOld.Name
CurrentDb.Relations.Append relNew
End If
Next relOld
End Sub


Ist das praxistauglich? Mit welchen Nebeneffekten ist ggf. zu rechnen?

THX

Thomas

--
"Access? Damit arbeite ich nicht. Das ist doch nur ein abgespecktes Excel."

[André Minhorst]

Hallo Thomas,

Post by Thomas Winkler

Post by André Minhorst
http://www.access-entwicklerbuch.de/2007/index.php?page=buch&bookpage=Kap_08/05_02.html
Siehe dort unter Funktion 'CREATETABLEMitANSI92'.

Wie Du schon in der Diskussion mit Karl mitbekommen hast, löst Dein
Vorschlag mein Problem nicht.

reite nur darauf herum ...

Post by Thomas Winkler
Allerdings habe ich inzwischen weiter experimentiert und habe eine
funktionierende Lösung gefunden. Allerdings bereitet sie mir ein wenig
Bauchschmerzen, wegen eineiger Probleme (sind das überhaupt welche), die
"On Error Resume Next" erfordern. Was meint ihr dazu?
(BTW: Hab die Sub extra so benannt, dass Karl sein "ALTER CONSTRAINT"
bekommt :-)
Public Sub alterConstraint(ByRef strRelationName As String, ByRef
lngAttributes As Long)
Dim relOld As DAO.Relation
Dim relNew As DAO.Relation
Dim fldOld As DAO.Field
Dim fldNew As DAO.Field
Dim prp As DAO.Property
'Das ist nötig, da sich nicht alle Properties übertragen lassen
On Error Resume Next
For Each relOld In CurrentDb.Relations
If LCase(relOld.Name) = LCase(strRelationName) Then
Set relNew = CurrentDb.CreateRelation
'Properies der Relation übertragen
For Each prp In relOld.Properties
If LCase(prp.Name = "attributes") Then
relNew.Properties(prp.Name) = lngAttributes
Else
relNew.Properties(prp.Name) = relOld.Properties(prp.Name)
End If
Next prp
'Felder übertragen
For Each fldOld In relOld.Fields
Set fldNew = relNew.CreateField(fldOld.Name)
'Properties der Felder übertragen
For Each prp In fldOld.Properties
fldNew.Properties(prp.Name) = fldOld.Properties(prp.Name)
Next prp
relNew.Fields.Append fldNew
Next fldOld
CurrentDb.Relations.Delete relOld.Name
CurrentDb.Relations.Append relNew
End If
Next relOld
End Sub
Ist das praxistauglich? Mit welchen Nebeneffekten ist ggf. zu rechnen?

Das On Error Resume next wäre mir hier ein wenig zu global. Ich würde es
nur vor der Zeile positionieren, die beim Übertragen der Properties
Probleme macht und die Fehlerbehandlung direkt dahinter wieder mit On Error
Goto 0 anschalten.

Und eigentlich wolltest Du ja auch nur die Löschweitergabe hinzufügen. Du
darfst dann also nicht pauschal einen neuen Wert über lngAttributes setzen,
weil Du damit ja gegebenenfalls andere Attribute änderst. Stattdessen musst
Du prüfen, ob schon eine Löschweitergabe vorhanden ist und diese
gegebenenfalls hinzufügen (ungetestet):

...
If LCase(prp.Name = "attributes") Then
If not relOld.Properties(prp.Name) _
OR dbDeleteCascade = dbDeleteCascade then
relNew.Properties(prp.Name) = lngAttributes + dbDeleteCascade
else
relNew.Properties(prp.Name) = lngAttributes
end if
Else

...

Noch besser wäre, Du prüfst vor dem Anlegen der neuen Relation, ob die
Löschweitergabe schon aktiviert ist:

If relOld.Properties("Attributes").Value Or dbDeleteCascade =
dbDeleteCascade then ...

Falls ja, kannst Du direkt zum nächsten Relation-Objekt wechseln.

Generell würde es mir allerdings Bauchschmerzen bereiten, pauschal die
Löschweitergabe aller Relationen zu aktivieren.

Ciao
André

[André Minhorst]

Post by Thomas Winkler
If LCase(prp.Name = "attributes") Then
If not relOld.Properties(prp.Name) _
OR dbDeleteCascade = dbDeleteCascade then
relNew.Properties(prp.Name) = lngAttributes + dbDeleteCascade

wird zu:

relNew.Properties(prp.Name) = relOld.Properties(prp.name) + dbDeleteCascade

Post by Thomas Winkler
else
relNew.Properties(prp.Name) = lngAttributes

wird zu:

relNew.Properties(prp.Name) = relOld.Properties(prp.name)

Post by Thomas Winkler
end if
Else

Ciao
André

[Thomas Winkler]

Hi André,

danke für Deine Antworten. Das soll auch nicht der endgültige Stand
sein. Die von Dir genannten Punkte waren mir schon klar. Ich wollte nur
wissen, ob die prinzipielle Vorgehensweise so i.O ist und ich dort
weiter machen kann.

1.

Woran liegt es eigentlich, dass man nicht alle Properties übertragen
kann? Wenn man mal relOld und relNew bzw. fldOld und fldNew im
Überwachungsfenster verfolgt, sieht man im expandierten Baum gut welche
Properties das sind.

2.

Welche Bedeutung haben denn die nicht übertragbaren bzw. was handelt man
sich mit der unvollständigen Übertragung ein?

Thomas

[André Minhorst]

Hi Thomas,

Post by Thomas Winkler
1.
Woran liegt es eigentlich, dass man nicht alle Properties übertragen
kann? Wenn man mal relOld und relNew bzw. fldOld und fldNew im
Überwachungsfenster verfolgt, sieht man im expandierten Baum gut welche
Properties das sind.

vielleicht lassen sich die Properties ja übertragen, aber eben nicht durch
einfaches zuweisen? Ohne das nun geprüft zu haben: Möglicherweise enthalten
diese ja Objekte, die man anders übergeben muss?

Post by Thomas Winkler
2.
Welche Bedeutung haben denn die nicht übertragbaren bzw. was handelt man
sich mit der unvollständigen Übertragung ein?

Wie heißen denn die nicht übertragbaren Elemente und welchen Typ haben
diese?

Ciao
André

[Thomas Winkler]

Hi,

Post by André Minhorst
Wie heißen denn die nicht übertragbaren Elemente und welchen Typ haben
diese?

Von den Properties der Relation betrifft dies nur:
- PartialReplica: 3420 - Das Objekt ist ungültig, oder es ist nicht
mehr festgelegt.

Von den Properties der Felder der Relation betrifft dies:
- Value: 3219 - Unzulässige Operation.
- Attributes: 3219 - Unzulässige Operation.
- CollatingOrder: 3219 - Unzulässige Operation.
- Type: 3219 - Unzulässige Operation.
- OrdinalPosition: 3219 - Unzulässige Operation.
- Size: 3219 - Unzulässige Operation.
- SourceField: 3219 - Unzulässige Operation.
- SourceTable: 3219 - Unzulässige Operation.
- ValidateOnSet: 3219 - Unzulässige Operation.
- DataUpdatable: 3219 - Unzulässige Operation.
- DefaultValue: 3219 - Unzulässige Operation.
- ValidationRule: 3219 - Unzulässige Operation.
- ValidationText: 3219 - Unzulässige Operation.
- Required: 3219 - Unzulässige Operation.
- AllowZeroLength: 3219 - Unzulässige Operation.
- FieldSize: 3267 - Die Eigenschaft kann nur festgelegt werden, wenn
das Feld Teil einer Fields-Auflistung des Recordset-Objekts ist.
- OriginalValue: 3251 - Operation wird für diesen Objekttyp nicht
unterstützt.
- VisibleValue: 3251 - Operation wird für diesen Objekttyp nicht
unterstützt.

Thomas

--
"Access? Damit arbeite ich nicht. Das ist doch nur ein abgespecktes Excel."

[Thomas Winkler]

Hi,
- PartialReplica (1): 3420 - Das Objekt ist ungültig, oder es ist
nicht mehr festgelegt.
- Value (0): 3219 - Unzulässige Operation.
- Attributes (4): 3219 - Unzulässige Operation.
- CollatingOrder (3): 3219 - Unzulässige Operation.
- Type (3): 3219 - Unzulässige Operation.
- OrdinalPosition (3): 3219 - Unzulässige Operation.
- Size (4): 3219 - Unzulässige Operation.
- SourceField (12): 3219 - Unzulässige Operation.
- SourceTable (12): 3219 - Unzulässige Operation.
- ValidateOnSet (1): 3219 - Unzulässige Operation.
- DataUpdatable (1): 3219 - Unzulässige Operation.
- DefaultValue (12): 3219 - Unzulässige Operation.
- ValidationRule (12): 3219 - Unzulässige Operation.
- ValidationText (12): 3219 - Unzulässige Operation.
- Required (1): 3219 - Unzulässige Operation.
- AllowZeroLength (1): 3219 - Unzulässige Operation.
- FieldSize (4): 3267 - Die Eigenschaft kann nur festgelegt werden,
wenn das Feld Teil einer Fields-Auflistung des Recordset-Objekts ist.
- OriginalValue (0): 3251 - Operation wird für diesen Objekttyp nicht
unterstützt.
- VisibleValue (0): 3251 - Operation wird für diesen Objekttyp nicht
unterstützt.

Nochmal die Datentyp-IDs in Klartext:
0...undefiniert
1...Boolean
3...Integer
4...Long
12...Memo

Thomas

--
"Access? Damit arbeite ich nicht. Das ist doch nur ein abgespecktes Excel."

[Josef Poetzl]

Hallo!

Post by Thomas Winkler

Post by André Minhorst
Wie heißen denn die nicht übertragbaren Elemente und welchen Typ haben
diese?

- PartialReplica: 3420 - Das Objekt ist ungültig, oder es ist nicht
mehr festgelegt.

[...]
Das liegt imo daran, dass die DAO.Field-Schnittstelle auch für
Indizes, TableDef usw. verwendet wird. Daher gibt es darin
Eigenschaften, die nicht überall verwendet werden.

Warum willst du eigentlich alle Properties übertragen?

Ich lese z. B. in meiner DBMS-Test-Anwendung nur einige Eigenschaften
aus und erstelle damit eine DDL-Anweisung.
Dabei komme ich mit den Eigenschaften Name, Table, ForeignTable und
Attributes (für dbRelationUpdateCascade u. dbRelationDeleteCascade)
von DAO.Relation und den betroffenen Feldnamen aus.
Gibt es sonst noch etwas, das übernommen werden müsste?


mfg
Josef

[Thomas Winkler]

Hi,

Post by Josef Poetzl
Das liegt imo daran, dass die DAO.Field-Schnittstelle auch für
Indizes, TableDef usw. verwendet wird. Daher gibt es darin
Eigenschaften, die nicht überall verwendet werden.

OK. Das wäre eine Erklärung.

Post by Josef Poetzl
Warum willst du eigentlich alle Properties übertragen?

Von *wollen* kann keine Rede sein. Ich *will* *nur*
dbRelationDeleteCascade setzen oder löschen - nicht mehr. Da das nicht
geht, muss ich halt eine "Kopie" der Relation anlegen und dort die
gewünschten Attribute setzen. Diese "Kopie" sollte halt bestmöglich
sein, weshalb *alle* direkten Properties und alle Properties der Felder
durchlaufen werden.

Natürlich würde es auch reichen nur die tatsächlich für die .Fields
einer DAO.Relation benötigten Properties zu kopieren. Nur kann ich nicht
mit absoluter Sicherheit sagen, welche das sind.

Post by Josef Poetzl
Ich lese z. B. in meiner DBMS-Test-Anwendung nur einige Eigenschaften
aus und erstelle damit eine DDL-Anweisung.
Dabei komme ich mit den Eigenschaften Name, Table, ForeignTable und
Attributes (für dbRelationUpdateCascade u. dbRelationDeleteCascade)
von DAO.Relation und den betroffenen Feldnamen aus.
Gibt es sonst noch etwas, das übernommen werden müsste?

Nach außen IMHO nicht. Nur weis ich auch nicht was Access/Jet sonst noch
an internen Informationen in der Relation ablegt. Das sollte dann
natürlich erhalten bleiben - genau so, wie das halt beim "normalen"
hinzufügen von dbRelationDeleteCascade per Mausklick auch der Fall wäre.

Am besten gefallen würde mir ein UPDATE auf MSysRelationships.grbit.
BTW: Kann man der Tabelle vllt. irgendwie das Schreibgeschützt-Flag
manipulieren - von mir aus auch per Hex-Editor?

Thomas

--
"Access? Damit arbeite ich nicht. Das ist doch nur ein abgespecktes Excel."

[Josef Poetzl]

Hallo!

Post by Thomas Winkler

Post by Josef Poetzl
Warum willst du eigentlich alle Properties übertragen?

Von *wollen* kann keine Rede sein. Ich *will* *nur*
dbRelationDeleteCascade setzen oder löschen - nicht mehr. Da das nicht
geht, muss ich halt eine "Kopie" der Relation anlegen und dort die
gewünschten Attribute setzen. Diese "Kopie" sollte halt bestmöglich
sein, weshalb *alle* direkten Properties und alle Properties der Felder
durchlaufen werden.
Natürlich würde es auch reichen nur die tatsächlich für die .Fields
einer DAO.Relation benötigten Properties zu kopieren. Nur kann ich nicht
mit absoluter Sicherheit sagen, welche das sind.

Ich betrachte nur jene als notwendig, die ich für die Ausführung per
DDL benötige. ;-)

Die "Darstellungseigenschaft" für den Pfeil der Verbindungslinie
(Standard für Verknüpfungstyp im Abfrageentwurf) wird dann zwar nicht
gesetzt, das ist für mich aber eine unnötige Einstellung, die nur das
"Verstehen" von Beziehungen verhindert. ;-)
Ok, für die automatisierte join-Verbindung in Abfragen kann das
möglicherweise nützlich werden. Dann müsste man das extra noch aus den
Attributes auslesen und einstellen.

Post by Thomas Winkler
BTW: Kann man der Tabelle vllt. irgendwie das Schreibgeschützt-Flag
manipulieren - von mir aus auch per Hex-Editor?

Was meinst du mit "Schreibgeschützt-Flag"?


mfg
Josef

[Thomas Winkler]

Hi,

Post by Josef Poetzl
Ich betrachte nur jene als notwendig, die ich für die Ausführung per
DDL benötige. ;-)

O.K. Das ist auch eine Einstellung. Ist sozusagen das Minimum an
Eigenschaften.

Post by Josef Poetzl
Die "Darstellungseigenschaft" für den Pfeil der Verbindungslinie
(Standard für Verknüpfungstyp im Abfrageentwurf) wird dann zwar nicht
gesetzt, das ist für mich aber eine unnötige Einstellung, die nur das
"Verstehen" von Beziehungen verhindert. ;-)

Für mich *prinzipiell* auch überflüssig. Nur habe ich eben den Anspruch
die Relationen außer der Löschweitergabe *nicht* zu verändern.

Post by Josef Poetzl

Post by Thomas Winkler
BTW: Kann man der Tabelle vllt. irgendwie das Schreibgeschützt-Flag
manipulieren - von mir aus auch per Hex-Editor?

Was meinst du mit "Schreibgeschützt-Flag"?

Die Tabelle ist schreibgeschützt. Es muss also irgendwo in einer MDB
eine Stelle geben, an der vermerkt ist, ob eine Tabelle beschreibbar ist
oder nicht. Natürlich kann es sein, dass man darauf keinen Zugriff aus
Access heraus hat (GUI oder VBA) - aber mindestens mir dem Hex-Editor
sollte man den haben.

Thomas

--
"Access? Damit arbeite ich nicht. Das ist doch nur ein abgespecktes Excel."

[Josef Poetzl]

Hallo!

Post by Thomas Winkler

Post by Josef Poetzl
Die "Darstellungseigenschaft" für den Pfeil der Verbindungslinie
(Standard für Verknüpfungstyp im Abfrageentwurf) wird dann zwar nicht
gesetzt, das ist für mich aber eine unnötige Einstellung, die nur das
"Verstehen" von Beziehungen verhindert. ;-)

Für mich *prinzipiell* auch überflüssig. Nur habe ich eben den Anspruch
die Relationen außer der Löschweitergabe *nicht* zu verändern.

Mehr als die RI-Eigenschaften, die Felder und die Pfeilart kann man
auch über das Beziehungsfenster nicht einstellen, oder?
Somit müsste doch das Neuerstellen mit diesen Werten einer Kopie
entsprechen.

Post by Thomas Winkler

Post by Josef Poetzl

Post by Thomas Winkler
BTW: Kann man der Tabelle vllt. irgendwie das Schreibgeschützt-Flag
manipulieren - von mir aus auch per Hex-Editor?

Was meinst du mit "Schreibgeschützt-Flag"?

Die Tabelle ist schreibgeschützt. Es muss also irgendwo in einer MDB
eine Stelle geben, an der vermerkt ist, ob eine Tabelle beschreibbar ist
oder nicht. Natürlich kann es sein, dass man darauf keinen Zugriff aus
Access heraus hat (GUI oder VBA) - aber mindestens mir dem Hex-Editor
sollte man den haben.

Meinst du damit einen Schreibschutz über die
Access-Sicherheitseinstellungen (Benutzer- u. Gruppenberechtigungen)?
Das müsste dann über die GRANT-Anweisung einstellbar sein.
| GRANT insert,update,delete ON TABLE DeineTabelle TO BenutzerOderGruppe
... natürlich nur dann, wenn du das Recht dazu hast oder es dir gibst.
;-)


mfg
Josef

[Thomas Winkler]

Hi,

Post by Josef Poetzl
Meinst du damit einen Schreibschutz über die
Access-Sicherheitseinstellungen (Benutzer- u. Gruppenberechtigungen)?
Das müsste dann über die GRANT-Anweisung einstellbar sein.
| GRANT insert,update,delete ON TABLE DeineTabelle TO BenutzerOderGruppe
.... natürlich nur dann, wenn du das Recht dazu hast oder es dir gibst.
;-)

Nein. Ich meine die *Systemtabelle* MSysRelationships. Die ist IMHO
unabhängig von den Access-Sicherheitseinstellungen *immer* schreibgeschützt.

Trotzdem getest:
GRANT SELECT, DELETE, INSERT, UPDATE, DROP, SELECTSECURITY,
UPDATESECURITY, UPDATEIDENTITY, CREATE, SELECTSCHEMA, SCHEMA,
UPDATEOWNER ON TABLE MSysRelationships TO admin;

Wie erwartet: Keine Schreibrechte.

Thomas

--
"Access? Damit arbeite ich nicht. Das ist doch nur ein abgespecktes Excel."

[Josef Poetzl]

Hallo!

Post by Thomas Winkler
Nein. Ich meine die *Systemtabelle* MSysRelationships. Die ist IMHO
unabhängig von den Access-Sicherheitseinstellungen *immer* schreibgeschützt.

Darin haben wir ja auch nichts zu suchen. ;-)
Und auch wenn man es schaffen würde, deren Datenfelder beschreibbar zu
bekommen, ich würde mich nicht darauf verlassen, dass damit alles so
eingestellt ist, wie es sein soll.
Da vertraue ich doch eher dem Neuerstellen mit identischen Werten.
(Name, Felder u. Attribute - oder eben jene Eigenschaften, die in der
Hilfe als verfügbar gekennzeichnet sind.)

mfg
Josef

[Josef Poetzl]

Hallo!

Post by Thomas Winkler

Post by Josef Poetzl
Das liegt imo daran, dass die DAO.Field-Schnittstelle auch für
Indizes, TableDef usw. verwendet wird. Daher gibt es darin
Eigenschaften, die nicht überall verwendet werden.

OK. Das wäre eine Erklärung.

Und kaum sucht man in der OH, findest man schon etwas. ;-)

Microsoft DAO 3.60-Hilfe:
Referenz für DAO-Objekte
-> F-O
-> Field-Objekt, Fields-Auflistung - Zusammenfassung

Dort ist eine Übersicht, welche Methoden und Eigenschaften von Field
in den jeweiligen Strukturen (Index, TabelDef,...) verfügbar sind.


mfg
Josef

[Thomas Winkler]

Hi,

Post by Josef Poetzl
Und kaum sucht man in der OH, findest man schon etwas. ;-)
Referenz für DAO-Objekte
-> F-O
-> Field-Objekt, Fields-Auflistung - Zusammenfassung
Dort ist eine Übersicht, welche Methoden und Eigenschaften von Field
in den jeweiligen Strukturen (Index, TabelDef,...) verfügbar sind.

Dort hatte ich noch nicht nachgeschaut. Aber die Infos dort kann man
auch vergessen, bzw. sind schon zu alt.

Es gibt z.B. mindestens *eine* weitere Property welches in einem .Field
einer DAO.Relation verfügbar ist.

Sie nennt sich "CollectionIndex" und enthält einen Integer-Wert -
vielleicht eine interne OID. Diese Property ist z.B. *nicht* in der OH
an genannter Stelle zu finden.

Und *das* sind genau die Gründe, weshalb ich die Reduktion der
verwendeten Properties auf das Minimum (für SQL-CREATE-CONSTRAINT) für
kritisch halte bzw. die Folgen nicht abschätzen kann.

Thomas

--
"Access? Damit arbeite ich nicht. Das ist doch nur ein abgespecktes Excel."

[Thomas Winkler]

Hi,

Post by André Minhorst
Generell würde es mir allerdings Bauchschmerzen bereiten, pauschal die
Löschweitergabe aller Relationen zu aktivieren.

Es handelt sich nicht um eine Produktiv-DB. Es handelt sich um eine
einmalige Aktion auf einer Kopie, die danach verworfen wird. Die Anzahl
der Tabellen macht ein manuelles Vorgehen unmöglich. Außerdem gehts
nicht nur um das *setzen* LWG sondern ggf. auch ums Löschen und auch um
die AWG.

Thomas

[André Minhorst]

Hi Thomas,

Post by Thomas Winkler

Post by André Minhorst
Generell würde es mir allerdings Bauchschmerzen bereiten, pauschal die
Löschweitergabe aller Relationen zu aktivieren.

Es handelt sich nicht um eine Produktiv-DB. Es handelt sich um eine
einmalige Aktion auf einer Kopie, die danach verworfen wird.

vielleicht kannst Du nächstes Mal direkt sagen, dass das, wonach Du fragst,
sowieso für den Mülleimer ist ...

Ciao
André

[Stefan Hoffmann]

hi Thomas,

Post by Thomas Winkler
ich will per VBA die Löschweitergabe bestimmter Verknüpfungen setzen.

Ich denke mit Neuerzeugen geht es:

http://www.office-loesung.de/ftopic52752_0_0_asc.php


mfG
--> stefan <--

[Karl Donaubauer]

Post by Thomas Winkler
ich will per VBA die Löschweitergabe bestimmter Verknüpfungen setzen.
Dim rel As DAO.Relation
For Each rel In CurrentDb.Relations
rel.Attributes = (rel.Attributes Or dbRelationDeleteCascade)
Next rel
Nur leider tritt bei der Zuweisung der Laufzeitfehler 3219
("Unzulässige Oepration") auf.
Wie kann ich nun die Löschweitergabe einer Verknüpfung setzen?

Für eine bestehende IMO gar nicht, denn die Attributes sind da readonly.
--> Löschen und Neuerstellen mit den gewünschten Attributen

[André Minhorst]

Hi,

Post by Karl Donaubauer

Post by Thomas Winkler
ich will per VBA die Löschweitergabe bestimmter Verknüpfungen setzen.
Dim rel As DAO.Relation
For Each rel In CurrentDb.Relations
rel.Attributes = (rel.Attributes Or dbRelationDeleteCascade)
Next rel
Nur leider tritt bei der Zuweisung der Laufzeitfehler 3219
("Unzulässige Oepration") auf.
Wie kann ich nun die Löschweitergabe einer Verknüpfung setzen?

Für eine bestehende IMO gar nicht, denn die Attributes sind da readonly.
--> Löschen und Neuerstellen mit den gewünschten Attributen

gerade getestet:

Dim cnn As ADODB.Connection
Dim strSQL As String

Set cnn = CurrentProject.Connection

'erste Beispieltabelle erzeugen:
strSQL = "CREATE TABLE tblMitarbeiter(" _
& "MitarbeiterID COUNTER CONSTRAINT PKMitarbeiterID PRIMARY KEY, " _
& "Mitarbeiternummer TEXT(10) " _
& "CONSTRAINT UniqueMitarbeiternummer UNIQUE, " _
& "Vorname TEXT(50) NOT NULL, " _
& "Nachname TEXT (50) NOT NULL, " _
& "AbteilungID INTEGER) "

cnn.Execute strSQL

'verknüpfte Tabelle erzeugen:
strSQL = "CREATE TABLE tblAbteilungen(" _
& "AbteilungID COUNTER CONSTRAINT PKAbteilungID PRIMARY KEY, " _
& "Abteilung TEXT(255))"

cnn.Execute strSQL

'Verknüpfung mit Lösch- und Aktualisierungsweitergabe setzen:
strSQL = "ALTER TABLE tblMitarbeiter ADD CONSTRAINT FKAbteilungID FOREIGN
KEY (AbteilungID) REFERENCES tblAbteilungen ON UPDATE CASCADE ON DELETE
CASCADE"

Set cnn = CurrentProject.Connection

cnn.Execute strSQL

Set cnn = Nothing

Ciao
André

[Karl Donaubauer]

Post by André Minhorst

Post by Karl Donaubauer

Post by Thomas Winkler
ich will per VBA die Löschweitergabe bestimmter Verknüpfungen
Dim rel As DAO.Relation
For Each rel In CurrentDb.Relations
rel.Attributes = (rel.Attributes Or dbRelationDeleteCascade)
Next rel
Nur leider tritt bei der Zuweisung der Laufzeitfehler 3219
("Unzulässige Oepration") auf.
Wie kann ich nun die Löschweitergabe einer Verknüpfung setzen?

Für eine bestehende IMO gar nicht, denn die Attributes sind da readonly.
--> Löschen und Neuerstellen mit den gewünschten Attributen

Dim cnn As ADODB.Connection
Dim strSQL As String
Set cnn = CurrentProject.Connection
strSQL = "CREATE TABLE tblMitarbeiter(" _
& "MitarbeiterID COUNTER CONSTRAINT PKMitarbeiterID PRIMARY KEY, "
_ & "Mitarbeiternummer TEXT(10) " _
& "CONSTRAINT UniqueMitarbeiternummer UNIQUE, " _
& "Vorname TEXT(50) NOT NULL, " _
& "Nachname TEXT (50) NOT NULL, " _
& "AbteilungID INTEGER) "
cnn.Execute strSQL
strSQL = "CREATE TABLE tblAbteilungen(" _
& "AbteilungID COUNTER CONSTRAINT PKAbteilungID PRIMARY KEY, " _
& "Abteilung TEXT(255))"
cnn.Execute strSQL
strSQL = "ALTER TABLE tblMitarbeiter ADD CONSTRAINT FKAbteilungID
FOREIGN KEY (AbteilungID) REFERENCES tblAbteilungen ON UPDATE CASCADE
ON DELETE CASCADE"
Set cnn = CurrentProject.Connection
cnn.Execute strSQL
Set cnn = Nothing

Ursuper getestet, André!
Jetzt noch ein Beispiel, das zeigt, wie man eine _bereits bestehende_
Beziehung mit einer Löschweitergabe versorgt, und schon hätte das
Ganze etwas mit meiner Aussage zu tun.

Also auf zum CONSTRAINT, Alter!... ähh ALTER CONSTRAINT oder so.

[André Minhorst]

Post by Karl Donaubauer

Post by André Minhorst

Post by Karl Donaubauer

Post by Thomas Winkler
ich will per VBA die Löschweitergabe bestimmter Verknüpfungen
Dim rel As DAO.Relation
For Each rel In CurrentDb.Relations
rel.Attributes = (rel.Attributes Or dbRelationDeleteCascade)
Next rel
Nur leider tritt bei der Zuweisung der Laufzeitfehler 3219
("Unzulässige Oepration") auf.
Wie kann ich nun die Löschweitergabe einer Verknüpfung setzen?

Für eine bestehende IMO gar nicht, denn die Attributes sind da readonly.
--> Löschen und Neuerstellen mit den gewünschten Attributen

Dim cnn As ADODB.Connection
Dim strSQL As String
Set cnn = CurrentProject.Connection
strSQL = "CREATE TABLE tblMitarbeiter(" _
& "MitarbeiterID COUNTER CONSTRAINT PKMitarbeiterID PRIMARY KEY, "
_ & "Mitarbeiternummer TEXT(10) " _
& "CONSTRAINT UniqueMitarbeiternummer UNIQUE, " _
& "Vorname TEXT(50) NOT NULL, " _
& "Nachname TEXT (50) NOT NULL, " _
& "AbteilungID INTEGER) "
cnn.Execute strSQL
strSQL = "CREATE TABLE tblAbteilungen(" _
& "AbteilungID COUNTER CONSTRAINT PKAbteilungID PRIMARY KEY, " _
& "Abteilung TEXT(255))"
cnn.Execute strSQL
strSQL = "ALTER TABLE tblMitarbeiter ADD CONSTRAINT FKAbteilungID
FOREIGN KEY (AbteilungID) REFERENCES tblAbteilungen ON UPDATE CASCADE
ON DELETE CASCADE"
Set cnn = CurrentProject.Connection
cnn.Execute strSQL
Set cnn = Nothing

Ursuper getestet, André!
Jetzt noch ein Beispiel, das zeigt, wie man eine _bereits bestehende_
Beziehung mit einer Löschweitergabe versorgt, und schon hätte das
Ganze etwas mit meiner Aussage zu tun.
Also auf zum CONSTRAINT, Alter!... ähh ALTER CONSTRAINT oder so.

Leute, Ihr müsst noch mehr unterstreichen, damit ich es leichter habe, die
Fragestellung zu interpretieren ...

Ciao
André