Ein kleines Beispiel für ODBC am Beispiel von MS Access.

Code-Stücke können hier veröffentlicht werden.
Benutzeravatar
jens
Moderator
Beiträge: 8461
Registriert: Dienstag 10. August 2004, 09:40
Wohnort: duisburg
Kontaktdaten:

Freitag 18. November 2005, 16:37

Also hier hab ich gesehen, das es wohl mit "PASSWORD=" gehen soll. Bei tut's das aber nicht :(

Code: Alles auswählen

import dbi, odbc

dbconf = {
    "dbHost"            : '.\SQLEXPRESS',
    "dbDatabaseName"    : 'DatabaseName',
    "dbUserName"        : 'UserName',
    "dbPassword"        : 'Password',
    "dbTablePrefix"     : 'lucid_',
}

DSN_info = (
    "DRIVER={SQL Server};SERVER={%s};"
    "UID=%s;PASSWORD=%s;DATABASE=%s"
) % (
	dbconf["dbHost"],
	dbconf["dbUserName"],
	dbconf["dbPassword"],
	dbconf["dbDatabaseName"]
)
print DSN_info

c = odbc.odbc(DSN_info)
Ausgabe:
DRIVER={SQL Server};SERVER={.\SQLEXPRESS};UID=UserName;PASSWORD=Password;DATABASE=DatabaseName
Traceback (most recent call last):
File "test.py", line 22, in ?
c = odbc.odbc(DSN_info)
dbi.operation-error: [Microsoft][ODBC SQL Server Driver][SQL Server]Login failed for user 'UserName'. in LOGIN

CMS in Python: http://www.pylucid.org
GitHub | Open HUB | Xing | Linked in
Bitcoins to: 1JEgSQepxGjdprNedC9tXQWLpS424AL8cd
Benutzeravatar
gerold
Python-Forum Veteran
Beiträge: 5555
Registriert: Samstag 28. Februar 2004, 22:04
Wohnort: Oberhofen im Inntal (Tirol)
Kontaktdaten:

Freitag 18. November 2005, 17:20

jens hat geschrieben:

Code: Alles auswählen

import dbi, odbc
Hi Jens!

Ich sehe gerade, dass du das wirklich verwenden möchtest. In deinem Interesse --> tu es nicht. Die ODBC-Implementierung von pyWin32 ist sche.... :x

Versuche lieber zuerst mit pyMssql eine Verbindung aufzubauen und damit zu arbeiten. Ich weiß leider nicht, ob pyMssql auch mit dem neuen SQL-Server funktioniert, ich arbeite mit dem MsSQL-Server 2000 und mit der MSDE 2000.

Glaube mir, ich habe alles durchprobiert was irgendwie eine Verbindung zum MS-SQLServer aufbauen und lizenzfrei verwendet werden kann. Nur pyMssql macht so gut wie keine Probleme. Das Einzige Problem, das bis jetzt aufgetaucht ist --> ich kann kein Euro-Zeichen aus einem Datenfeld auslesen oder schreiben. Das wird ständig durch einen Unterstrich "_" ersetzt.
Aber das ist mit den Problemen, die ich mit anderen Schnittstellen hatte nicht annähernd vergleichbar.

Z.B. kannst du mit der pyWin32-ODBC-Implementierung nichts in eine Tabelle schreiben, wenn diese keinen Primärschlüssel hat. Oder du bekommst keine Rückmeldung bei manchen Fehlern usw. Ich glaube, dass man damit auch keine "Gespeicherte Prozeduren" mit Rückgabewerten aufrufen kann. -- Sicher bin ich mir aber nicht mehr.

Bei anderen Schnittstellen gab es Umlautprobleme und ständig Abstürze. Manche reagieren einfach nicht mehr, wenn der Server mal kurz nicht erreichbar ist -- so etwas wie ein Timeout schien es nicht zu geben. Usw.

Wie bereits geschrieben -- der einzige Fehler, den ich bei pyMssql gefunden habe ist der mit dem Euro-Zeichen.

Es gibt auch noch die Möglichkeit, mit ADO über den Umweg "win32com.client.Dispatch", auf die Datenbank zuzugreifen. Wenn du also unbedingt mal ein Euro-Zeichen brauchst, dann würde ich es auf die schnelle mal über diesem Weg versuchen. Die Nachteile dieser Schnittstelle sind, das an ADO angelehnte Handling und die Performance, da es ja über Client-Dispatch geleitet wird.

