Suche DB-Interface ohne Installation

Installation und Anwendung von Datenbankschnittstellen wie SQLite, PostgreSQL, MySQL, der DB-API 2.0 und sonstigen Datenbanksystemen.
Benutzeravatar
gerold
Python-Forum Veteran
Beiträge: 5554
Registriert: Samstag 28. Februar 2004, 22:04
Wohnort: Telfs (Tirol)
Kontaktdaten:

Beitragvon gerold » Dienstag 20. Januar 2009, 13:19

Hallo!

Mir gefällt die Idee mit der Zwischenschicht (XMLRPC, JSONRPC, Pyro http://pyro.sourceforge.net/, ...) immer besser. Denn damit kannst du alles auf dem Server erledigen. Die Daten können mit XMLRPC, JSONRPC, Pyro,... oderwasweisichnochalles übermittelt werden. Es muss kein spezieller Datenbanktreiber installiert werden.

So umgehst du das Problem mit dem Treiber und dessen Abhängigkeiten, die eventuell gegeben sein müssen.

mfg
Gerold
:-)
http://halvar.at | Kleiner Bascom AVR Kurs
Wissen hat eine wunderbare Eigenschaft: Es verdoppelt sich, wenn man es teilt.
Benutzeravatar
ms4py
User
Beiträge: 1178
Registriert: Montag 19. Januar 2009, 09:37

Beitragvon ms4py » Dienstag 20. Januar 2009, 15:35

Von dieser Lösung bin ich leider nicht ganz so begeistert. Hätte ja dann viel größeren Aufwand.

Hab gerade auch noch Probleme mit Windows und den Zugriff auf den SQL Server. psycopg funktioniert nur mit der alten Version und benötigt ein zusätzliches Modul mit einer zwielichtigen Lizenz (Egenix mx base).

Habe dann mal PyGreSQL installiert. Bekomme beim import folgenden Fehler:
import _pg
ImportError: DLL load failed: Das angegebene Modul wurde nicht gefunden.

libpg.dll konnte nicht gefunden werden
Müsste das in dem Binary-Packet eigentlich mit dabei sein? Habe keine Admin-Rechte, vielleicht werden die DLLs einfach nicht mit installiert?
Zuletzt geändert von ms4py am Dienstag 20. Januar 2009, 15:56, insgesamt 1-mal geändert.
Benutzeravatar
gerold
Python-Forum Veteran
Beiträge: 5554
Registriert: Samstag 28. Februar 2004, 22:04
Wohnort: Telfs (Tirol)
Kontaktdaten:

Beitragvon gerold » Dienstag 20. Januar 2009, 15:55

ice2k3 hat geschrieben:Von dieser Lösung bin ich leider nicht ganz so begeistert. Hätte ja dann viel größeren Aufwand.

Hallo ice2k3!

Das ist ein sehr geringer Aufwand gegenüber den Versuchen, die du derzeit durchführst. Aber unabhängig davon.

Installieren von PostgreSQL und psycopg2 unter Windows XP bzw. Windows Vista:

0.) Den alten Balast loswerden: psycopg, psycopg2 und PostgreSQL deinstallieren und den Computer neu starten.

1.) Installiere dir unter Vista auf keinen Fall "Python für 64 Bit". Nimm weiterhin "Python für 32 Bit". Installiere dir das neueste Python 2.6.x. Spiele unter Windows gar nicht erst mit Python 3. Das bringts nicht. Wenn es irgendwelche Inkompatibilitäten gibt, dann lassen die sich im Nachhinein in kürzester Zeit im Programm anpassen. http://python.org/ftp/python/2.6.1/python-2.6.1.msi

2.) Installiere PostgreSQL. Am Besten nimmst du den "pgInstaller" und nicht den "One click installer". Dessen Sinn habe ich sowiso noch nicht verstanden. Nimm die Version "8.3.4" http://wwwmaster.postgresql.org/downloa ... .3.4-1.zip, denn dafür gibt es einen passenden Windows-Treiber für Python. Es wird wahrscheinlich in den nächsten Tagen einen neuen Treiber für 8.3.5 geben, aber darauf muss man ja nicht warten. Das kann man später updaten.

