Neue Tabelle erstellen und öffnen

[Thomas F]

Ich wollte eine neue Tabelle in meiner Datenbank erstellen und dann sofort öffnen(enthält noch keine Daten)
Dazu folgender Code
Man gibt in ein Edit1 den Namen der Tabelle ein und auf Button1click wird die Tabelle (Tabelle2) erstellt,
während bereits eine Tabelle (Tabelle1) geöffnet ist
Allerdings bekomme ich danach immer eine Fehlermeldung, dass die Tabelle nicht existiert.
Wenn ich danach in das Verzeichnis der Tabellen schaue (Combobox1) ,dann existiert die neue Tabelle und ich kann die Tabelle2 auch ohne Fehlermeldung öffnen.

Delphi-Quellcode:

procedure TForm5.Button1Click(Sender: TObject);
var Tabellenname:string;
begin

if Edit1.text <> '' then
begin
  Tabellenname:= Edit1.Text;
unit1.form1.adoconnection1.ConnectionString:=Unit1.form1.ADOTable1.ConnectionString;
unit1.form1.ADOConnection1.Execute('CREATE TABLE '+Tabellenname+' (Nr COUNTER NOT NULL PRIMARY KEY,Feld1 varchar(60),Feld2 varchar(60),Feld3 varchar(5),Datum DATE,Feld5 varchar(40))');
 Unit1.form1.adotable1.Close;
unit1.Form1.ADOTable1.TableName:=tabellenname;
 Unit1.form1.adotable1.open;
close;
 end;

end;

[Bernhard Geyer]

Schließe mal die Connection nach dem Erzeugen. Access hat ein teilweise bescheuertes Cachingverhalten welches sowas verursachen könnte.

[Thomas F]

Zitat:

Zitat von Bernhard Geyer

Schließe mal die Connection nach dem Erzeugen. Access hat ein teilweise bescheuertes Cachingverhalten welches sowas verursachen könnte.

geht leider auch nicht, ich habs probiert

Delphi-Quellcode:

procedure TForm5.Button1Click(Sender: TObject); 
var Tabellenname:string; 
begin 

if Edit1.text <> '' then 
begin 
  Tabellenname:= Edit1.Text; 
unit1.form1.adoconnection1.ConnectionString:=Unit1.form1.ADOTable1.ConnectionString; 
unit1.form1.ADOConnection1.Execute('CREATE TABLE '+Tabellenname+' (Nr COUNTER NOT NULL PRIMARY KEY,Feld1 varchar(60),Feld2 varchar(60),Feld3 varchar(5),Datum DATE,Feld5 varchar(40))'); 
  unit1.form1.ADOConnection1.Close; //<----------
Unit1.form1.adotable1.Close; 
unit1.Form1.ADOTable1.TableName:=tabellenname; 
unit1.form1.ADOConnection1.open;
Unit1.form1.adotable1.open; 
close; 
end; 

end;

[/delphi]

[blawen]

Hast Du Dir den erzeugten SQL-Befehl mal ausgeben lassen und hast Du ihn mit einem ext. DB-Tool überprüft?

Ev. musst Du den Tabellennamen in "" einklammern?

[Thomas F]

Seltsam, ich hab nur zum Testen einen 2.Button hinzugefügt, und öffne die neue Tabelle mit Buttonclick
Dann gehts
Offenbar ist die Tabelle noch nicht erstellt, wenn sie geöffnet wird :shock:

Delphi-Quellcode:

procedure TForm5.Button1Click(Sender: TObject); 
var Tabellenname:string; 
begin 

if Edit1.text <> '' then 
begin 
  Tabellenname:= Edit1.Text; 
unit1.form1.adoconnection1.ConnectionString:=Unit1.form1.ADOTable1.ConnectionString; 
unit1.form1.ADOConnection1.Execute('CREATE TABLE '+Tabellenname+' (Nr COUNTER NOT NULL PRIMARY KEY,Feld1 varchar(60),Feld2 varchar(60),Feld3 varchar(5),Datum DATE,Feld5 varchar(40))'); 
Unit1.form1.adotable1.Close; 
unit1.Form1.ADOTable1.TableName:=tabellenname; 

close; 
end; 

end;


procedure TForm1.Button2Click(Sender: TObject);//2.Button
begin

 adotable1.open;  //funktioniert
end;

[globetrotter77]

Dein ADOTable bezieht sich vermutlich auch auf Form5 und nicht auf Form1.
Zumindest bei den Buttons ist das offenbar so, sonst würde es nicht
---> procedure TForm5.Button1Click(Sender: TObject);
heißen
Die Referenzierung mit "unit1.form1." mal rausnehmen, dann müsste sich alles auf das aktuelle Formular beziehen.

[Thomas F]

Zitat:

Zitat von globetrotter77