Vorsicht! Verwende die Windows-Version von pyMsSql, die du bei Sourceforge herunterladen kannst, nicht die von Leonidas. Ich habe vor ein paar Tagen gemerkt, dass es einen Unterschied bei "fetchone()" gibt.

http://pymssql.sourceforge.net/

@Leonidas: Du liest eh mit, oder?

lg
Gerold
:-)
http://halvar.at | Kleiner Bascom AVR Kurs
Wissen hat eine wunderbare Eigenschaft: Es verdoppelt sich, wenn man es teilt.
Leonidas
Administrator
Beiträge: 16024
Registriert: Freitag 20. Juni 2003, 16:30
Kontaktdaten:

Freitag 18. November 2005, 18:03

gerold hat geschrieben:Vorsicht! Verwende die Windows-Version von pyMsSql, die du bei Sourceforge herunterladen kannst, nicht die von Leonidas. Ich habe vor ein paar Tagen gemerkt, dass es einen Unterschied bei "fetchone()" gibt.

http://pymssql.sourceforge.net/

@Leonidas: Du liest eh mit, oder?
Ja, ich habe es mir angewöhnt, die meisten Threads zu lesen.

Die Version auf Sourceforge hat schon die Versionsnummer 0.7.3, wohingegen mein Binary nur 0.6.0 ist, da wundert mich der Unterschied bei fetchall() überhaupt nicht. Aber da es ja ein Python 2.4 Binary davon gibt, werde ich es nicht nochmal selbst kompilieren: es ist nämlich zu grauenhaft.
My god, it's full of CARs! | Leonidasvoice vs Modvoice
Benutzeravatar
jens
Moderator
Beiträge: 8461
Registriert: Dienstag 10. August 2004, 09:40
Wohnort: duisburg
Kontaktdaten:

Samstag 19. November 2005, 20:43

@gerold: Danke für deinen Tip! Dann werde ich mir mal pyMssql anschauen ;)
EDIT: Du meinst wohl http://www.python-forum.de/viewtopic.php?t=2903 ;)

Aber ist es evtl. nicht nur das €-Zeichen, sondern generell Probleme mit Umlaute/Sonderzeichen ???