3.) Installiere "psycopg2". Das Findest du für Python 2.6.x hier: http://www.stickpeople.com/projects/pyt ... elease.exe
Diese EXE-Datei musst du nur mit einem Doppelklick ausführen und schon ist die Schnittstelle installiert.

4.) Ausprobieren: http://www.python-forum.de/topic-12304.html

mfg
Gerold
:-)
Zuletzt geändert von gerold am Freitag 13. März 2009, 19:28, insgesamt 1-mal geändert.
http://halvar.at | Kleiner Bascom AVR Kurs

Wissen hat eine wunderbare Eigenschaft: Es verdoppelt sich, wenn man es teilt.
Benutzeravatar
ms4py
User
Beiträge: 1178
Registriert: Montag 19. Januar 2009, 09:37

Beitragvon ms4py » Dienstag 20. Januar 2009, 16:01

Programme, die ich unter Windows entwickle, sollten ja auch mit der Steuerung kompatibel sein, deshalb kommt ein Upgrade momentan nicht in Frage.

Nochmal zu meinem Problem mit PyGreSQL. Kann es sein, dass bei dem Binary-Paket nicht alles mitinstalliert werden (wegen mangelden Admin-Rechten).
Benutzeravatar
gerold
Python-Forum Veteran
Beiträge: 5554
Registriert: Samstag 28. Februar 2004, 22:04
Wohnort: Telfs (Tirol)
Kontaktdaten:

Beitragvon gerold » Dienstag 20. Januar 2009, 16:02

ice2k3 hat geschrieben:Habe keine Admin-Rechte, vielleicht werden die DLLs einfach nicht mit installiert?

Hallo ice2k3!

Dann brauchst du gar nicht erst versuchen, PostgreSQL, Python und Psycopg2 zu installieren. Ohne Adminrechte auf der Windows-Schüssel wird das nie etwas werden.

mfg
Gerold
:-)
http://halvar.at | Kleiner Bascom AVR Kurs

Wissen hat eine wunderbare Eigenschaft: Es verdoppelt sich, wenn man es teilt.
Benutzeravatar
ms4py
User
Beiträge: 1178
Registriert: Montag 19. Januar 2009, 09:37

Beitragvon ms4py » Dienstag 20. Januar 2009, 16:09

PostgreSQL und Python ist natürlich schon installiert.
Geht nur um das PyGreSQL Package.
Aber das scheint wohl einen lokal laufenden Postgre Server benötigen, soweit ich das jetzt untersucht habe.

Ich frage jetzt auf jeden Fall mal beim Steuerungshersteller an, was und ob er mir bestimmte Möglichkeiten bieten kann. Werde mich dann wieder melden.

Edit:
Das Kompilieren einer Schnittstellte benötigt immer den installierten Server, kann das sein? Hab mir gerade das Setup der psycopg2 angeschaut und das sah ganz danach aus.
lunar

Beitragvon lunar » Dienstag 20. Januar 2009, 17:50

ice2k3 hat geschrieben:psycopg funktioniert nur mit der alten Version und benötigt ein zusätzliches Modul mit einer zwielichtigen Lizenz (Egenix mx base).

Hast du diese Lizenz überhaupt gelesen, oder war sie dir einfach nur zu lang?

Die Lizenz ist nämlich eigentlich nichts weiter als eine "virale" X11-Lizenz mit komplexeren Klauseln zum Haftungs- und Garantieausschluss sowie einigen Sonderklauseln, die weitere vertragliche Beziehungen zur herstellenden Firma ausschließen sowie die Lizenz auf Egenix-mx-base beschränken (falls das Paket nicht allein verteilt wird).

Summa summarum ist das eine makellose freie Lizenz.
Benutzeravatar
ms4py
User
Beiträge: 1178
Registriert: Montag 19. Januar 2009, 09:37

Beitragvon ms4py » Dienstag 20. Januar 2009, 18:25

Benötigen diese Schnittstellen nun einen lokal installierten Server oder nicht? Hat da jemand Erfahrung?
lunar

Beitragvon lunar » Dienstag 20. Januar 2009, 19:13

ice2k3 hat geschrieben:Benötigen diese Schnittstellen nun einen lokal installierten Server oder nicht? Hat da jemand Erfahrung?