Dein ADOTable bezieht sich vermutlich auch auf Form5 und nicht auf Form1.
Zumindest bei den Buttons ist das offenbar so, sonst würde es nicht
---> procedure TForm5.Button1Click(Sender: TObject);
heißen
Die Referenzierung mit "unit1.form1." mal rausnehmen, dann müsste sich alles auf das aktuelle Formular beziehen.

ADO und die DBGird befindet sich auf dem Form1, von dort klickt man auf "Neue Tabelle" , dann öffnet sich Form5,
wo man in das Edit1 den Tabellennamen eingibt, und mit Button1.click die Tabelle erstellt.
Problem ist, dass die Tabelle noch nicht erstellt ist, wenn sie geöffnet wird.
Dann kommt die Fehlermeldung.

[globetrotter77]

und wie findet dann Button2 die passende Tabelle???

Delphi-Quellcode:

procedure TForm5.Button2Click(Sender: TObject);//2.Button
begin

adotable1.open;  //funktioniert
end;

[Thomas F]

Zitat:

Zitat von globetrotter77

und wie findet dann Button2 die passende Tabelle???

Delphi-Quellcode:

procedure TForm5.Button2Click(Sender: TObject);//2.Button
begin

adotable1.open;  //funktioniert
end;

Ja, da hab ich einen Fehler gemacht, es muß TForm1.Button2Click heissen.

Delphi-Quellcode:

procedure TForm1.Button2Click(Sender: TObject);//2.Button
begin

adotable1.open;  //funktioniert
end;

[nahpets]

Hallo,

falls das Problem noch nicht weg sein sollte, versuche mal bitte folgendes:

Delphi-Quellcode:

  unit1.form1.ADOConnection1.Close; //<---------- 
Unit1.form1.adotable1.Close; 
ShowMessage('****');
unit1.Form1.ADOTable1.TableName:=tabellenname; 
unit1.form1.ADOConnection1.open; 
Unit1.form1.adotable1.open;

Dadurch wird eine mehr oder weniger von Dir beeinflussbare Pause eingebaut. Wenn es damit funktioniert, bist Du im Programmablauf zu schnell und "überholst" quasi die Datenbank. Um das Problem zu lösen könntest Du anstelle von ShowMessage ein Sleep(1000) einbauen. Den Wert 1000 musst Du eventuell anpassen. Eine "brutalere" Möglichkeit könnte in etwa so aussehen:

Delphi-Quellcode:

var
      i : Integer;
...
  Unit1.form1.adotable1.Close; 
  unit1.Form1.ADOTable1.TableName:=tabellenname; 
  unit1.form1.ADOConnection1.open; 
  i := 0;
  repeat
    inc(i);
    Try
      Unit1.form1.adotable1.open; 
    Except
    End;
  until Unit1.form1.adotable1.Active or (i >= 3); // maximal drei Versuche starten
  if Not Unit1.form1.adotable1.Active then begin
    // Behandlung der Situation, dass die Tabelle nach dem 3. Versuch nicht zu öffnen ist.
    ShowMessage('Die Tabelle ' + tabellenname + ' konnte nicht geöffnet werden.');
  end;

Über die "Eleganz" dieser Lösung wollen wir uns lieber nicht unterhalten :wink:

[Thomas F]

Hallo Stephan,

es ist tatsächlich so dass der Programmablauf zu schnell ist, und die Tabelle noch gar nicht fertig erstellt ist,
bevor sie auf gerufen wird.
Mit Sleep (2000) funktioniert es,ich hab es mit sleep(1000) probiert,
ist aber zu wenig

Delphi-Quellcode:

unit1.Form1.ADOConnection1.Close;
 Unit1.form1.adotable1.Close;
 unit1.Form1.ADOTable1.TableName:=tabellenname;
 Sleep(2000)  ;
 unit1.form1.ADOConnection1.open;
 Unit1.form1.adotable1.open;

[HaJo]

Nun muß ich Thomas F mal fragen, was das denn soll :-)

In der Regel hat man beim Programmieren von Datenbankanwendungen ein Gerüst der Datenbank schon erstellt, um das herum man seine Anwendung baut.

Sollte es dann doch einmal nötig werden, aus dem Programmablauf eine neue Tabelle zu erstellen, wird diese in der Regel auch mit Daten gefüllt und mit einem Post oder Commit abgeschlossen.
Diese Daten sind dann auch vorhanden!

Ein solches vorgehen sehe ich lediglich bei Exportfunktionen für andere Anwendungen.

Denn:
Aus dem laufenden Programm erzeugten Tabellen, läßt sich aus dem laufenden Programm nun mal kein kein zusätzlicher Quelltext zuordnen, der das arbeiten mit solchen Tabellen intelligent im Programm verewigt.

Was soll das ganze also?

