Office: (Office 2013) BackEnd-DB updaten per VBA

Code:

Man könnte ja überprüfen, ob die Anweisung das tut, was man sich einbildet.
Ich würde eher an so etwas denken:
Code:

Mir ist allerdings nicht einsichtig, warum man (außer bei Temp-Vorgängen) eine Tabelle löschen muss, um sie neu einzubringen. Wenn ich eine neue Tür im Haus brauche, mache ich ein Loch in die Wand statt das Haus komplett abzureißen und neu aufzubauen. Ich bin aber auch faul (aufwandssparend).
Für Tabellen des Datenmodells dürfte ein Löschen wegen der vorhandenen Beziehungen und Schlüssel extremst schwierig bis unmöglich sein, von der ordnungsgemäßen gleichwertigen Wiederherstellung wollen wir da noch gar nicht reden.

Ob die von Dir verwendeten Append-Anweisungen funktionieren können oder im Stadium des Experimentierens verbleibend verharren, da bin ich schwer unschlüssig.
Gerade beim Experimentieren würde ich jeden Schritt und sein Ergebnis einzeln überprüfen und nichts vorher als gegeben oder gar funktionierend annehmen.

Sowie: Neben TransferDatabase kann man Tabellen auch per Tabellenerstellungsabfrage übertragen, Beziehungen, Indizes, Gültigkeitsregeln & Co. interessieren doch niemanden ... bei einer Tabelle namens "Version_BE".

 

\@ebs17:

Ich schrieb ja schon in #6, wozu diese Code-Zeilen dienen und es steht auch so im Code.

Genau. Habe ich getan bis hin zu der Code-Zeile, die den Fehler wirft.

Siehe "Tabelle ändern": eben drum versuche ich, die neuen Felder aus dem Tabellenschema FE in das Tabellenschema BE zu "injizieren". Dann braucht es kein Löschen einer Tabelle und keine Beziehungen gehen verloren.
Siehe "Tabelle neu hinzufügen": es versteht sich von selbst, dass benötigte Beziehungen angelegt werden. Die werden aber erst benötigt, wenn das Übertragen wie gewünscht funktioniert. Und dass es aktuell nicht funktioniert liegt nicht an den fehlenden Beziehungen....

Viele Grüße
Michael

 

Und hier noch ein Versuch mit der TransferDatabase-Methode.

Die Idee dahinter: zunächst übertragen wir die neuen / geänderten Strukturen unter einem neuen Namen in das BE und bedienen uns dann der neuen Tabellen im BE, um die zusätzlichen Attribute in der Original-Tabelle anzulegen.

Am Beispiel der Tabelle REZEPT:
Originaltabelle BE = REZEPT
Neue Struktur im FE = REZEPT_neu
Neue Struktur im BE = REZEPT_neu_BE

Leider ist das Ergebnis das selbe... *frown.gif*

Code:

Ergebnisse debug.print lassen ein anderes Ergebnis vermuten oder doch zumindest erhoffen:
REZEPT_neu_BE
REZEPT

Das hinterlässt mich doch arg ratlos...

Viele Grüße
Michael

 

So etwas ist dann nur einfach so hingeschrieben und ansonsten ohne Bedeutung ... nur um Klarheit über die Unklarheit bei Personen zu zeigen bzw. zu erzeugen?

Tabellenschema und FE?
Was neu ist, weiß der Entwickler doch im Moment des Entwickelns. Da kann er es auch gleich aufschreiben.

Eine Sequenz könnte so aussehen:
Code:

Das ist einfach, sicher und bestens zu lesen. Am besten in einer zusätzlichen Datei oder einem Script zu platzieren, weil eine Aktualisierung pro Struktur-Update nur einmal nötig ist. Welche Riesendiskussionen braucht es noch rundherum?

Das Kommentieren eines jeden der Versuche von Michael übernimmt bitte jemand anders. Experimentieren ist ja auch Zeitvertreib. Bei mir ist dazu schon genug vertrieben.

 

Hallo Michael,

du solltest ja bisher mitbekommen haben, daß die DoCmd-Aktionen sich immer auf die aktuelle Datenbank beziehen.

Nochmal mein Tipp, sich mit XML zu beschäftigen. Es gibt in Access die beiden Befehle ExportXML und ImportXML. Mit diesen kann z.B. sehr einfach eine komplette Schemadatei für eine Tabelle erstellt werden. Diese XML-Datei läßt sich entsprechend seinen Bedürfnissen anpassen und wieder importieren.
Man könnte diese XML-Datei auch distributieren, damit neue Tabellen exakt inkl. aller Felder und deren Properties anlegen und dann die Daten per Insert in die neue Tabellen zu übernehmen. Mit den XML-Dateien kann man noch mehr machen. Infos hierzu in den entsprechenden Dokus von MS.

