Tabellenstruktur kopieren per VB

[Lutz Uhlmann]

Hi NG

Ich arbeite grad an einem Programm (Access 2003), wo ich zu
Archivierungszwecken je eine Tabelle pro Jahr anlegen möchte.

Ich brauche also folgende Funktionalität:
Ich öffne meine Backend-Db per VB und lege dort eine Kopie der Mustertabelle
TabXXXX namens Tab2008 an. Dabei soll nur die Struktur kopiert werden.

Habe bereits DoCmd.Transfer und DoCmd.CopyObject probiert, aber die arbeiten
leider mit der aktuellen Datenbank (Frontend) und nicht mit dem BE welches
ich vorher explizit öffne ...
Wie könnte ich noch eine leere Kopie meiner Tabelle anlegen?

Lutz

[Stefan Hoffmann]

hi Lutz,

Post by Lutz Uhlmann
Ich öffne meine Backend-Db per VB und lege dort eine Kopie der Mustertabelle
TabXXXX namens Tab2008 an. Dabei soll nur die Struktur kopiert werden.

Definiere Struktur.

Ein

INSERT INTO Tab2008
SELECT *
FROM TabXXXX
WHERE False

könnte schon ausreichend sein.


mfG
--> stefan <--

[Mark Doerbandt]

Hallo, Lutz,

Post by Lutz Uhlmann
Ich öffne meine Backend-Db per VB und lege dort eine Kopie der Mustertabelle
TabXXXX namens Tab2008 an. Dabei soll nur die Struktur kopiert werden.

was spricht dagegen, in der Archivtabelle ein Feld "ArchivJahr"
anzulegen - dann brauchst Du keine neuen Tabellen anlegen.

Gruss - Mark

[Lutz Uhlmann]

Post by Mark Doerbandt
was spricht dagegen, in der Archivtabelle ein Feld "ArchivJahr"
anzulegen - dann brauchst Du keine neuen Tabellen anlegen.

Prinzipiell würde das gehen.

Eigentlich hab ich mich aber für eine Aufsplittung entschieden und möchte
das Konzept vorerst auch nicht ändern.
Kann ja eigentlich nicht so schwer sein, eine Tabelle zu kopieren, oder doch
???

Notfalls müßte ich das eben doch nochmal abändern. Aber es würde mich
prinzipiell mal interessieren, wie ich eine Tabelle kopieren kann.

Lutz

[Mark Doerbandt]

Hallo, Lutz,

Post by Lutz Uhlmann
Eigentlich hab ich mich aber für eine Aufsplittung entschieden und möchte
das Konzept vorerst auch nicht ändern.

warum hast Du Dich dafuer entschieden? Welche Vorteile hast Du davon?

Gruss - Mark

[Lutz Uhlmann]

Post by Mark Doerbandt

Post by Lutz Uhlmann
Eigentlich hab ich mich aber für eine Aufsplittung entschieden und möchte
das Konzept vorerst auch nicht ändern.

warum hast Du Dich dafuer entschieden? Welche Vorteile hast Du davon?

Würde jetzt hier zuweit vom Thema wegführen. Ich bin auch am Prüfen ob ich
das auch noch ohne die einzelnen Jahres-Tabellen mache.

Allerdings würde mich wirklich mal völlig unabhängig vom konkreten Problem
interessieren, wie ich eine Tabelle per Vb kopieren kann?
Gibts da keine anderen Möglichkeiten außer die genannten CopyObject,
Transfer und per SQL?

Theoretisch ginge es auch wenn man eine Tabelle neu anlegt und die Felder
(Indizes) der alten Tabelle durchläuft (TableDef.Fields) und diese dann in
der neuen Tabelle einträgt - zugegeben sicherlich eine relativ aufwendige
Methode.

[Mark Doerbandt]

Hallo, Lutz,

Post by Lutz Uhlmann

Post by Mark Doerbandt
warum hast Du Dich dafuer entschieden? Welche Vorteile hast Du davon?

Würde jetzt hier zuweit vom Thema wegführen.

auch wenn ich manchmal penetrant erscheine: meist sind die Gruende,
warum jemand zur Laufzeit eine Tabelle erstellen moechte, durch andere
Massnahmen einfacher oder besser zu erreichen.

Natuerlich kann man Tabellen auch per VBA erstellen oder kopieren. Ich
denke aber, dass das im produktiven Betrieb nicht sinnvoll ist.

Gruss - Mark

[Lutz Uhlmann]