[Thomas F]

Man kann aus dem Programm heraus eine neue Tabelle öffnen, sodass man mehrere Tabellen in der Datenbank hat,
die Felder der Tabellen sind vorgegeben, und können nicht verändert werden.
Man könnte natürlich auch die vorhandene Tabelle löschen, und die anfallenden Daten neu eintragen.

[nahpets]

Hallo,

Zitat:

Zitat von HaJo

Nun muß ich Thomas F mal fragen, was das denn soll :-)

In der Regel hat man beim Programmieren von Datenbankanwendungen ein Gerüst der Datenbank schon erstellt, um das herum man seine Anwendung baut.

Sollte es dann doch einmal nötig werden, aus dem Programmablauf eine neue Tabelle zu erstellen, wird diese in der Regel auch mit Daten gefüllt und mit einem Post oder Commit abgeschlossen.
Diese Daten sind dann auch vorhanden!

Ein solches vorgehen sehe ich lediglich bei Exportfunktionen für andere Anwendungen.

Denn:
Aus dem laufenden Programm erzeugten Tabellen, läßt sich aus dem laufenden Programm nun mal kein kein zusätzlicher Quelltext zuordnen, der das arbeiten mit solchen Tabellen intelligent im Programm verewigt.

Was soll das ganze also?

das sehe ich anders.
Für meinen Administrationsjob muss ich aus diversen Systemen Daten sammeln und auswerten. Für die Protokolle des Mailservers gibt es je Tag eine Tabelle, die zur Laufzeit erstellt wird. Der Zugriff erfolgt über Namenskonventionen. Eine einzige Tabelle wäre mir hier zu schnell zu groß. Beim Befüllen der "Tages-Tabellen" werden andere Tabellen mit "Statistikinformationen" gefüllt. Die "Tages-Tabellen" werden sporadisch (nach Zeitablauf) gelöscht. Natürlich könnte man dazu eine Tabelle nehmen und dort zeitabhängig Teilmengen löschen, die Laufzeit der Befüllung und das Löschen der nicht (mehr) benötigten Daten (Drop Table) ist bei der von mir gewählten Verfahrensweise aber deutlich kürzer, als bei einer großen Tabelle.
Ähnlich verfahre ich bei der Auswertung der Ereignislogs der Server. Jeder Server hat "seine" Tabellen. Zugriff erfolgt über eine View. Wenn ein Server wegfällt, lösche ich dessen Tabellen und passe die View an. Tabellen für neue Server werden automatisch erstellt, hier muss ich nur die View anpassen (kommt sehr selten vor). Bisher ist diese Vorgehensweise extrem wartungsarm. (Und wenn ich mal Langeweile habe, bau ich mir noch 'ne Routine, die die View automatisch anpasst. :wink:)

[HaJo]

ich hab ja Ausnahmen eingeräumt.

Wollte nur zum Ausdruck bringen, das man in der Regel beim programmieren ein Data-Objekt hat, das bestimmte Bearbeitungs-Proceduren und Funktionen enthält, die sich nur sehr schwer vom laufenden Programm her weiterschreiben lassen :-)

[globetrotter77]

Zitat:

Zitat von HaJo

Denn:
Aus dem laufenden Programm erzeugten Tabellen, läßt sich aus dem laufenden Programm nun mal kein kein zusätzlicher Quelltext zuordnen, der das arbeiten mit solchen Tabellen intelligent im Programm verewigt.

Was soll das ganze also?

Das gibt es sogar sehr häufig!
Gerade in größeren Systemen ist es z.B. immer wieder mal erforderlich, aus dem laufenden Programm heraus temporäre Schnappschüsse eines ganz genau definierten Ausschnitts der Daten zu erstellen, mit denen dann die eigentliche (in der Regel sehr aufwendige) Bearbeitung erfolgen kann, ohne dass sich andere aktive Benutzer einmischen.
Ein völlig normaler Vorgang!

[HaJo]

Gegen Export-Funktionen sage ich ja nichts. Aber das was Thomas F hier als Problem hinstellt, ist eigentlich keines.

Schreibt man Daten in die Tabelle und die Umgebung ist ok, sollten nach dem abschließendem Close oder Post auch die Daten in der Tabelle stehen!

Aber gerade in Access mal so eben einen fünfzeiler hier als Problem zu schildern ist an der Realität vorbei gedacht :-)
Oder anders gesagt - kein sittlicher Nährwert...

[globetrotter77]

@HaJo:

natürlich ist das ein Problem ... zumindest für ihn!
für mich auch nicht unbedingt, aber es gibt eben auch ab und zu mal Fragen, die auf nem anderen Niveau trotzdem Riesenprobleme aufwerfen ... ist einfach so!