EDIT:
So, hab es nun mal installiert, aber der import schlägt schon fehl :(
In pymssql.py wird ein import _mssql gemacht, Dabei tritt der Fehler auf:
ImportError: DLL load failed: Das angegebene Modul wurde nicht gefunden.
Wenn ich es mal lokal mache, erscheint eine Windows-Fehler-box, indem auf eine fehlende "ntwdblib.dll" hingewiesen wird :( In der Tat, hab ich auf dem ganzen System keine Datei mit dem Namen!

EDIT2:
In der FAQ steht's ja:
A: Yes, ntwdblib.dll is absolutely necessary to operate with MS SQL Server. This library is a part of MS SQL Client Tools, which can be installed from MS SQL Server installation media. I cannot provide the library because of its licence restrictions.
Zuletzt geändert von jens am Donnerstag 24. November 2005, 12:26, insgesamt 1-mal geändert.

CMS in Python: http://www.pylucid.org
GitHub | Open HUB | Xing | Linked in
Bitcoins to: 1JEgSQepxGjdprNedC9tXQWLpS424AL8cd
Benutzeravatar
jens
Moderator
Beiträge: 8461
Registriert: Dienstag 10. August 2004, 09:40
Wohnort: duisburg
Kontaktdaten:

Dienstag 22. November 2005, 18:12

OK, also ich hab mir die Datei beschafft. Und zwar hab ich die v2000.080.2039.00 aus dem ServicePack 4 für den SQL Server 2000... Ist somit eigentlich nicht für den SQL Server 2005... Aber ein Versuch war es wert...

Aber leider funktioniert es nicht:

Code: Alles auswählen

Traceback (most recent call last):
  File "test.py", line 6, in ?
    c = dbapi.connect('.\SQLEXPRESS', 'UserName', 'Password')
  File "C:\Python24\Lib\site-packages\pymssql.py", line 309, in connect
    con = _mssql.connect(dbhost, dbuser, dbpasswd)
_mssql.error: Could not connect to MS SQL Server
Nun weiß ich nicht, ob es an der Version der DLL Datei liegt, die nicht mit dem Server funktioniert, oder ob ich evtl. an anderer Stelle einen Fehler gemacht hab...


Naja, aber es gibt ja auch noch adodbapi... Das teste ich morgen mal... Ist wahrscheinlich nicht viel mehr als die PyWin32 Geschichte...
Hat jemand damit Erfahrung gesammelt? gerold?

CMS in Python: http://www.pylucid.org
GitHub | Open HUB | Xing | Linked in
Bitcoins to: 1JEgSQepxGjdprNedC9tXQWLpS424AL8cd
Benutzeravatar
gerold
Python-Forum Veteran
Beiträge: 5555
Registriert: Samstag 28. Februar 2004, 22:04
Wohnort: Oberhofen im Inntal (Tirol)
Kontaktdaten:

Dienstag 22. November 2005, 20:34

jens hat geschrieben: Aber leider funktioniert es nicht:
[...]
Hat jemand damit Erfahrung gesammelt?
Hi Jens!

Es sieht wohl so aus, als ob du einer der ersten bist, die von Python aus auf den 2005'er zugreifen möchten. Leider kann ich dich dabei nicht unterstützen. --> Seit Visual Studio .NET versuche ich von MS-Produkten los zu kommen. Es wird sich also wahrscheinlich nie ein 2005'er SQL-Server auf einen meiner Computer verirren.

Hier ein Auszug aus einem alten Skript, das noch mit ODBC auf den SQL-Server 2000 zugegriffen hat.

Code: Alles auswählen

connstr = \
    "DRIVER=SQL Server;"\
    "SERVER=%s;"\
    "DATABASE=%s;"\
    "UID=%s;"\
    "PWD=%s" % (sw3host, sw3database, sw3username, sw3password)

try:
    conn = odbc.odbc(connstr)
except:
    message = u"Fehler: Beim Öffnen der Globaldatenbank"
    write_message(message)
    return False
Für einfache Sachen ist ODBC immer noch besser als nichts.

lg
Gerold
:-)
http://halvar.at | Kleiner Bascom AVR Kurs
Wissen hat eine wunderbare Eigenschaft: Es verdoppelt sich, wenn man es teilt.
Benutzeravatar
jens
Moderator
Beiträge: 8461
Registriert: Dienstag 10. August 2004, 09:40
Wohnort: duisburg
Kontaktdaten:

Mittwoch 23. November 2005, 16:55

Naja, es ist nich so, das ich jetzt unbedinngt den 2005'er nutzten will. Aber das ist die einzige kostenlose Variante von M$ :?

Also da muß ich nochmal ein wenig probieren...

EDIT1:
Also hab im Python Cookbook eine Anleitung gefunden mit dem Kommandozeilen Programm osql eine Verbindung aufzubauen. Ich denke das kann man nicht wirklich produktiv nutzten, aber zumindest kann ich damit nachschauen, ob eine Verbindung mit dem User und dem Passwort generell klappt:

Code: Alles auswählen

#!/usr/bin/python
# -*- coding: UTF-8 -*-

import os, dbi, odbc

dbconf = {
    "dbHost"            : '.\SQLEXPRESS',
    "dbDatabaseName"    : 'DatabaseName',
    "dbUserName"        : 'UserName',
    "dbPassword"        : 'Password',
}

# http://aspn.activestate.com/ASPN/Cookbook/Python/Recipe/144183
osql_test = (
    "osql -S%s -d%s -U%s -P%s "
    """/w 8192 -Q"set nocount on select name from master..syslogins where name = 'sa'"""
) % (
    dbconf["dbHost"],
    dbconf["dbDatabaseName"],
    dbconf["dbUserName"],
    dbconf["dbPassword"],
)
print osql_test
lst = os.popen(osql_test).readlines()
try:
    if lst[2].strip() == 'sa':
        print "connection OK"
    else:
        print "connection failed!"
except IndexError:
    print "Could not connect"

print "-"*80

DSN_info = (
    "DRIVER=SQL Server;"
    "SERVER=%s;"
    "DATABASE=%s;"
    "UID=%s;"
    "PASSWORD=%s;"
) % (
    dbconf["dbHost"],
    dbconf["dbDatabaseName"],
    dbconf["dbUserName"],
    dbconf["dbPassword"],
)
print DSN_info
c = odbc.odbc(DSN_info)
Ausgaben:
osql -S.\SQLEXPRESS -dDatabaseName -UUserName -PPassword /w 8192 -Q"set nocount on select name from master..syslogins where name = 'sa'
connection OK
--------------------------------------------------------------------------------
DRIVER=SQL Server;SERVER=.\SQLEXPRESS;DATABASE=DatabaseName;UID=UserName;PASSWORD=Password;
Traceback (most recent call last):
File "MSSQL mini test.py", line 47, in ?
c = odbc.odbc(DSN_info)
dbi.operation-error: [Microsoft][ODBC SQL Server Driver][SQL Server]Login failed for user 'UserName'. in LOGIN
Wie man sehen kann klappt eine connection eigentlich schon. Aber per odbc geht's einfach nicht... Leider sehe ich in den LOG-Dateien auch nicht mehr Informationen, warum das so ist :twisted:

CMS in Python: http://www.pylucid.org
GitHub | Open HUB | Xing | Linked in
Bitcoins to: 1JEgSQepxGjdprNedC9tXQWLpS424AL8cd
Benutzeravatar
jens
Moderator
Beiträge: 8461
Registriert: Dienstag 10. August 2004, 09:40
Wohnort: duisburg
Kontaktdaten:

Mittwoch 23. November 2005, 18:05

Ach guck mal einer an, über adodbapi geht's :shock:
Obwohl das auch nur conn=win32com.client.Dispatch('ADODB.Connection') macht, also win32 nutzt.

Code: Alles auswählen

#!/usr/bin/python
# -*- coding: UTF-8 -*-

""" Test MSSQL connection using adodbapi
Links
http://aspn.activestate.com/ASPN/Cookbook/Python/Recipe/144183
"""

import os, adodbapi

test_select_statement = "select name from master..syslogins where name = 'sa'"

dbconf = {
    "dbHost"            : '.\SQLEXPRESS',
    "dbDatabaseName"    : 'DatabaseName',
    "dbUserName"        : 'UserName',
    "dbPassword"        : 'Password',
}

osql_test = (
    "osql -S%s -d%s -U%s -P%s "
    """/w 8192 -Q"set nocount on %s"""
) % (
    dbconf["dbHost"],
    dbconf["dbDatabaseName"],
    dbconf["dbUserName"],
    dbconf["dbPassword"],
    test_select_statement,
)
print osql_test
lst = os.popen(osql_test).readlines()
try:
    if lst[2].strip() == 'sa':
        print "connection OK"
    else:
        print "connection failed!"
except IndexError:
    print "Could not connect"

print "-"*80

DSN_info = (
    "DRIVER=SQL Server;"
    "SERVER=%s;"
    "DATABASE=%s;"
    "UID=%s;"
    "PASSWORD=%s;"
) % (
    dbconf["dbHost"],
    dbconf["dbDatabaseName"],
    dbconf["dbUserName"],
    dbconf["dbPassword"],
)
print DSN_info
connection = adodbapi.connect(DSN_info)
cursor = connection.cursor()
cursor.execute(test_select_statement)
data = cursor.fetchall()
print "SQL select result:", data
if data[0][0] == "sa":
    print "connection OK"
else:
    print "connection failed!"
Ausgabe:
osql -S.\SQLEXPRESS -dDatabaseName -UUserName -PPassword /w 8192 -Q"set nocount on select name from master..syslogins where name = 'sa'
connection OK
--------------------------------------------------------------------------------
DRIVER=SQL Server;SERVER=.\SQLEXPRESS;DATABASE=DatabaseName;UID=UserName;PASSWORD=Password;
SQL select result: ((u'sa',),)
connection OK

CMS in Python: http://www.pylucid.org
GitHub | Open HUB | Xing | Linked in
Bitcoins to: 1JEgSQepxGjdprNedC9tXQWLpS424AL8cd
Benutzeravatar
gerold
Python-Forum Veteran
Beiträge: 5555
Registriert: Samstag 28. Februar 2004, 22:04
Wohnort: Oberhofen im Inntal (Tirol)
Kontaktdaten:

Mittwoch 23. November 2005, 19:28

jens hat geschrieben:Naja, es ist nich so, das ich jetzt unbedinngt den 2005'er nutzten will. Aber das ist die einzige kostenlose Variante von M$
[...]

Code: Alles auswählen

"PASSWORD=%s;"
[...]
Wie man sehen kann klappt eine connection eigentlich schon. Aber per odbc geht's einfach nicht... Leider sehe ich in den LOG-Dateien auch nicht mehr Informationen, warum das so ist :twisted:
Hi Jens!

Für ODBC muss das "PWD" heißen... :-)