Post by Mark Doerbandt
auch wenn ich manchmal penetrant erscheine: meist sind die Gruende,
warum jemand zur Laufzeit eine Tabelle erstellen moechte, durch andere
Massnahmen einfacher oder besser zu erreichen.

Da hast du wohl recht. Hab jetzt auch umgestellt.
Alle aktuellen noch änderbaren Buchungen sind in Archiv1, alle alten
abgeschlossenen Buchungen sind in Archiv2. Somit halte ich das Archiv1 mit
dem gearbeitet wird relativ schlank und Archiv2 dient wirklich nur zum
archivieren. Bei einem Abschluß werden alle Datensätze aus 1 in 2
verschoben.

Post by Mark Doerbandt
Natuerlich kann man Tabellen auch per VBA erstellen oder kopieren. Ich
denke aber, dass das im produktiven Betrieb nicht sinnvoll ist.

Nein, wäre aber interessant für ein kleines Tool welches ich selber
geschrieben habe, mit dem ich meine MDBs bearbeiten und verwalten kann.

[Mark Doerbandt]

Hallo, Lutz,

Post by Lutz Uhlmann
Nein, wäre aber interessant für ein kleines Tool welches ich selber
geschrieben habe, mit dem ich meine MDBs bearbeiten und verwalten kann.

ok, /das/ ist ein ganz anderer Grund. Dafuer setze ich so etwas auch
ein. Du musst mal genauer definieren, was Du alles kopieren moechtest.
Tabellen und Felder, Indizes, Defaultwerte, Beschreibungen,
Beziehungen?

Gruss - Mark

[Josef Poetzl]

Hallo!

Post by Lutz Uhlmann
Aber es würde mich
prinzipiell mal interessieren, wie ich eine Tabelle kopieren kann.

Was verstehst du unter "Tabelle kopieren"?

Sollen nur die Datenfelder mit den Datentypen übernommen werden?
Oder sollen auch die Indizes, Einschränkungen, Feldbeschreibungen usw.
kopiert werden?

mfg
Josef

[Lutz Uhlmann]

Post by Josef Poetzl
Was verstehst du unter "Tabelle kopieren"?
Sollen nur die Datenfelder mit den Datentypen übernommen werden?
Oder sollen auch die Indizes, Einschränkungen, Feldbeschreibungen usw.
kopiert werden?

Ja eigentlich schon.
Genauso als würde ich im Datenbank-Fenster oder per DoCmd.Transfer eine
Tabelle kopieren.
Nur eben per VB in einer beliebeigen MDB.

[Josef Poetzl]

Hallo!

Post by Lutz Uhlmann

Post by Josef Poetzl
Was verstehst du unter "Tabelle kopieren"?
Sollen nur die Datenfelder mit den Datentypen übernommen werden?
Oder sollen auch die Indizes, Einschränkungen, Feldbeschreibungen usw.
kopiert werden?

Ja eigentlich schon.
Genauso als würde ich im Datenbank-Fenster oder per DoCmd.Transfer eine
Tabelle kopieren.
Nur eben per VB in einer beliebeigen MDB.

Mit DoCmd.TransferDatabase kannst du zumindest die Tabelle inkl.
Indizes, Einschränkungen und Beziehungen kopieren.

Beispiel:
DoCmd.TransferDatabase acExport, "Microsoft Access", _
"D:\ein\ZielBE.mdb", acTable, "Tabelle", "Tabelle_2008", True


mfg
Josef

[Josef Poetzl]

Hallo!

Post by Josef Poetzl
Mit DoCmd.TransferDatabase kannst du zumindest die Tabelle inkl.
Indizes, Einschränkungen und Beziehungen kopieren.

... natürlich ohne Beziehungen (RI) - dafür aber mit der Beschreibung.

mfg
Ingrid

[Lutz Uhlmann]

Post by Josef Poetzl
Mit DoCmd.TransferDatabase kannst du zumindest die Tabelle inkl.
Indizes, Einschränkungen und Beziehungen kopieren.
DoCmd.TransferDatabase acExport, "Microsoft Access", _
"D:\ein\ZielBE.mdb", acTable, "Tabelle", "Tabelle_2008", True

Soweit richtig, dafür muß aber die Quell-Tabelle (Export) bzw Ziel-Tabelle
(Import) in meiner aktuellen Datenbank liegen.
Funktioniert leider nicht mehr, wenn ich per VB eine Datenbank öffne und
dort Tab1 nach Tab2 kopieren möchte.
Dazu müßte ich wahrscheinlich die zu bearbeitende Datenbank mit
OpenCurrentDatabase als aktuelle Db öffnen.

