Hi, keine Ahnung, ist bestimmt ganz simpel, zumindest so simpel, dass ich nirgends etwas geeignetes mit den Suchbegriffen
"python access microsoft tabelle schreiben" in allerlei Kombinationen finden.
Ich möchte nichts weiter, als
- eine Access- DB öffnen (idealerweise OHNE Fernsteuerung und ODBC direkt auf Dateiebene, aber das wäre auch nicht so wichtig)
- eine Zeile einfügen
- Datenbank schließen
db = OpenAccessDB("C:\\MeineDatei.accdb")
datensatz = db.table['Tabelle1'].Insert()
for each field in datensatz.fields:
if field.type == 'int':
field.value = 10
if field.type == 'str':
field.value = 'test'
datensatz.commit()
db.save_and_close()
Also ich habe diese Suchbegriffe verwendet und komme dann über den dritten Link zum ersten Stackoverflow-Beitrag, der direkt auf eine zuvor beantwortete Frage und somit fast direkt auf die erste gegebene Antwort verweist, über welche man zur Google-Code-Seite kommt, auf der man dann den Link zur Github-Seite des Projekts findet. Von dort ist es nur noch *ein* Klick zum Wiki, in welchem man Code-Beispiele zur Genüge findet...
Der wichtigste Satz steht aber auf der Hauptseite:
pyodbc makes it easy to connect to databases using ODBC. It implements the DB API 2.0 specification, but adds even more convenience.
Das besagt, dass dieser Treiber das DB API 2.0 unterstützt. Damit lässt sich der Code genauso schreiben, wie man es u.a. in der offiziellen Doku zum SQLite-Modul findet. Voila, man braucht also keine Magie - und vor allem keine *gesonderten* Beispiele für den Schreibzugriff.
Ich hoffe, das hilft Dir weiter und regt Dich an, demnächst weniger "spezifisch" zu suchen (denn wo allgemein der Zugriff auf eine DB gezeigt wird, dürfte man auch etwas über das "schreiben" finden )
Da hast Du sicher recht, aber da mein Ziel ja wahr, das möglichst auf Dateiebene zu lösen, ging es nicht ohne.
Aber was solls, dann Plan B - ODBC, geht letztlich auch.
Das hast Du ja nicht spezifiziert! Du schriebst ja lediglich "idealerweise" - das ist ja kein Ausschluss...
Grundsätzlich würde ich persönlich Access niemals benutzen, wenn ich nicht dazu gezwungen bin (harte externe Anforderungen). Wenn Du es Dir aussuchen kannst, nutze besser ein anderes RDBMS!
Für mich ist access auch keine DB. Im Regelfall arbeite ich seit Jahren mit Oracle, aber es gibt einige Situationen, in denen für mich Access das Mittel der Wahl ist:
- wenn man mit dbase- Dateien hantieren muss (muss ich öfter)
- wenn man Daten "im Block" jemandem zur Verfügung stellen muss und er damit weiterarbeiten soll/will/muss
- wenn man relativ schnell und transportabel eine Handvoll dummer Daten auswerten will, ohne große Verweildauer/Datenlebensdauer/weitere Nutzer
- wenn man eine überschaubare Menge Code mitliefern muss
Mein aktuelles Ziel ist, Ordnung in meine tausend mal irgendwie schnell auf allerlei Wechselplatten und USB- Sticks gesicherten Bilder zu bringen. Und da will ich einfach alle Bilddateien "hashen" und samt Vorkommen, Größe und Namen (irgendwann, wenn es mich noch mal packt, dann auch mit Datum, Kameradaten etc.) in eine DB schreiben, die ich dann leicht auswerten kann. Da mit Access über ODBC u.ä. zu aufwändig ist und ich mir dann auch noch was für linux einfallen lassen müsste (native schreiben wäre ja egal), habe ich mich für sqlite entschieden. Das Sammeln geht damit auch. Wenn dann alle Daten drin sind, kann ich es von da immer noch leicht nach Access übertragen und damit rumspielen.
Im Moment hat er knapp 200.000 Bilddateien gesammelt, da sind mit Sicherheit schon wenigstens die Hälfte Duplikate. Nun ja, das große Jagen und Sammeln geht weiter.
@NoPy: Für xBase (verschiedene dBase- und Foxpro-Varianten) gibt es Module für Python. Dieses Dateiformat ist auch heute noch Teil von anderen Formaten/”Dateisammlungen” weil es so verdammt einfach ist und sich zu DOS-Zeiten wohl jeder zweite Programmierer mal selbst Routinen für das Format geschrieben hat.
Für die drei weiteren Spiegelstriche/Punkte würde ich auch zu SQLite raten. Das ist frei verfügbar, multiplatform, mittlerweile ziemlich verbreitet, und kann mit SQL angesprochen werden (oder mit einem ORM wie SQLAlchemy).
Ist schon klar, aber SQLite muss installiert werden, Access ist es. Um eine dBase- Datei ins Access zu bekommen, kann der normalo- Nutzer selbst Hand anlegen, bei SQLite nicht. Wenn er irgend eine Abfrage über die Daten machen will, dann kann er das mit clickibunti tun, in SQLite benötigt er SQL- Kenntnisse. Wenn ich ihm noch etwas Software mit auf den weg geben will in Form eines Formulars und ein paar VBA- Späßchen, dann ist das in der selben Datei und funktioniert - wenn er es geschafft hat, der Quelle zu vertrauen - ohne weiteres Zutun.
Ganz ehrlich, Access als Datenbank ist nicht viel wert, das SQL kommt aus dem Tritt, sobald man etwas komplizierteres fordert. Lesen kann man es sowieso nicht mehr, wenn die GUI das alles wieder in eine Zeile gekracht hat.
Aber was die GUI für einen Datencontainer betrifft, ist Access (leider) unerreicht.
Der Zugriff auf Access ist eben in reinem Python nicht so dolle. Wenn es denn unbedingt Access ein muss, dann böte sich ggf. IronPython an, so dass man die ADO.NET-Komponenten zur Kommunikation nutzen kann. Allerdings fällt eben SQLAlchemy-Support weg - das wäre für mich - ähnlich wie BlackJack es sieht - ein KO-Kriterium.
Ganz ehrlich: Wenn Du doch die Wahl hast, rede Dir doch Access nicht schön. Willst Du Dir ehrlich in Python das Leben schwerer machen, nur wegen "marginaler" Probleme wie zusätzlicher Tools o.ä.? :K
Je nach Anwendungsfall könnte für Dich auch eine Dokumenten zentrierte DB wie CouchDB interessant sein - insbesondere dann, wenn die Daten heterogen sind.
Aber mein Leben besteht ja nicht nur aus python, genaugenommen besteht es nur zu einem sehr kleinen Teil aus python. In meiner Arbeitswelt habe ich zu 70-90% mit Oracle und zugehörigem (PL)SQL zu tun, der Rest ist Excel, Access, Word und ab und an muss/darf ich mal was programmieren, was ich entweder mit python tue (wenn es sich beispielsweise um Scripte handelt oder ich entsprechende Schnittstellen der FME oder von QGIS basteln muss/darf) oder mit Lazarus/FreePascal mache (wenn ich eine Oberfläche brauche und ich den meine Quellen auch in einem Jahr noch verstehen muss), manchmal sogar mit VBA, wenn es darum geht, jemandem ein Rundum- Sorglos- Paket in Form einer "intelligenten" Excel- oder Access- Datei zu liefern.
Privat bin ich dabei, python für mich zu erschließen, zum Einen, weil es das Scripten erleichtert, zum Anderen, weil ich neugierig bin, ob ich noch irgendwann mal lerne, auch mit dieser Sprache effizient umzugehen. Darüberhinaus benutze ich auch hier Lazarus und - da ich im Moment versuche, mit Unity vertraut zu werden - c# (java finde ich hier weniger angenehm und mit python/boo habe ich es noch nicht versucht. Ich würde die Zusammenhänge gern begreifen und das macht sich natürlich erst einmal leichter, wenn man festen Boden unter den Füßen hat. Ich habe nun mal Jahrzehnte damit verbracht, zur Designzeit typisierte Sprachen zu benutzen (Pascal, Modula2, C++ ...), mein Erfahrungsschatz ist da schlicht größer.
Daher: Es mag sein, dass der python- Zugang zu Access nicht so doll ist, von Lazarus aus ist es auch nicht besser. Aber dennoch: Wenn ich relationale Daten habe und diese schnell mal in alle möglichen Richtungen auswerten will, vielleicht sogar mal als Bericht oder in einem lustigen kleinen Formular, dann ist für mich Access das Mittel der Wahl. ZUmindest auf Windows- Rechnern (die mir zur Verfügung stehen) kann ich die Datei ohne irgendeine Installation benutzen, weniger versierte Anwender ihre Daten selbst auswerten lassen und für richtig ungeschickte Kandidaten ein Frontend bauen, das sofort aufgeht, wenn der die EINE Datei öffnet. Tut mir leid, aber DAS kann im Moment kein anderes System, leider. Es ist mir auch noch nicht wirklich gelungen, mit python eine EXE zu bauen, die ich weitergeben kann. (nicht, dass ich es nicht versucht hätte. Die exe lief bei mir auch, aber als ich sie dann meinem Chef übergab, ging da nix. Was auch immer ich falsch gemacht habe.) Notfalls kann man mit Access sogar mehrere Nutzer Daten pflegen lassen, aber das würde ich wirklich nur unter massivem Zwang tun und wenn es wirklich nicht darauf an kommt.
Ich bin kein python- Jünger und werde auch keiner werden. So wie ich auch kein Lazarus/Delphi- Jünger bin, auch wenn ich beides für sehr gute Einsteiger- Systeme halte. Ich benutze das Werkzeug, dass mir für den Zweck am geeignetsten erscheint oder vorgegeben ist. Ich würde notfalls sogar ABAP benutzen, aber glücklicherweise scheint dieser Kelch an mir vorbeizugehen.
)