Ich habe das gerade mal anhand einer Tabelle ausprobiert. Schema exportiert, angepaßt und als neue Tabelle importiert. Läuft hervorragend. Mit Daten sollte das ähnlich einfach gehen. Per Automation ließe sich das so auch mit einer externen Datenbank (BE) durchführen.

Grüße Ulrich

 

Eine solche Aussage ist unvollständig, siehe Objektmodell von Access.
Code:

Ohne weitere Qualifizierung des Application-Objektes kann man nur die aktuelle DB ansprechen.

Ob die Maßnahmen mit XML einfacher und vollständig (Beziehungen, Indizes, Gültigkeitsregeln, weitere Feldeigenschaften wie DefaultValue, neuerdings DataMacros, Anlagefelder?) machbar sind, würde ich bezweifeln. Datenbank ist ein wenig mehr als eine Tabelle.

 

\@Eberhard

Zweifel sind immer gut. Man das aber anhand einer bestehenden Tabelle selber überprüfen, dann hätte man Klarheit, bezüglich was geht und was nicht geht. Soweit ich das bisher sehen konnte, sind die Feldeigenschaften enthalten, inkl. dem Property "DefaultValue". Ob auch "CustomProperties" mit einbezogen werden, müsste man eventuell prüfen. Aber bis jetzt sieht das nicht schlecht aus.

Ja klar, aber es gibt nun mal nur die bekannten Möglichkeiten in Access.

Wenn du noch andere Vorschläge hast ...
Im Prinzip betrifft das Problem ja alle, die eine DB distibutieren und pflegen müssen.

Gruß Ulrich

 

\@Ulrich,
ich habe die Methode mit dem XML ganz vergessen.
Danke für die Erinnerung. Man wird mit der Zeit ja so einseitig und vergisst dabei diverse Möglichkeiten.

 

Hallo zusammen,

ich versuche noch einmal, die bisherigen Erkenntnisse zusammenzufassen. Vielleicht finden wir ja doch noch einen einfachen Lösungsansatz, der den Anforderungen gerecht wird.

Anforderung:

1. Änderungen am BE automatisiert durch ein Update-Programm auf dem Rechner des Benutzers durchführen, ohne dass der Benutzer die BE-Datei an den Entwickler verschicken muss.
2. Bestehende Tabellen im BE um zusätzliche Attribute erweitern, ohne die Original-Tabelle im BE löschen oder umbenennen zu müssen (kein Verlust von Beziehungen).
3. Neue Tabellen im BE hinzufügen und erforderliche Beziehungen anlegen.

Mir geht es um eine einfache und wenig fehleranfällige Variante. Neue Felder oder gar ganze Tabellen Feld für Feld mit allen Attributen per VBA aufzubauen scheidet für mich deshalb aus. Weiterhin möchte ich vermeiden, bei bestehenden Tabellen Beziehungen im BE zu zerstören. Damit scheidet eine Lösung aus, bei der die neue Tabellenstruktur in das BE kopiert und dann die Daten aus der Original-Tabelle übertragen werden. Das trifft auch für XMLExport / XMLImport zu, wenn ich die Doku richtig verstanden habe.

In Post #18 kommen wir der Lösung ja schon recht nah. Und ich würde gern verstehen, warum
Code:

nicht zum Ziel führt.

Ich freue mich sehr über alle Beiträge, die sich auf die definierten Anforderungen und Rahmenbedingungen beziehen.

Viele Grüße
Michael

 

Prüfen kann man bei Jet nur per VBA, bestimmte Eigenschaften erstellen oder ändern dann auch nur per VBA. Um mehrere Anweisungen nacheinander "im Stück" auszuführen, da ist auch VBA nötig.

Da verbleibt Dir die gute Nachricht: Handbetrieb ist angesagt. Ob der dann live weniger fehleranfällig ist - da würde ich ein großes Fragezeichen setzen.

 

Soll das ein Witz sein.
Wir - ist hier nicht angebracht, da nur du dir einbildest, dass es so gehen muss.

Wenn du wissen willst, warum das nicht geht, musst du Microsoft fragen.
Die haben das so programmiert.

Wenn du alle Möglichkeiten ablehnst, ist das deine Sache, aber verarsche nicht die Helfer hier im Forum.

 

Hallo Michael,

ich habe das Gefühl, daß du von falschen Voraussetzungen ausgehts. Die Anforderungen hast du für dich selber definiert und eine Lösung als solches mußt du dir auch schon selber erarbeiten und programmieren. Da liegt die Verantwortung bei dir.

Hier im Forum wurden dir diesbezüglich bereits etliche Möglichkeiten mit den jeweiligen Vor- und Nachteilen aufgezeigt.

Ulrich