[Wolfgang Badura]

Hallo Lutz!

Post by Lutz Uhlmann

Post by Josef Poetzl
DoCmd.TransferDatabase acExport, "Microsoft Access", _
"D:\ein\ZielBE.mdb", acTable, "Tabelle", "Tabelle_2008", True

Soweit richtig, dafür muß aber die Quell-Tabelle (Export) bzw Ziel-Tabelle
(Import) in meiner aktuellen Datenbank liegen.

Stimmt so nicht.
Beim Export ist die Zieltabelle frei wählbar.
Sinnvoll ist es deshalb, sich in der DB mit der Quelltabelle zu befinden.
Hat außerdem den Vorteil, wenn eine in der Ziel-DB schon vorhandene Tabelle
damit überschrieben würde und diese dort Beziehungen zu anderen Tabellen
hat, daß diese ohne Fehler überschrieben wird. Das geht beim Import nicht.
Wolfgang

[Wolfgang Badura]

Hallo!

Post by Wolfgang Badura
Beim Export ist die Zieltabelle frei wählbar.

Muß statt Zieltabelle Zieldatenbank heißen!
Wolfgang

Post by Wolfgang Badura
Hallo Lutz!

Post by Lutz Uhlmann

Post by Josef Poetzl
DoCmd.TransferDatabase acExport, "Microsoft Access", _
"D:\ein\ZielBE.mdb", acTable, "Tabelle", "Tabelle_2008", True

Soweit richtig, dafür muß aber die Quell-Tabelle (Export) bzw Ziel-Tabelle
(Import) in meiner aktuellen Datenbank liegen.

Stimmt so nicht.
Beim Export ist die Zieltabelle frei wählbar.
Sinnvoll ist es deshalb, sich in der DB mit der Quelltabelle zu befinden.
Hat außerdem den Vorteil, wenn eine in der Ziel-DB schon vorhandene Tabelle
damit überschrieben würde und diese dort Beziehungen zu anderen Tabellen
hat, daß diese ohne Fehler überschrieben wird. Das geht beim Import nicht.
Wolfgang

[Stefan Hoffmann]

Meinte eigentlich:

SELECT *
INTO Tab2008
FROM TabXXX
WHERE False


mfG
--> stefan <--

[Lutz Uhlmann]

Post by Stefan Hoffmann
SELECT *
INTO Tab2008
FROM TabXXX
WHERE False

Wie sieht es da aus mit den Feld-Eigenschaften??? Werden die 1:1 übernommen?

[Stefan Hoffmann]

hallo Lutz,

Post by Lutz Uhlmann

Post by Stefan Hoffmann
SELECT *
INTO Tab2008
FROM TabXXX
WHERE False

Wie sieht es da aus mit den Feld-Eigenschaften??? Werden die 1:1 übernommen?

Jain, aber das ist bei einer Archivtabelle ja auch nicht notwendig.


mfG
--> stefan <--

[Mark Doerbandt]

Hallo, Lutz,

Post by Lutz Uhlmann
Wie sieht es da aus mit den Feld-Eigenschaften??? Werden die 1:1 übernommen?

darueber brauchst Du Dir bei meinem Vorschlag keine Gedanken machen.

Gruss - Mark

[Karl Donaubauer]

Post by Lutz Uhlmann
...
Ich öffne meine Backend-Db per VB und lege dort eine Kopie der
Mustertabelle TabXXXX namens Tab2008 an. Dabei soll nur die Struktur
kopiert werden.
Habe bereits DoCmd.Transfer und DoCmd.CopyObject probiert, aber die
arbeiten leider mit der aktuellen Datenbank (Frontend) und nicht mit
dem BE welches ich vorher explizit öffne ...

Du kannst DoCmd.TransferDatabase (wegen des Nur-Struktur-
Parameters) verwenden, wenn du per Automatisierung mit
dem BE arbeitest. S. das zweite Codebeispiel in
www.donkarl.com?FAQ1.21, in dem das für einen anderen
DoCmd-Befehl vorgeführt wird.

[Dieter Fillsner]

Hi Lutz,

warum machst Du nicht folgendes :

1. Import Tabelle nach Zwischentabelle

2. Export Zwischentabelle nach ZielTabelle

3. löschen interne (zwischen-) Tabelle

Gruß
Dieter