[Erledigt] Datenbank erstellen mit CREATE DATABASE

[charlytango]

Hi

Soweit mir bekannt ist, kann man sich weder mit SQLDB noch mit ZEOS mit einer Datenbank verbinden ohne einen Datenbanknamen anzugeben.

Der möglichen Komplexität des Anlegens einer Datenbank in einem SQL Server bin ich mir bewusst. Sollte die Aufgabenstellung derart komplex sein, ist es mit einem einfachen CREATE DATABASE ohnehin nicht getan.

Aber das Connection-Objekt selbst hat bei beiden Varianten die Fähigkeit ein ExecSQL abzusetzen, dessen Existenz sich mir nicht erschließt wernn ich dann doch wieder eine DB brauche um mit dem SQL-Server zu connecten. Denn TSQLQuery/TZQuery haben ja auch ein ExecSQL und ein Open (wobei mir auch hier klar ist wozu)

Bei SQLite ist das einfach, da übernimmter die Treiberschicht das Erstellen einer nicht existierenden Datenbank. (was dann ja eine Datei ist)

Ich wollte nur nochmal nachfragen ob das so ist wie ich recherchiert habe bevor ich mich da in etwas verrenne.

Nochmal die Frage: Kann man sich mit ZEOS/SQLDB mit einem Server verbinden um eine ggfs nicht existierende Datenbank anzulegen und sich danach mit dieser verbinden.

[Joh]

Also: ich habe es mir recht einfach gemacht:

Ein Formular mit
- IBConnection (Firebird)
- SQLTransaction
- SQLQuery (zum Einfügen/bearbeiten der Daten)
- ein paar Buttons, weil ich (größere Mengen) Daten übernehmen mußte und es dabei zu Fehlern kam
- Indizes erst nachher, weil die Daten inkonsistent waren

In IBConnection steht bereits der DatabaseName hart kodiert...

Code: Alles auswählen

procedure TForm1.btnCreateDBClick(Sender: TObject);
begin
  with IBConnection do
  begin
    DatabaseName := 'blabla.fdb';
    if FileExists(DatabaseName) then
      DeleteFile(DatabaseName);
    UserName := 'sysdba';
    Password := 'masterkey';
    try
      IBConnection.CreateDB;
      writeln('Datenbank erstellen beendet!');
    except MessageDlg('Die Erzeugung der Datenbank war nicht erfolgreich!',mtError,[mbOK],0);
    end;
  end;
end;

Code: Alles auswählen

procedure TForm1.btnCreateTableClick(Sender: TObject);
begin
  with IBConnection do
  begin
    Open;
    if not Connected then
      MessageDlg('hmm, Das Öffnen der Datenbank war nicht erfolgreich!',mtError,[mbOK],0)
    else
    begin

      Transaction.StartTransaction;
      ExecuteDirect('CREATE TABLE Artikel ('
      + 'id             int generated by default as identity primary key,'
      + 'LieferantID    int,'
      + 'Bez            varchar(80),'
      + 'Aktualisierung date,'
      + 'VBF            varchar(6),'
      + 'Flammpunkt     varchar(20),'
      + 'Siedepunkt     varchar(20),'
      + 'UnterEx        varchar(20),'
      + 'OberEx         varchar(20),'
      + 'Code           varchar(100))');
      Transaction.Commit;
      Transaction.EndTransaction;

      Transaction.StartTransaction;
      ExecuteDirect('CREATE TABLE ArtikelBU ('
      + 'id             int primary key,'
      + 'BFP            int,'
      + 'SG             int,'
      + 'EP             int)');
      Transaction.Commit;
      Transaction.EndTransaction;

      writeln('Tabellen erstellen beendet!');
    end;
    Close;
  end;
end;

Edit: hmm, irgendwie mag das Forum gerade keine Anhänge...; Anhang gelöscht

[Sieben]

In der Tat sind die Methoden CreateDB (und DropDB) virtual Methods von TSQLConnection und werden in den DB-spezifischen Ableitungen jeweils 'überritten'. DatabaseName muss dabei jeweils schon gesetzt sein, genau so, wie Joh es gezeigt hat. Für SQLDB lautet die Antwort also 'ja'. Für ZEOS vermutlich auch.

[Zvoni]

SQLite aussen vor (wie schon erwähnt: DB-Name setzen, und falls nicht existiert, wird sie angelegt):
Für Server-basierte DB (mySQL/Maria/PostGres/MSSQL) gibt's nen "Trick", wie man das "Ein DB-Name muss angegeben werden" aushebelt:
Man gibt den Namen eines Schemas (!!) an, welches definitiv auf dem Server existiert.
Und bei Server-basierten Datenbanken gibt es immer mindestens ein Schema, welches definitiv existiert
Bei MySQL/Maria ist es z.b. "mysql", weil da z.b. die ganze User-Verwaltung gehandhabt wird, und die existiert definitiv, weil es mindestens den user "root" geben muss
auf MSSQL wäre es z.b. "master"
für PostGres heisst es "postgres"

google mal nach "mysql [bzw. DB deiner Wahl] default database"

Anbei mal der erste Treffer für o.g. Suche für MSSQL
https://dataedo.com/kb/databases/sql-se ... es-schemas

EDIT: Ich beziehe mich jetzt explizit auf dein "CREATE DATABASE" aus dem Betreff, welches entsprechende DBA-Rechte fordert.
Also Vorsicht, falls mit anderen User-Logins gearbeitet wird.
Dann kann ggfs. auf "INFORMATION_SCHEMA" ausgewichen werden (sofern vorhanden).

Heisst (Bsp. jetzt MySQL - absoluter Aircode)

Code: Alles auswählen

Var
  MySQLCon:TMySQL80Connection;
//............... Create Connection
  MySQLCon.Database:='mysql';
  MySQLCon.Username:='root';
  MySQLCon.Password:='rootpassword';
//.... Noch Transaction, Hostnamen und Port setzen...blablabla
  MySQLCon.Open;    
  MySQLCon.ExecSQL('CREATE DATABASE MeineDB';);
//CREATE TABLE usw....  
  MyTransaction.Commit;
//....anderes Zeuch
  MySQLCon.Close;
  MySQLCon.Database:='MeineDB';
  MySQLCon.UserName:='CharlyTango';
// anderes Zeuch setzen
  MySQLCon.Open;
  

[Socke]

Nochmal die Frage: Kann man sich mit ZEOS/SQLDB mit einem Server verbinden um eine ggfs nicht existierende Datenbank anzulegen und sich danach mit dieser verbinden.

Das hängt nicht an ZEOS oder SQLDB sondern an der Datenbank-Software, mit der du arbeiten willst. Jede Datenbank implementiert da andere Wege.
Wie meine Vorredner/-schereiber schon geschrieben haben, gibt es häufig eine "Standard"-Datenbank, die bei der Installation automatisch angelegt wird und für solche Sachen verwendet wird.

Mir sind schon verschiedene Wege über den Weg gelaufen:

• Standard-/Management-Datenbank per SQL (MySQL/MariaDB, MSSQL, Postgres, SAP HANA, Oracle ...)
• Temporär gestartete Utility-Datenbank (Sybase/SAP IQ)
• Kommondozeilenprogramm (SAP MaxDB)
• REST API oder Webanwendung (Cloud-Datenbanken diverser Anbieter)

[charlytango]

Danke für die ausführlichen Antworten.

Hab schon befürchtet dass man irgendwie "ums Eck" arbeiten muss.
Auch für meine umfangreicheres DB-Anbindungsobjekt zahlt es sich nicht aus, das direkt einzubauen, besonders weil einem dann DB-Rechte in die Quere kommen.
Da soll es so bleiben wie es ist und dann soll eben die DB zuerst im Server angelegt werden. Und für SQLite ist das ohnehin implizit.
Für Interbase brauche ich dann eben jmd der mir das testet, denn irgendwie scheine ich bei Interbase allergische Reaktionen zu bekommen

Case closed.

[af0815]

Hab schon befürchtet dass man irgendwie "ums Eck" arbeiten muss.
Auch für meine umfangreicheres DB-Anbindungsobjekt zahlt es sich nicht aus, das direkt einzubauen, besonders weil einem dann DB-Rechte in die Quere kommen.

Jede große DB-Firma braucht ihr "Alleinstellungsmerkmal" auf das aufgebaut wird. Nachdem ja nur eine kleine Untermenge des SQL und allen Befehlen die ein SQL-Server - nein besser gesagt - Datenbank-Server versteht, normiert wurde, ist es kein Wunder das es da jede Menge an Unterschieden gibt.

Wenn man universell bleiben will/muss, so kann man nur einen kleinen Ausschnitt der Möglichkeiten der Server nutzen. Und da wird es oft sehr eng. DIe Firmen tun schon ihr möglichstes. Und dann kommt noch die Treiberschicht hinzu, die teilweise die Möglichkeiten noch weiter einschränkt. Beispiel die FreeTDS Treiber für MS-SQL Server, die gerade im Bereich Stored Proceduren die Möglichkeiten sehr stark einschränken. Noch dazu einige "its per Design" Sachen in SqlDB (automatische Transaktionsmanagment das IMHO keine wirklich verlässigen Automatismen hat).