Office: (Office 2010) rst.close bringt eine Fehlermeldung

Hallo,

die Zeile rst.Close bringt beim ausführen folgende Fehlermeldung:
"Laufzeitfehler '3704': Der Vorgang ist für ein geschlossenes Objekt nicht zugelassen."
Warum kann ich rst.Open machen, aber dann kein Close?

Code:

Gruß

:)

 

Hast Du Dir Deine SQL-Anweisung angeschaut? Das ist DDL, und damit lässt sich nun nicht ein Recordset (von Daten?) öffnen.

 

Es wird eine Tabelle erzeugt durch das rst.Open.
Ist dann kein rst.Close nötig?

Sorry, ich bin Anfänger, kannst Du es bitte einfacher formulieren?

 

Hallo,
zu was muss man in einer DB eine Tabelle per VBA anlegen ?

 

Code:

Mit der gleichen Berechtigung, mit der bei einem Import neue Tabellen angelegt werden, kann man auch selber welche erstellen.

 

Hallo,
Ich würde trotzdem mal gern die Begründung wissen.
Es war ja auch eine Frage an den TE.

 

\@gpswanderer:
Unterschiedliche Themengebiete (hier Sprachen, z.B. Englisch, Französisch) möchte ich in jeweils eigene Tabellen speichern, die vom Aufbau her gleich sind. Mit dem Anlegen einer neuen Sprache brauche ich dann nicht die Tabellen von Hand erstellen, sondern das System macht es für mich.

@ebs17:
Ist der Code die bessere Alternative zu rst?
Code:

Wo werden dann - wenn Datensätze ausgelesen werden - diese gespeichert?

Gruß

 

Diese ganz gewiss nicht.

Man dürfte sich die Frage beantworten lassen, wozu zur Laufzeit eine neue Tabelle benötigt wird? Ist die Frage zur Zufriedenheit beantwortet, wäre es nun nicht gerade toll, wenn man zum Tabellenerstellen VBA-Prozeduren unterbricht und im Handbetrieb agiert.

An sich ist das Vermögen, eine Tabelle per Data Definition Language erstellen zu können, als hilfreich einzuschätzen.

Als Gründe, die für eine neue Tabelle sprechen, fallen mir ein:
- Strukturpflege eines Backends per Script
- Zwischenspeicherung von Ergebnissen zur Erhöhung der Gesamtperformance, vorzugsweise dann in einem zusätzlichen temporären Backend

@amibobo: Wo bitte kommen Datensätze her, wenn Du gerade eine neue (leere) Tabelle erstellst?

 

Hallo,
dachte ich es mir doch. Das Vorhaben ist wenig geeignet. Wer in einer Datenbank regelmäßig mit dieser oder ähnlichen Begründung neue Tabellen benötigt hat ein falsches Datenmodell.
Alle Daten gehören in eine Tabelle mit einem Kennzeichen (Fremdschlüssel) für die Sprache. Das ist eine Grundregel relationaler Datenbanken.

Du solltest das Vorhaben gründlich überdenken und Dich mal mit den Normalisierungsregeln beschäftigen.

 

Code:

Im konkreten Fall werden diese dann manuell eingegeben.
Klar kann man dann die Tabellen vorher auch manuell erstellen, aber es geht ja auch ums lernen und da finde ich u.a. das automatische erstellen von Tabellen interessant.

 

\@Eberhard,
Du warst zu schnell mit Deiner Antwort, ich hatte meinen Beitrag noch geändert.

Meine Forumserfahrung (nicht meine Access Erfahrung) zeigt mir, dass diese Frage meist berechtigt ist, so auch hier. Ich glaube, da sind wir uns einig.

 

Code:

Vielleicht kann ich auch hier noch was lernen, aber ich habe mir bereits Gedanken gemacht:
Es gibt eine Tabelle, wo die Vokabeln der jeweiligen Sprache gespeichert werden:
ID | Vokabel
In einer weiteren Tabelle werden die Verknüpfungen zwischen zwei Sprachen hergestellt über zwei Fremdschlüssel:
FK_Deutsch | FK_Englisch
Damit kann ich dann auch mehrere Bedeutungen eines Wortes in der anderen Sprache in der Tabelle handhaben.
Wieder in einer weiteren Tabelle sollen die Synonyme einer Sprache gespeichert werden:
FK_Deutsch | FK_Deutsch_Synonym
Diese Tabellen benötigt man bei jeder Sprache, und die Verknüpfung zwischen zwei Sprachen sogar noch öfter. Also gewisse Ersparnis an manuellem Erstellen ist gegeben.

Für Verbesserungsvorschläge bin ich offen und dankbar.

 

Hallo,

und da hast tatsächlich Du für jede Sprache eine Tabelle ?

In den Feldnamen darf die Sprache nicht vorkommen. Daher bin ich ziemlich sicher, das das Datenmodell so falsch ist.

Nach meiner Auffassung benötigst Du folgende Tabellen:

- Vokabeln
- Sprachen
- Zuordnung Vokabel zu Sprache

In die 3 Tabelle kommt eine Feld für die Übersetzung und ein Feld für das Synonym. Weiterhin ein Fremdschlüsselfeld zur Sprache und zur Vokabel.

Damit kannst Du alles erschlagen, beliebig viele Vokabeln mit beliebig vielen Übersetzungen in beliebig vielen Sprachen.
Ohne an den Tabelle je was erweitern ändern zu müssen. Oder gar eine neue Tabelle erstellen zu müssen.
l
Beschreibe bitte mal die jetzigen Tabellen genauer, falls ich das nicht richtig verstanden habe.

 

Nun, wie gesagt: Tabellen (und auch Indizes, Beziehungen u.a.) per DDL/DAO/ADODB erstellen zu können und für welche Situationen/Strukturen man das einsetzt: Das sind ganz verschiedene Schuhe.

Und: Das Erstellen einer m:n-Beziehung per Code ist dann wieder nicht regelmäßig (=> Strukturpflege), aber ordentlich ambitioniert, wenn es dann auch vollständig erfolgt.

Eine schöne Zusammenstellung dazu: Strukturänderungen an der Datenbank

 

Die Tabellenstrukturen sind so gedacht:

Es gibt pro Sprache eine Tabelle mit
ID | Vokabel
So hat jede Vokabel jeder Sprache eine eindeutige ID.

Um nun Beziehungen herzustellen, gibt es weitere Tabellen:
FK_Deutsch | FK_Englisch
Die Benennung habe ich fürs Verständnis gewählt. Man kann auch FK1 und FK2 verwenden und die Tabelle tbl_DeutschEnglisch nennen.
Für andere Sprachen benötige ich die selbes Struktur. Dann gibt es z.B. eine weitere Tabelle tbl_EnglischFranzoesisch und tbl_DeutschFranzoesisch.

Ist damit das Datenmodell wieder richtig oder gibt es auch hier Fehler?