Wenn die Schnittstellen gegen die Client-Bibliotheken des entsprechenden DBMS gelinkt sind, benötigten sie natürlich auch die entsprechenden Bibliotheken (also im mindesten eine Installation der DB-Client-Programme) und – wenn man sie kompilieren möchte – auch die entsprechenden Header.

Das scheint bei dem von dir verwendeten Paket offenbar der Fall zu sein.
Benutzeravatar
ms4py
User
Beiträge: 1178
Registriert: Montag 19. Januar 2009, 09:37

Beitragvon ms4py » Freitag 13. März 2009, 10:17

So, jetzt grabe ich noch mal diesen Thread aus.
Der aktuelle Stand ist jetzt so:
Die Maschinen greifen mit Hilfe einer Pyro-Zwischenschicht auf die DB zu und die Clients am PC direkt auf die DB.

Nun hätte ich die Idee, in der Pyro-Komponente eine sqlite Datenbank zu intergrieren und mit den PC-Clients auch mit der Pyro-Komponente zu kommunizieren, um dann so komplett auf den Postgre Server verzichten zu können.
Bei der Anwendung ist es von wichtiger Bedeutung eine einfache Installation mit möglichst wenig Komponenten bereitzustellen.
Ist das ein guter Ansatz oder aus welchen Gründen nicht zu empfehlen.

Anzahl Clients: Es könnten ca. bis zu 25 Maschinen Anfragen senden (Standard 5-10) und mehrere PC-Clients. (Alle haben vermutlich ein 5 Sekunden Intervall, wobei die Datenmenge auf der PC Seite entsprechend höher ist, weil diese alle Daten empfangen und die Maschinen nur jeweils ihre spezifischen senden.)
Benutzeravatar
Leonidas
Administrator
Beiträge: 16023
Registriert: Freitag 20. Juni 2003, 16:30
Kontaktdaten:

Beitragvon Leonidas » Freitag 13. März 2009, 10:27

Solange man nicht zu viele gleichzeitige Writes in die Datenbank hat, ist das ok.
My god, it's full of CARs! | Leonidasvoice vs Modvoice
Benutzeravatar
ms4py
User
Beiträge: 1178
Registriert: Montag 19. Januar 2009, 09:37

Beitragvon ms4py » Freitag 13. März 2009, 11:14

Lasse gerade testweise 20 Maschinen-Clients in einer While True Schleife ihre Daten updaten. Außer einer hohen CPU-Auslastung scheint das keine Probleme zu machen. Von der Seite her sehe ich da also keine Probleme.

Sieht vielleicht sonst noch jemand Probleme? Ansonsten würde ich diesen Ansatz weiterverfolgen.
Benutzeravatar
ms4py
User
Beiträge: 1178
Registriert: Montag 19. Januar 2009, 09:37

Beitragvon ms4py » Freitag 13. März 2009, 12:24

Bisher schütze ich den DB Zugriff mit einem Lock, so dass immer nur einer parallel auf die DB zugreifen kann.
Ist jetzt so schon ein bisschen performant lastig. Gefällt mir nicht so.

Ist der Lock notwendig, oder gibt es da Alternativen?
Benutzeravatar
Leonidas
Administrator
Beiträge: 16023
Registriert: Freitag 20. Juni 2003, 16:30
Kontaktdaten:

Beitragvon Leonidas » Freitag 13. März 2009, 18:34

SQLite kommt mit parallelen Reads zurecht, mit parallelen Writes eher nicht.
My god, it's full of CARs! | Leonidasvoice vs Modvoice
Benutzeravatar
ms4py
User
Beiträge: 1178
Registriert: Montag 19. Januar 2009, 09:37

Beitragvon ms4py » Dienstag 17. März 2009, 16:17

Leonidas hat geschrieben:SQLite kommt mit parallelen Reads zurecht, mit parallelen Writes eher nicht.

Ja, das ist klar.
sqlite3.connect(database[, timeout, isolation_level, detect_types, factory])

When a database is accessed by multiple connections, and one of the processes modifies the database, the SQLite database is locked until that transaction is committed. The timeout parameter specifies how long the connection should wait for the lock to go away until raising an exception. The default for the timeout parameter is 5.0 (five seconds).

Aber der interne Lock von Sqlite dürfte doch eigentlich reichen?

Wer ist online?

Mitglieder in diesem Forum: 0 Mitglieder