Es gibt doch so wunderbare Datenbanksysteme für klein und groß, die nicht MS-geschwängert sind. Dann wird einem nur noch .NET aufs Auge gedrückt. Usw. :roll:
Ein großer Fehler beim Programmieren von SW3 war, dass ich auf MS SQL-Server als Datenbanksystem gesetzt habe. Dieses Ding hebt den Preis des Datenbankservers einfach zu sehr in die Höhe. Du brauchst unbedingt einen Server (Win2000 oder Win2003), dann brauchst du den MS SQL-Server und die Clientlizenzen. Damit nicht genug. Möchtest du eine geklusterte Lösung, muss es schon der teurere SQL-Server sein.

Hätte ich von Anfang an auf PostgreSQL gesetzt, dann hätte ich ein Programm, das auch für mittlere Betriebe interessant wäre. Außerdem kommt immer wieder die Anfrage rein, ob wir den Datenbankserver nicht auch unter Linux laufen lassen können.

Leider habe ich beim Programmieren ziemlich viele SQL-Server-eigene Funktionen eingesetzt, so dass eine Umstellung recht schwer wird.

... das war einfach mal so aus dem Nähkästchen geplaudert. :D

lg
Gerold
:-)
http://halvar.at | Kleiner Bascom AVR Kurs
Wissen hat eine wunderbare Eigenschaft: Es verdoppelt sich, wenn man es teilt.
Benutzeravatar
gerold
Python-Forum Veteran
Beiträge: 5555
Registriert: Samstag 28. Februar 2004, 22:04
Wohnort: Oberhofen im Inntal (Tirol)
Kontaktdaten:

Mittwoch 23. November 2005, 19:39

jens hat geschrieben:Ach guck mal einer an, über adodbapi geht's :shock:
Obwohl das auch nur conn=win32com.client.Dispatch('ADODB.Connection') macht, also win32 nutzt.
Hi Jens!

Wenn "adodbapi" das Meiste unterstützt, was mit ADODB funktioniert, dann ist das ja gar nicht mal so schlecht.

Die Verwendung von "client.Dispatch" bedeutet ja nur, dass es eine "lose" Verbindung zum ActiveX-Objekt "ADODB.Connection" aufbaut. Das ist zwar beim Initialisieren langsamer, nimmt aber im laufenden Betrieb nicht unbedingt viel an Geschwindigkeit weg.

Das ist wie unter "Visual Basic Script" die Verwendung von

Code: Alles auswählen

Dim objConn
Set objConn = CreateObject("ADODB.Connection")
Wenn alles was du brauchst mit ADODBAPI funktioniert, dann hast du sicher keine schlechte Wahl getroffen.
Alles was nicht über ADODBAPI funktioniert, geht ganz sicher direkt über ADODB. Was natürlich einfacher ist, wenn man so wie ich schon jahrelang mit Visual Basic und ADODB programmiert hat. :lol:

lg
Gerold
:-)
http://halvar.at | Kleiner Bascom AVR Kurs
Wissen hat eine wunderbare Eigenschaft: Es verdoppelt sich, wenn man es teilt.
Benutzeravatar
jens
Moderator
Beiträge: 8461
Registriert: Dienstag 10. August 2004, 09:40
Wohnort: duisburg
Kontaktdaten:

Donnerstag 24. November 2005, 07:59

