Access: Alter Table & Backend

Computer: Software & Programmierung Microsoft Access
#1

Liebe Expertinnen,

ich möchte einen Foreign Key droppen, den Autowert der referenzierten Tabelle zurücksetzen und den Foreign Key wieder anlegen. Schon beim Droppen renne ich allerdings vor die Wand:

Das Datenbankmodul konnte die Tabelle ‚SE_aktuell‘ nicht sperren, da sie bereits von einem anderen Benutzer oder Vorgang bearbeitet wird.
Da ist kein anderer Benutzer, die Tabelle liegt im Backend. Dort kann ich natürlich keine Module anlegen, deshalb liegt das Modul im Frontend. Sperrt das Frontend nun die Tabelle im Backend? Und wenn ja, wie komme ich da wieder raus?

Ich habe schon versucht, die CurrentdB zu schließen, das scheint auch zu gehen, die Fehlermeldung bleibt aber die gleiche. Wer weiß was?

Gruß Ralf

#2

Hallo Ralf,

WIE greifst Du auf das BE zu? Es ist nicht nötig, die BE-DB extra per Code zu öffnen (—> …bereits von einem anderen Benutzer …"), greif gleich auf die Verknüpfung im FE zu.

Weiterhin dürfte es Probleme geben, wenn die Primärschlüssel für Beziehungen verwendet sind. Dann müßten erst die Beziehungen gelöst und hinterher neu gesetzt werden.

Aber wozu das Ganze? Es sollte sich dabei nur um einen Einzelfall handeln, und dann wäre die manuelle Umsetzung besser geeignet.

Viele Grüße vom Bodensee
Franz , DF6GL

PS: Feedback erwünscht!

[Bei dieser Antwort wurde das Vollzitat nachträglich automatisiert entfernt]

#3

Moin, Franz,

WIE greifst Du auf das BE zu? Es ist nicht nötig, die BE-DB
extra per Code zu öffnen (—> …bereits von einem anderen
Benutzer …"), greif gleich auf die Verknüpfung im FE zu.

mein erster Ansatz war, die Tabelle direkt anzusprechen, Antwort (sinngemäß): Verknüpfte Tabellen können nicht geändert werden. Daraufhin habe ich die BE mit Opendatabase(BE-Name) geöffnet.

Weiterhin dürfte es Probleme geben, wenn die Primärschlüssel
für Beziehungen verwendet sind. Dann müßten erst die
Beziehungen gelöst und hinterher neu gesetzt werden.

Genau deshalb will ich ja einen Foreign Key droppen und hinterher neu anlegen.

Aber wozu das Ganze? Es sollte sich dabei nur um einen
Einzelfall handeln, und dann wäre die manuelle Umsetzung
besser geeignet.

Einmal im Jahr könnte der Eingriff nötig werden, und ich wollte mich nicht als Wartungstechniker binden.

Gruß Ralf

#4

Hallo,

Einmal im Jahr könnte der Eingriff nötig werden, und ich
wollte mich nicht als Wartungstechniker binden.

naja, dann mach eine MDB-Datei als „Wartungs-DB“ ohne irgendwelche Verknüpfungen und öffne die BE-Datei mit Opendatadase(als neuen Workspace). Anschließend hast Du SQL/DDL- und ADO/DAO-Zugriff auf die Tabellenstrukturen und kannst die Änderungen nach Belieben vornehmen. Die Grundsatz-Probleme, die sich mit der Änderung an Primärschlüsseln ergeben, sind damit aber nicht eliminiert. Die betroffenen Beziehungen müssen ebenfalls zunächst gelöscht werden, bevor ein Schlüsselfeld gelöscht werden kann.

Viele Grüße vom Bodensee
Franz , DF6GL

PS: Feedback erwünscht!

#5

Servus, Franz,

naja, dann mach eine MDB-Datei als „Wartungs-DB“ ohne
irgendwelche Verknüpfungen

versteh nur Bahnhof :frowning:

und öffne die BE-Datei mit Opendatadase(als neuen Workspace).

Das hatte ich schon.

Anschließend hast Du
SQL/DDL- und ADO/DAO-Zugriff auf die Tabellenstrukturen und
kannst die Änderungen nach Belieben vornehmen.

Eben nicht, sonst hätte ich nicht gefragt.

Die Grundsatz-Probleme, die sich mit der Änderung an
Primärschlüsseln ergeben, sind damit aber nicht eliminiert.

Auch das hatten wir schon, ist aber auch nicht meine Sorge. Die Daten, die sich per FS auf die Tabelle beziehen, deren Autowert ich zurücksetzen will, sind zu dem Zeitpunkt gelöscht. Mein Kummer ist die Beziehung, die ich nicht droppen kann.

Gruß Ralf

#6

Hallo Ralf,

ich möchte einen Foreign Key droppen, den Autowert der
referenzierten Tabelle zurücksetzen und den Foreign Key wieder
anlegen.

  • erstelle dir eine Kopie der Tabelle
  • ändere den FeldTyp des ID-Feldes von Autowert in ZAHL
  • trage deine gewünschte AUTOWERT Zahl dort ein
  • per Anfügeabfrage fügst du nun diesen Datensatz der Originaltabelle hinzu
  • fertig

Grüße aus Schönberg (Lübeck)
Wolfgang
(Netwolf)

#7

Moin, Wolfgang,

  • fertig

nicht ganz :smile: Mir geht es darum, den Zähler wieder bei 1 starten zu lassen, vor allem aber möchte ich das Ganze aus der Applikation heraus machen, nicht in der Entwicklungsumgebung. Auch dort würde ich’s ein wenig anders bauen:

  • Kopiere Tabelle, nur Struktur
  • Anfügeabfrage: alte Tabelle ohne Key --> neue Tabelle
  • drop ausgehende Beziehung
  • drop alte Tabelle
  • rename neue Tabelle
  • create ausgehende Beziehung

Gruß Ralf

#8

Hallo Ralf,

Dein Kummer ist doch:

„Das Datenbankmodul konnte die Tabelle ‚SE_aktuell‘ nicht sperren, da sie bereits von einem anderen Benutzer oder Vorgang bearbeitet wird.“

oder nicht?

Wenn, dann wird auf diese Tabelle akt. schon (im Edit-Modus) zugegriffen, und das muß zunächst abgestellt werden.

Viele Grüße vom Bodensee
Franz , DF6GL

PS: Feedback erwünscht!

#9

Hallo,

Mir geht es darum, den Zähler wieder bei 1
starten zu lassen, vor allem aber möchte ich das Ganze aus der
Applikation heraus machen,

Lösche aus dem FE heraus den Inhalt(!, nicht die Tabelle selber) der Mastertabelle(n) und den Inhalt der dazugehörenden n-Tabellen (explizit, falls keine Löschweitergabe und ref. Integrität definiert wurde)

Anschließend repariere/komprimiere das BE.

Die Kopiererei der Tabellen erschließt sich mir nicht, wobei ich auch Schwierigkeiten mit der oben zitierten Anforderung habe… :wink:

Autowerte sind nicht für „Durchnummerierungen“ geeignet und sind als Primärschlüssel(-Wert) für den User aussagelos.

Viele Grüße vom Bodensee
Franz , DF6GL

PS: Feedback erwünscht!

1 Like
#10

Moin, Franz,

Dein Kummer ist doch:

„Das Datenbankmodul konnte die Tabelle ‚SE_aktuell‘ nicht
sperren, da sie bereits von einem anderen Benutzer oder
Vorgang bearbeitet wird.“

jetzt fangen wir an, uns im Kreis zudrehen - so fing die Sache doch an, dass ich mir nicht erklären konnte (und kann), wer da sperrt.

Gruß Ralf

#11

Moin, Franz,

Lösche aus dem FE heraus den Inhalt
(…)
Anschließend repariere/komprimiere das BE.

Bingo, das war der Trick. Vor Jahren mal irgendwo gelesen (vielleicht sogar im Kompendium), damals nicht gebraucht und prompt vergessen. Besternten Dank!

Autowerte sind nicht für „Durchnummerierungen“ geeignet und
sind als Primärschlüssel(-Wert) für den User aussagelos.

schtümmt. Mir ist es dennoch gelungen, diese eherne Regel zu brechen:

Mitglieder werden (m:n) Gruppen zugeordnet, diese Zuordnung hat einen Ident, der nur solange lebt, bis das Mitglied aus der Gruppe aussteigt. Zuordnung zu einer Gruppe ergibt einen neuen Wert für den Ident. 20 % der Mitglieder wechseln pro Saison die Gruppe.

Der Ident (und einiges mehr) wird als Barcode auf Karten gedruckt, die der Spieler am Ende zurückgibt. Da der Barcodeleser mal ausfallen könnte, wird der Ident im Klartext mit angedruckt, dann kann der Erfasser ihn eintippen. Und da auf dem Etikett nur 3 Stellen Platz haben, …

Gruß Ralf