Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
A03: Per VBA zu einer Tabelle ein leeres Feld hinzufügen
724 views
Skip to first unread message
Rüdiger Gram
Apr 19, 2012, 11:03:10 AM4/19/12
to
Hallo NG,
an eine vorhandene Tabelle möchte ich per Code ein neues, leeres
Ja/Nein-Feld anfügen. Seit Stunden würge ich schon daran herum und kriege es
einfach nicht gebacken.
Kann mir jemand sagen (schreiben), wie man das macht?
Herzlichen Dank im voraus.
Rüdiger
an eine vorhandene Tabelle möchte ich per Code ein neues, leeres
Ja/Nein-Feld anfügen. Seit Stunden würge ich schon daran herum und kriege es
einfach nicht gebacken.
Kann mir jemand sagen (schreiben), wie man das macht?
Herzlichen Dank im voraus.
Rüdiger
Jörg Ackermann
Apr 19, 2012, 12:34:41 PM4/19/12
to
Hallo,
Rüdiger Gram schrieb am 19.04.2012 17:03:
> an eine vorhandene Tabelle möchte ich per Code ein neues, leeres
> Ja/Nein-Feld anfügen. Seit Stunden würge ich schon daran herum und kriege es
> einfach nicht gebacken.
>
> Kann mir jemand sagen (schreiben), wie man das macht?
currentdb.Execute "ALTER TABLE Tabelle ADD COLUMN Feld BIT"
oder
currentproject.Connection.Execute
"ALTER TABLE Tabelle ADD COLUMN Feld BIT"
(in einer Zeile)
Je nach verwendeter Technik
Gruß
Rüdiger Gram schrieb am 19.04.2012 17:03:
> an eine vorhandene Tabelle möchte ich per Code ein neues, leeres
> Ja/Nein-Feld anfügen. Seit Stunden würge ich schon daran herum und kriege es
> einfach nicht gebacken.
>
> Kann mir jemand sagen (schreiben), wie man das macht?
oder
currentproject.Connection.Execute
"ALTER TABLE Tabelle ADD COLUMN Feld BIT"
(in einer Zeile)
Je nach verwendeter Technik
Gruß
Rüdiger Gram
Apr 19, 2012, 12:49:57 PM4/19/12
to
Jörg Ackermann schrieb:
> currentdb.Execute "ALTER TABLE Tabelle ADD COLUMN Feld BIT"
>
> oder
>
> currentproject.Connection.Execute
> "ALTER TABLE Tabelle ADD COLUMN Feld BIT"
> (in einer Zeile)
>
> Je nach verwendeter Technik
Hilfetexten, noch bei Donkarl gefunden.
In diesem Forum gibt es vermutlich noch mehr Leute, die die Information
schon länger gesucht haben.
Ganz herzlichen Dank
Rüdiger
Henry Habermacher
Apr 19, 2012, 11:04:14 PM4/19/12
to
Hallo Rüdiger
Rüdiger Gram wrote:
> In diesem Forum gibt es vermutlich noch mehr Leute, die die Information
> schon länger gesucht haben.
Kaum, und wenn, dann hätten Sie gefragt. Wieso "kaum": Es ist eine unübliche
Vorgehensweise, die Datenstrukturen während der Laufzeit von Datenbank
Anwendungen zu ändern. Dieses Verhalten ist eher bei Excel üblich, wo
schnell mal eine neue Spalte hinzugefügt und verschoben werden kann. In
Datenbankstrukturen sind solche "Machenschaften" eher verpönt.
Gruss
Henry
Rüdiger Gram wrote:
> In diesem Forum gibt es vermutlich noch mehr Leute, die die Information
> schon länger gesucht haben.
Vorgehensweise, die Datenstrukturen während der Laufzeit von Datenbank
Anwendungen zu ändern. Dieses Verhalten ist eher bei Excel üblich, wo
schnell mal eine neue Spalte hinzugefügt und verschoben werden kann. In
Datenbankstrukturen sind solche "Machenschaften" eher verpönt.
Gruss
Henry
Lars P. Wolschner
Apr 20, 2012, 12:30:24 PM4/20/12
to
"Henry Habermacher" <DontSp...@psp-online.com>:
> Rüdiger Gram wrote:
>> In diesem Forum gibt es vermutlich noch mehr Leute, die die
>> Information schon länger gesucht haben.
>
> Kaum, und wenn, dann hätten Sie gefragt. Wieso "kaum": Es ist
> eine unübliche Vorgehensweise, die Datenstrukturen während der
> Laufzeit von Datenbank Anwendungen zu ändern.
Das stimmt eigentlich nicht, denn eine richtige Datenbankanwendung
muß ja auch mal installiert werden. In diesem Installationsmodus
werden vom Nutzer (der dann oft ein IT-Administrator ist) grund-
legende Informationen abgefragt, wie etwa der Name des
Datenbankservers, Typ und Name der Datenbank sowie Administrator-
Benutzerkennung und -Paßwort der Datenbank. Dann wird die gesamte
benötigte Struktur angelegt und initiale Daten.
> Dieses Verhalten ist eher bei Excel üblich, wo schnell mal eine
> neue Spalte hinzugefügt und verschoben werden kann. In
> Datenbankstrukturen sind solche "Machenschaften" eher verpönt.
Auch der Vergleich ist schief. Wenn die Datenbankanwendung etwa auf
eine neuere Version aktualisiert wird, dürfte sich häufig auch die
Tabellenstruktur im Datenbankserver ndern. Beispielweise werden 1:1-
zu 1:N-Beziehungen oder letztere zu N:M-Beziehungen verfeinert. Das
Erfordernis dieser Transformation muß die neue Version der Anwendung
bei ihrer Installatione erkennen und die Änderungen durchführen,
tunlichst ohne daß der Nutzer dabei Daten verliert.
--
Mit freundlichen Grüßen
Lars P. Wolschner
> Rüdiger Gram wrote:
>> In diesem Forum gibt es vermutlich noch mehr Leute, die die
>> Information schon länger gesucht haben.
>
> Kaum, und wenn, dann hätten Sie gefragt. Wieso "kaum": Es ist
> eine unübliche Vorgehensweise, die Datenstrukturen während der
> Laufzeit von Datenbank Anwendungen zu ändern.
muß ja auch mal installiert werden. In diesem Installationsmodus
werden vom Nutzer (der dann oft ein IT-Administrator ist) grund-
legende Informationen abgefragt, wie etwa der Name des
Datenbankservers, Typ und Name der Datenbank sowie Administrator-
Benutzerkennung und -Paßwort der Datenbank. Dann wird die gesamte
benötigte Struktur angelegt und initiale Daten.
> Dieses Verhalten ist eher bei Excel üblich, wo schnell mal eine
> neue Spalte hinzugefügt und verschoben werden kann. In
> Datenbankstrukturen sind solche "Machenschaften" eher verpönt.
eine neuere Version aktualisiert wird, dürfte sich häufig auch die
Tabellenstruktur im Datenbankserver ndern. Beispielweise werden 1:1-
zu 1:N-Beziehungen oder letztere zu N:M-Beziehungen verfeinert. Das
Erfordernis dieser Transformation muß die neue Version der Anwendung
bei ihrer Installatione erkennen und die Änderungen durchführen,
tunlichst ohne daß der Nutzer dabei Daten verliert.
--
Mit freundlichen Grüßen
Lars P. Wolschner
Claus Maier
Apr 20, 2012, 6:26:52 PM4/20/12
to
Lars P. Wolschner wrote:
> "Henry Habermacher" <DontSp...@psp-online.com>:
>
>> Rüdiger Gram wrote:
>
>>> In diesem Forum gibt es vermutlich noch mehr Leute, die die
>>> Information schon länger gesucht haben.
>>
>> Kaum, und wenn, dann hätten Sie gefragt. Wieso "kaum": Es ist
>> eine unübliche Vorgehensweise, die Datenstrukturen während der
>> Laufzeit von Datenbank Anwendungen zu ändern.
>
> Das stimmt eigentlich nicht, denn eine richtige Datenbankanwendung
> muß ja auch mal installiert werden.
(Ich DB-Dau, aber...)
> "Henry Habermacher" <DontSp...@psp-online.com>:
>
>> Rüdiger Gram wrote:
>
>>> In diesem Forum gibt es vermutlich noch mehr Leute, die die
>>> Information schon länger gesucht haben.
>>
>> Kaum, und wenn, dann hätten Sie gefragt. Wieso "kaum": Es ist
>> eine unübliche Vorgehensweise, die Datenstrukturen während der
>> Laufzeit von Datenbank Anwendungen zu ändern.
>
> Das stimmt eigentlich nicht, denn eine richtige Datenbankanwendung
> muß ja auch mal installiert werden.
Vielleicht hast Du etwas mißverstanden?
Es geht hier ja nicht um die Installation einer DB, sondern um
Manipulation an der Struktur einer bereits installierten DB während
sie in Betrieb ist...
Ich kann mir vorstellen, daß sowas nicht gerade "gut" ist.
mfg
Claus
Siegfried Schmidt
Apr 21, 2012, 4:51:13 AM4/21/12
to
Claus Maier schrieb:
> Ich kann mir vorstellen, daß sowas nicht gerade "gut" ist.
Was sollte denn am nachträglichen Anfügen eines Ja/Nein-Feldes an einer
Tabelle ungut sein?
Siegfried
> Ich kann mir vorstellen, daß sowas nicht gerade "gut" ist.
Tabelle ungut sein?
Siegfried
Rainer Georg Blankenagel
Apr 21, 2012, 8:01:08 AM4/21/12
to
Lars P. Wolschner <"Lars P. Wolschner" <lars.wo...@nexgo.de>>:
> Wenn die Datenbankanwendung etwa auf
> eine neuere Version aktualisiert wird, dürfte sich häufig auch die
> Tabellenstruktur im Datenbankserver ndern. Beispielweise werden 1:1-
> zu 1:N-Beziehungen oder letztere zu N:M-Beziehungen verfeinert. Das
> Erfordernis dieser Transformation muß die neue Version der Anwendung
> bei ihrer Installatione erkennen und die Änderungen durchführen,
> tunlichst ohne daß der Nutzer dabei Daten verliert.
Das scheint mir jetzt weniger ein üblicher Fall zu sein als vielmehr ein
Beispiel für, äh, suboptimale Planung in den ersten Phasen der
Datenbankentwicklung.
Rainer
> Wenn die Datenbankanwendung etwa auf
> eine neuere Version aktualisiert wird, dürfte sich häufig auch die
> Tabellenstruktur im Datenbankserver ndern. Beispielweise werden 1:1-
> zu 1:N-Beziehungen oder letztere zu N:M-Beziehungen verfeinert. Das
> Erfordernis dieser Transformation muß die neue Version der Anwendung
> bei ihrer Installatione erkennen und die Änderungen durchführen,
> tunlichst ohne daß der Nutzer dabei Daten verliert.
Beispiel für, äh, suboptimale Planung in den ersten Phasen der
Datenbankentwicklung.
Rainer
Lars P. Wolschner
Apr 21, 2012, 1:42:23 PM4/21/12
to
Rainer Georg Blankenagel <fr...@leganeknalb.de>:
Du meinst, eine gute Datenbankentwicklung sieht jegliche
Fortentwicklung der fachlichen Seite unfehlbar vorher? Das scheint
mir kein realistischerweise erreichbares Ziel zu sein. Die von mir
genannten Verfeinerungen *können*, aber *müssen* keineswegs die Folge
unzulänglichen Datenbankdesigns sein.
Fortentwicklung der fachlichen Seite unfehlbar vorher? Das scheint
mir kein realistischerweise erreichbares Ziel zu sein. Die von mir
genannten Verfeinerungen *können*, aber *müssen* keineswegs die Folge
unzulänglichen Datenbankdesigns sein.
Rainer Georg Blankenagel
May 8, 2012, 3:32:43 PM5/8/12
to
Wenn sich aber, wie von Dir als Beispiel angeführt, die Tabellenstruktur
ändert, dann haben sich in der durch die Datenbank abgebildeten
Wirklichkeit nicht nur Kleinigkeiten geändert. Nach meiner (zugegeben
subjektiven) Erfahrung ist das einfach nicht so häufig, wie Du das oben
postulierst. Und wenn "Beziehungen verfeinert" werden müssen, dann sind sie
vorher nicht korrekt erkannt worden - das meinte ich mit 'suboptimaler
Planung'. Kann ja passieren, aber als Normalfall sollte das wohl zumindest
für selbst erstellte Datenbankanwendungen nicht gelten.
Ja, ich weiß, ich rede von einer idealen Welt. In der Realität geht gern
auch mal was schief.
Rainer
0 new messages