Aha, nun geht beides! Ist ja total bescheuert, das es bei ADODB "PASSWORD=..." heißt und bei ODBC "PWD=..." :? Aber das blödste überhaupt, das man nirgendwo einen Hinweis bekommt, das die DSN-Syntax falsch ist :roll: (EDIT: Dazu hab ich eine nette Adresse gefunden: http://www.connectionstrings.com )

Was ich jetzt aber nicht ganz verstehe. Im "ODBC Datenquellen-Manager" muß ich eigentlich nicht's einstellen. Also ich kann alle "Benutzer-DSN", "System-DSN" und "Datei-DSN" löschen. Die braucht man überhaupt nicht. Ich dachte eigentlich dort müßte ich erstmal eine ODBC Quelle einrichten, auf die ich zugreife?!?!


Also ein Unterschied kann ich direkt sehen: ADODB liefert direkt unicode-Zeichen zurück, wohingegen es bei ODBC direkt konvertiert ist.

Der Zeitunterschied beim Connect ist schon deutlich messbar. Bei ADODB braucht er ca. 0.125sec und bei ODBC 0.06sec...

Leider hab ich mich bei MySQL mit dem DictCursor angefreunet. Kann einer der beiden Schnittstellen das auch??? Oder muß ich mir da selber was programmieren???


Also das ganze ich nur dafür gedacht, das PyLuid halt auch mit IIS + MSSQL läuft. Mein Hauptaugenmerk liegt allerdings klar auf Apache und MySQL ;) Nur ich möchte es zusätzlich unterstützen, da es Firmen gibt, die darauf total abfahren :roll: Fragt mich nicht warum 8)

EDIT:
Dumm ist auch das beide als paramstyle den qmark als "?" nutzten. Ich hab in Pylucid allerdings immer "%s" genutzt... Naja, das läßt sich aber vielleicht noch ganz gut anpassen...
Zuletzt geändert von jens am Donnerstag 24. November 2005, 10:52, insgesamt 1-mal geändert.

CMS in Python: http://www.pylucid.org
GitHub | Open HUB | Xing | Linked in
Bitcoins to: 1JEgSQepxGjdprNedC9tXQWLpS424AL8cd
Benutzeravatar
jens
Moderator
Beiträge: 8461
Registriert: Dienstag 10. August 2004, 09:40
Wohnort: duisburg
Kontaktdaten:

Donnerstag 24. November 2005, 09:15

Ach verdammt, ich merke gerade, das MSSQL z.B. kein AUTO_INCREMENT kennt. Bzw. heißt das bei denen irgendwas mit IDENTITY...
Hm!

Also ich möchte ganz gern, das ich PyLucid mit MySQL, SQLite und MSSQL läuft.

Ist es da vielleicht eine gute Strategie einfach nur SQL92 zu nutzten??? Oder ist das auch nicht der kleinste gemeinsamme Nenner??? Ich meine so super tolle neue Dinge wie VIEWS, Trigger ect. nutzte ich aus unwissenheit eh nicht :roll:

Kennst jemand eine gute SQL92 Referenz-Seite?

CMS in Python: http://www.pylucid.org
GitHub | Open HUB | Xing | Linked in
Bitcoins to: 1JEgSQepxGjdprNedC9tXQWLpS424AL8cd
Benutzeravatar
gerold
Python-Forum Veteran
Beiträge: 5555
Registriert: Samstag 28. Februar 2004, 22:04
Wohnort: Oberhofen im Inntal (Tirol)
Kontaktdaten:

Donnerstag 24. November 2005, 10:03

jens hat geschrieben:Ach verdammt, ich merke gerade, das MSSQL z.B. kein AUTO_INCREMENT kennt. Bzw. heißt das bei denen irgendwas mit IDENTITY...
[...]
Also ich möchte ganz gern, das ich PyLucid mit MySQL, SQLite und MSSQL läuft.
Ist es da vielleicht eine gute Strategie einfach nur SQL92 zu nutzten??? Oder ist das auch nicht der kleinste gemeinsamme Nenner??? Ich meine so super tolle neue Dinge wie VIEWS, Trigger ect. nutzte ich aus unwissenheit eh nicht
Hi Jens!

Und unter PostgreSQL funktioniert das mit den Auto-Increments auch noch ein wenig anders. :wink:

SQL92 ist nicht unbedingt der kleinste gemeinsame Nenner, da keine der oben genannten Datenbanken SQL92 *komplett* unterstützen. Jedes dieser Datenbanksysteme unterstützt einen Teil von SQL92 und ein Teil davon wurde von den Programmierern jeweils ein wenig anders interpretiert. Das fängt schon beim Erstellen von Tabellen an.