und wenn jemand so ein aus seiner Sicht riesiges Problem hat, muss man sich entscheiden ... entweder, man liest drüber hinweg oder man gibt nen Tipp oder eine Erklärung, aber bitte auf passendem Niveau.
Und manchmal kann bereits eine ganz banale Lösungsmöglichkeit sehr viel zum besseren Verständnis beitragen, auch wenn sie nicht unbedingt perfekt ist, sondern eben mit kleinen Schrittchen daherkommt.

Es hilft aber meistens in keiner Weise weiter, wenn man hört, welch übergroße Probleme in der ach so rauhen Wirklichkeit tatsächlich noch auf einen warten!

[HaJo]

@globetrotter77:

Danke für die Ohrfeige auf hohem Niveau - ab ja schon zugegeben das ich Schüler oder eben Anfänger gar nicht auf der Rechnung hatte.

Also nach dem Motto verfahren, es gibt keine dummen Fragen, sondern nur dumme Antworten?

Ich weiß nicht so recht. Auch beim Autofahren gibt es Grundregeln und Strategien die man in der Ausbildung übt damit sie später jedem bekannt sind. Ist diese Prüfung dann geschafft, beginnt das lernen und verfestigen dieser Regeln.

Umgekehrte Vorgehensweise halte ich für nicht sonderlich geschickt. Seh es mir nach

[globetrotter77]

Zitat:

Zitat von HaJo

Danke für die Ohrfeige auf hohem Niveau

gern geschehen! ... :wink:

Zitat:

Auch beim Autofahren gibt es Grundregeln und Strategien die man in der Ausbildung übt damit sie später jedem bekannt sind. Ist diese Prüfung dann geschafft, beginnt das lernen und verfestigen dieser Regeln.

Da hast du natürlich recht, aber irgendwann beginnt man eben doch etwas dilettantisch, und dann muss der Fahrlehrer auch mal ins Steuer greifen! Und danach auch notfalls nochmal erklären, was er schon 20 x gesagt hatte.

Zitat:

Umgekehrte Vorgehensweise halte ich für nicht sonderlich geschickt. Seh es mir nach

Da gebe ich dir ja auch recht, und wenn hier jemand kommt und meint, er bekommt gleich eine fertige Lösung, ohne selber nachgedacht haben zu müssen, dann ist ihm nicht zu helfen ...
auch dann nicht, wenn's für die Schule ist ... schließlich sollte man dort auch zuerst die vier Grundrechnungsarten kennen, bevor man einen Taschenrechner mit den abenteuerlichsten Lösungsversuchen traktiert.
Aber dumme Fragen sind, denke ich, schon mal erlaubt ... und dumme Fehler auch ... die habe ich selber auch schon zur Genüge gemacht ... ist doch völlig normal!

PS: Bin selbst ja noch nicht lange dabei in diesem Forum und von daher sicher nicht immer der geeignete Kommentator für alles, aber mein persönlicher Eindruck ist bisher durchaus positiv ...
und ich habe das Gefühl, dass auch vom Niveau her eben alles dabei ist, was so denkbar ist ... für jeden etwas eben ... und dann passt's doch, oder nicht?

[HaJo]

Du als Typ, Du passt ja auch, bist schon ok :-)

Vielleicht hab ich ja auch, als ich gestern nach langer Zeit nochmal hier war, einfach das falsche gelesen.
Vielleicht liegt es auch daran, das ich das Wissen um das Betriebssystem und das programmieren nicht von einander trennen kann. Bin eben programmierender Admin.

Dazu noch das Wissen um die krummen Machenschaften großer Konzerne (Beispiele gibt es auch hier), da kann man schon mal sehr kritisch werden.

Sehe es mir bitte nach und nix für Ungut.

Und nu ab in die Heia :-)

Lieben Gruß zu Dir

[globetrotter77]

Zitat:

Zitat von HaJo

Du als Typ, Du passt ja auch, bist schon ok :-)

Danke!

Zitat:

Vielleicht hab ich ja auch, als ich gestern nach langer Zeit nochmal hier war, einfach das falsche gelesen.

Das kann passieren, das habe ich in der kurzen Zeit auch schon festgestellt!

Zitat:

Vielleicht liegt es auch daran, das ich das Wissen um das Betriebssystem und das programmieren nicht von einander trennen kann. Bin eben programmierender Admin.

Klar, da denkt man anders ... ich bin auch schon seit geraumer Zeit programmierenderweise unterwegs, und nicht nur mit Delphi, auch nicht nur auf dem PC ... da sieht man vieles naturgemäß anders

Zitat:

Sehe es mir bitte nach und nix für Ungut.

kein Problem!

Zitat:

Und nu ab in die Heia :-)

Lieben Gruß zu Dir

Sleep(8*3600);
wäre jetzt nicht schlecht, geht aber leider nicht! :roll: