7
MS Access SQL Tabelle hinzufügen ohne GUI zu nutzen
Guten Morgen liebe Gemeinde!
Da immer wieder kommende MDB geändert werden müssen, kann dies praktisch in ein SQL eingebaut werden.
Folgendes:
Es soll eine Tabelle mit einer weiteren Spalte ergänzt werden.
[funktioniert]
Jetzt möchte ich aber noch festlegen, dass der Standartwert "Jetzt()" ist.
[Syntaxfehler in ALTER TABLE-Anweisung]
Falls dies in Access nur über die GUI möglich ist, schade!
Nachtrag:
in Postgres SQL geht es so
Euer
Midi
Quellen:
http://www.teialehrbuch.de/Kostenlose-Kurse/SQL/14689-ALTER-TABLE.html
http://sqlzoo.net/de/howto/source/z.dir/i02create.xml
Da immer wieder kommende MDB geändert werden müssen, kann dies praktisch in ein SQL eingebaut werden.
Folgendes:
Es soll eine Tabelle mit einer weiteren Spalte ergänzt werden.
ALTER TABLE WKZZStandort ADD DateOfBirth2 date
Jetzt möchte ich aber noch festlegen, dass der Standartwert "Jetzt()" ist.
ALTER TABLE WKZZStandort ADD DateOfBirth2 date DEFAULT now();
Falls dies in Access nur über die GUI möglich ist, schade!
Nachtrag:
in Postgres SQL geht es so
test timestamp without time zone DEFAULT now(),
Euer
Midi
Quellen:
http://www.teialehrbuch.de/Kostenlose-Kurse/SQL/14689-ALTER-TABLE.html
http://sqlzoo.net/de/howto/source/z.dir/i02create.xml
Auf Facebook teilen
Auf Twitter teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 192659
Url: https://administrator.de/forum/ms-access-sql-tabelle-hinzufuegen-ohne-gui-zu-nutzen-192659.html
Ausgedruckt am: 22.12.2024 um 10:12 Uhr
7 Kommentare
Neuester Kommentar
Moin.
Ich gehe Mal davon aus, dass Du das ganze in VBA machen willst.
HTH
MK
Ich gehe Mal davon aus, dass Du das ganze in VBA machen willst.
Dim db As Database
Dim SQL As String
Set db = CurrentDb
SQL = "ALTER TABLE WKZZStandort ADD DateOfBirth2 date"
db.Execute SQL, dbSeeChanges
db.TableDefs("WKZZStandort").Fields("DateOfBirth2").Properties("DefaultValue") = "Now()"
db.CloseHTH
MK
Hallo,
ich weiß nicht, welchen SQL-Dialekt Access spricht. Aber bei T-SQL (MS) heißt es "GETDATE()" und nicht "NOW()".
Gruß
Filipp
ich weiß nicht, welchen SQL-Dialekt Access spricht. Aber bei T-SQL (MS) heißt es "GETDATE()" und nicht "NOW()".
[Syntaxfehler in ALTER TABLE-Anweisung]
Das Posten von vollständigen Fehlermeldungen kann hilfreich sein...Gruß
Filipp
Moin Midivrus, thaenhusen und filippg
die Frage lässt sich am besten ausgehend von Filipps Frage beantworten.
In Access ist nach wie vor die Engine von den Konzepten und eben auch von den Grenzen des DAO-Modells (Data Access Objects) bestimmt. Was "früher" bei Access-MDBs Standard war, DAO hiess und bei Access 2000/2002 für tot erklärt wurde, nennt sich jetzt seit Access 2007 "Access Database Engine Object Library (Dateiname: ACEDAO.DLL)" und ist das olle DAO-Konzept.
Die eigentlich geeignete Architektur wäre wohl ADO (ActiveX Data Objects), kommt aber bei M$ nicht aus dem Quark (grottige Performance, abgespeckter Sprachumfang und vor allem bei Katalog/Datenbank-Verwaltungsfunktionen so gut wie nicht vorhanden). ADO ist zwar als Modell eher auf einer Linie, die besonders bei DDLs näher an der Mimik eines Standard-SQL-Sprachumfangs liegt.... soweit die gute Nachricht.
Von der Implementierung her allerdings ist alles, was Tabellen bzw Datenobjekte created oder altered nicht in DAO und nicht in ADO vollständig implementiert, sondern in einer Zusatzbibliothek (ADOX).
Bedeutet unterm Strich ganz banal:
-> nicht etwa das "now()" ist das Problem, sonder ganz einfach das unbekannte Schlüsselwort "DEFAULT".
DEFAULT wird weder bei einem CREATE TABLE noch einem ALTER TABLE außerhalb der Access-Klicks-Zsamma-Oberfläche unterstützt.
Also auch nicht bei Zugriffen von aussen - egal ob über ODBC, JBDC, DAO- oder ADO-Objekte, über VBA oder VBS.
Der einzige Weg (um nicht workaround zu schreiben) ist die von thaenhusen gezeigte Lösung.
Grüße
Biber
die Frage lässt sich am besten ausgehend von Filipps Frage beantworten.
Zitat von @filippg:
ich weiß nicht, welchen SQL-Dialekt Access spricht.
Aber bei T-SQL (MS) heißt es "GETDATE()" und nicht "NOW()".
Access spricht nach wie vor kein ANSI-SQL, nicht mal im Sinne von SQL-92 (und inzwischen ist SQL-2012 abgenickt).ich weiß nicht, welchen SQL-Dialekt Access spricht.
Aber bei T-SQL (MS) heißt es "GETDATE()" und nicht "NOW()".
In Access ist nach wie vor die Engine von den Konzepten und eben auch von den Grenzen des DAO-Modells (Data Access Objects) bestimmt. Was "früher" bei Access-MDBs Standard war, DAO hiess und bei Access 2000/2002 für tot erklärt wurde, nennt sich jetzt seit Access 2007 "Access Database Engine Object Library (Dateiname: ACEDAO.DLL)" und ist das olle DAO-Konzept.
Die eigentlich geeignete Architektur wäre wohl ADO (ActiveX Data Objects), kommt aber bei M$ nicht aus dem Quark (grottige Performance, abgespeckter Sprachumfang und vor allem bei Katalog/Datenbank-Verwaltungsfunktionen so gut wie nicht vorhanden). ADO ist zwar als Modell eher auf einer Linie, die besonders bei DDLs näher an der Mimik eines Standard-SQL-Sprachumfangs liegt.... soweit die gute Nachricht.
Von der Implementierung her allerdings ist alles, was Tabellen bzw Datenobjekte created oder altered nicht in DAO und nicht in ADO vollständig implementiert, sondern in einer Zusatzbibliothek (ADOX).
Bedeutet unterm Strich ganz banal:
[Syntaxfehler in ALTER TABLE-Anweisung]
bei einem ALTER TABLE add whatever date DEFAULT now()-> nicht etwa das "now()" ist das Problem, sonder ganz einfach das unbekannte Schlüsselwort "DEFAULT".
DEFAULT wird weder bei einem CREATE TABLE noch einem ALTER TABLE außerhalb der Access-Klicks-Zsamma-Oberfläche unterstützt.
Also auch nicht bei Zugriffen von aussen - egal ob über ODBC, JBDC, DAO- oder ADO-Objekte, über VBA oder VBS.
Der einzige Weg (um nicht workaround zu schreiben) ist die von thaenhusen gezeigte Lösung.
Grüße
Biber
Grüßt euch,
die Mailbenachrichtigungen sind von GMX als SPAM deklariert worden
[Lob in die Richtigung]!
Prinzipiell machen wollte ich es mit PHP!
@@filippg:
@@Biber: besten Dank!
Wenn ich richtig interpretiert habe, komme ich um den letzten Schritt nicht herum, die Standardwerte manuell zuhinterlegen?
angenehmen Resttag,
Midi
die Mailbenachrichtigungen sind von GMX als SPAM deklariert worden
[Lob in die Richtigung]!
Prinzipiell machen wollte ich es mit PHP!
@@filippg:
Das Posten von vollständigen Fehlermeldungen kann hilfreich sein...
Access gibt halt coolerweise nur immer diese Meldung!!!@@Biber: besten Dank!
db.TableDefs("WKZZStandort").Fields("DateOfBirth2").Properties("DefaultValue") = "Now()"
Wenn ich richtig interpretiert habe, komme ich um den letzten Schritt nicht herum, die Standardwerte manuell zuhinterlegen?
angenehmen Resttag,
Midi
Moin Midivirus,
ich war nicht sicher, ob deine Nachfrage eine rhetorische war.
Da aber nun Tage später kein "Hinreichend beantwortet"-Marker am Beitrag klebt, bestätige ich gerne nochmals die Richtigkeit deiner Interpretation.
Anmerkung 1)
Eine programmierte Lösung über PHP kannst du aus den genannten Gründen knicken. Du bekommst zwar problemlos eine Connection zur Access-Datenbank hin. Aber mit der kannst du nur Access-SQL sprechen. Und das kennt kein
Wenn thaenhusen ganz (über-)korrekt gewesen wäre, dann hätte er statt seiner Variablendeklaration geschrieben:
-> dann wäre vielleicht deutlicher geworden, dass hier "Properties" eines hierachischen Objekt-Modells geändert werden - nicht etwa über ein SQL-UPDATE Katalogfelder einer Tabellenbeschreibung. Hat Access nicht. Deshalb kannst du auch im ACCESS-SQL keine Abfrage "Liste mir alle Tabellen im Schema" oder "Liste mir alle Felder in Table xy" machen.
Anmerkung 2)
Um es nochmals ganz deutlich zu sagen: Access war nie ein strategisches M$-Produkt und wird es nie werden dürfen. Die Redmonder möchten, dass alles, was in Richtung wartbare, halbprofessionelle, mehrbenutzerfähige Datenbank geht auf einem SQL-Server läuft. Deshalb bekommt auch jeder Privatanwender einen SQL-Server für lau und bei Marketingaktionen noch einen vollgetankten Rasenmäher dazu.
Eine Access-Applikation macht auch unter Performance-Gesichtspunkten nur Sinn, wenn die Appz-Logik in VBA zusammengeschrotet wird. Denn nur DAO-Zugriff via VBA ("Direct DAO") hat das Privileg, den selben Adressraum benutzen zu dürfen wie die Anwendung "Access". Das darf weder ADO.Net noch ODBC noch JDBC noch alle anderen. Zusammengefasst als zwei Einzelaussagen:
- alle Zugriffe außer Direct DAO müssen wesentlich mehr Disk I/O und ein paar Abstraktionsebenen mehr in Kauf nehmen
- und alle anderen haben zusätzlich einen künstlich eingeschränkten SQL-Sprachumfang.
Noch kürzer zusammengefasst: Access-Datenbanken sind Insellösungen.
Und im Zuge der globalen Klimaerwärmung sind viele Inseln dem Untergang geweiht.
Grüße
Biber
ich war nicht sicher, ob deine Nachfrage eine rhetorische war.
Da aber nun Tage später kein "Hinreichend beantwortet"-Marker am Beitrag klebt, bestätige ich gerne nochmals die Richtigkeit deiner Interpretation.
Anmerkung 1)
Eine programmierte Lösung über PHP kannst du aus den genannten Gründen knicken. Du bekommst zwar problemlos eine Connection zur Access-Datenbank hin. Aber mit der kannst du nur Access-SQL sprechen. Und das kennt kein
ALTER TABLE add/alter COLUMN DEFAULT .... Das können nur die Objekt-Modelle (wie DAO) mit ihren DLLs und ihren TableDef-Objekten.Wenn thaenhusen ganz (über-)korrekt gewesen wäre, dann hätte er statt seiner Variablendeklaration geschrieben:
Dim db As DAO.Database
Dim tdf As DAO.TableDef
Dim fld As DAO.Field
...Anmerkung 2)
Um es nochmals ganz deutlich zu sagen: Access war nie ein strategisches M$-Produkt und wird es nie werden dürfen. Die Redmonder möchten, dass alles, was in Richtung wartbare, halbprofessionelle, mehrbenutzerfähige Datenbank geht auf einem SQL-Server läuft. Deshalb bekommt auch jeder Privatanwender einen SQL-Server für lau und bei Marketingaktionen noch einen vollgetankten Rasenmäher dazu.
Eine Access-Applikation macht auch unter Performance-Gesichtspunkten nur Sinn, wenn die Appz-Logik in VBA zusammengeschrotet wird. Denn nur DAO-Zugriff via VBA ("Direct DAO") hat das Privileg, den selben Adressraum benutzen zu dürfen wie die Anwendung "Access". Das darf weder ADO.Net noch ODBC noch JDBC noch alle anderen. Zusammengefasst als zwei Einzelaussagen:
- alle Zugriffe außer Direct DAO müssen wesentlich mehr Disk I/O und ein paar Abstraktionsebenen mehr in Kauf nehmen
- und alle anderen haben zusätzlich einen künstlich eingeschränkten SQL-Sprachumfang.
Noch kürzer zusammengefasst: Access-Datenbanken sind Insellösungen.
Und im Zuge der globalen Klimaerwärmung sind viele Inseln dem Untergang geweiht.
Grüße
Biber
@@Biber:
Das Lob war an GMX gerichtet, die die Benachrichtigungen neuerdings als SPAM einstufen. (...)
Für mich reicht die Aussage
Für mich ist diese Frage an dieser Stelle dann erl.!
Vielen lieben Dank für eure Mühen und wieder herrlich,
qualifizierte Antworten zulesen, Dank DAFÜR.
Das Lob war an GMX gerichtet, die die Benachrichtigungen neuerdings als SPAM einstufen. (...)
Für mich reicht die Aussage
Eine programmierte Lösung über PHP kannst du aus den genannten Gründen knicken.
Für mich ist diese Frage an dieser Stelle dann erl.!
Vielen lieben Dank für eure Mühen und wieder herrlich,
qualifizierte Antworten zulesen, Dank DAFÜR.
Midi<
Quelle: http://www.shotdev.com/php/php-adodb/php-adodb-get-table-properties/
Damit hab ich mein Ziel erreicht:
-Beitrag und Problem gelöst-
<html>
<head>
<title>ShotDev.Com Tutorial</title>
</head>
<body>
<?php
$strConn = new COM("ADODB.Connection") or die("Cannot start ADO");
$strConn->Open("DRIVER={Microsoft Access Driver (*.mdb)}; DBQ=" . realpath("db/mydatabase.mdb"));
$strSQL = "SELECT * FROM customer";
$objRec = $strConn->Execute($strSQL);
$intNumFields = $objRec->Fields->Count();
echo ("<b>Table customer have ".$intNumFields." Fields.</b><br>");
for ($i=0; $i < $intNumFields; $i++) {
echo $objRec->Fields($i)->Name."<br>";
}
$objRec->Close();
$strConn->Close();
$objRec = null;
$strConn = null;
?>
</body>
</html> Damit hab ich mein Ziel erreicht:
Prüfung ob die Spalte schon vorhanden ist, wenn nein, anlegen
-Beitrag und Problem gelöst-