Aus meiner Sicht wäre es eher ein Feature, wenn dein PyLucid **KEINEN** zusätzlichen Datenbankserver braucht.
Und dafür eignet sich *SQLite* wahrscheinlich am besten. Was ich gelesen habe, sollte SQLite auch mit Datenbanken der Größe einiger hundert MB wunderbar klar kommen. Warum also nicht alles auf SQLite "beschränken"? SQLite läuft unter Windows und Linux komplett transparent. Einen ODBC-Treiber, damit auf die SQLite-Datenbank auch mit Excel, Access und Co. zugegriffen werden kann, gibt es auch. Es ist schnell und unterstützt, da bin ich mir ziemlich sicher, alles was du brauchst. Ich kann mir nicht vorstellen, dass der Content einer PyLucid-Site diesen Rahmen je sprengen wird.

Es gibt Programme, mit denen man SQLite-Abfragen oder auch Tabellen designen kann. Man muss also nicht alles per Hand coden. Es gibt auch schon ein "PHPSQLiteAdmin" mit dem du deine Datenbanken wie bei "PHPMyAdmin" über einen Browser verwalten kannst.

Wenn man *AutoCommit* ausschaltet, dann ist dieses Ding richtig schnell.

Wo sind die Nachteile?
- Man lernt beim Programmieren nicht so viel über andere Datenbanksysteme. :wink:

IMHO:
Wie ich schon anmerken ließ, sehe ich keinen Vorteil in der Unterstützung mehrerer Datenbanksysteme, wenn sowiso schon SQLite unterstützt wird. Datenbankunabhängig wird das System wohl nur dann, wenn du noch eine Abstraktionsschicht zwischen den Datenbanken und PyLucid einschiebst. Dadurch wird das System aber sicher nicht schneller.

lg
Gerold
:-)
http://halvar.at | Kleiner Bascom AVR Kurs
Wissen hat eine wunderbare Eigenschaft: Es verdoppelt sich, wenn man es teilt.
Benutzeravatar
jens
Moderator
Beiträge: 8461
Registriert: Dienstag 10. August 2004, 09:40
Wohnort: duisburg
Kontaktdaten:

Donnerstag 24. November 2005, 10:18

Naja, ich hab ja mit MySQL angefangen... Meine versuche mal eben alles für SQLite kompatibel zu machen, schlugen recht schnell fehl...

Eigentlich hab ich schon eine Abstraktionsschicht in PyLucid selber. Alle SQL-Abfragen laufen über ein Modul. Wobei es auch von allen Modulen/Plugins möglich war direkt an den Cursor-Objekt ran zu gehen.

Außerdem mache ich reichlich gebrauch von meinem eigenen SQLwrapper. Das deckt ca. 90% aller SQL-Abfragen ab. Nur Sonderwünsche bauen sich selber einen SQL-Statement zusammen...

Vielleicht ist auch SQLObject eine Lösung, aber alles darauf umzustellen dürfte mehr Arbeit sein...

Ich Probiere erstmal ein wenig weiter, mal sehen, wie's läuft.

Gerade hab ich festgestellt, das es ein "SHOW FIELDS FROM ..." auch erstmal so nicht gibt. Es geht mit:
SELECT COLUMN_NAME FROM INFORMATION_SCHEMA.COLUMNS WHERE TABLE_NAME = '...';
:roll:

CMS in Python: http://www.pylucid.org
GitHub | Open HUB | Xing | Linked in
Bitcoins to: 1JEgSQepxGjdprNedC9tXQWLpS424AL8cd
Benutzeravatar
jens
Moderator
Beiträge: 8461
Registriert: Dienstag 10. August 2004, 09:40
Wohnort: duisburg
Kontaktdaten:

Donnerstag 24. November 2005, 10:49

Ach, so einfach ist das alles ja nicht:

Code: Alles auswählen

command:INSERT INTO lucid_TestTable ( data1,data2 ) VALUES ( ?,? ); with parameters: ('Value A 1', 'Value A 2')
Mehrfache Recordsets sind bei einer Transaktion mit diesem Cursortyp nicht m\xf6glich. \xc4ndern Sie entweder den Cursortyp, f\xfchren Sie Commit f\xfcr die Transaktion aus, oder schlie\xdfen Sie eines der Recordsets.
Mit absließendem "COMMIT;" klappt es auch nicht... In wie fern kann ich bei adodbapi einen anderen Curortyp nutzen?!?!?

CMS in Python: http://www.pylucid.org
GitHub | Open HUB | Xing | Linked in
Bitcoins to: 1JEgSQepxGjdprNedC9tXQWLpS424AL8cd
Antworten