Zugriff auf Datenbank nicht mehr möglich

[Ynkelonium]

Hallo zusammen,
unter Linux 18.3 habe ich mit Python 3.5.2 (Tk.: 8.6.5 und Idle: 3.5.2) verschiedene Anwendungen mit je einer Datenbank unter SQlite3 programmiert, die bisher auch völlig problemlos funktioniert haben.
Vor wenigen Wochen bin ich dann auf Linux 21.3. umgestiegen. Als ich nun versucht habe, eine meiner Anwendungen in dieser Umgebung zu nutzen, habe ich folgende Fehlermeldung erhalten:

"============ RESTART: /home/lauber/Schreibtisch/Privatprg_python.py ============
Traceback (most recent call last):
File "/usr/lib/python3.10/idlelib/run.py", line 578, in runcode
exec(code, self.locals)
File "/home/lauber/Schreibtisch/Privatprg_python.py", line 1946, in <module>
sqliteCon = sqlite3.connect('/media/lauber/Schreibtisch/spielwiese_aktuell.db') # = Test unter Linux21.3
sqlite3.OperationalError: unable to open database file"

Wie ich inzwischen herausgefunden habe, wird unter Linux 21.3 Python 3.10 (TK: 8.6.12 und Idle: 3.10) verwendet. Mein Gefühl sagt mir - sachliche andere Gründe konnte ich nicht finden -, dass in diesen unterschiedlichen Versionen das Problem liegt. Allerdings habe ich noch keinen Ansatz gefunden, um einer Lösung näher zu kommen.
Hat jemand schon ähnliche Probleme gehabt bzw. wer kann mir hier mit einem Hinweis/Tipp/Rat weiterhelfen.

Danke und Gruß
ynkelonium

[__blackjack__]

@Ynkelonium: Es gibt kein Linux Versionsnummer. Die Distribution wird irgendeinen Namen haben.

Das wird aber nicht das Problem sein, sondern dass es diesen Pfad auf dem neuen System wahrscheinlich nicht geben wird.

Was wird denn ausgegeben wenn Du folgendes in einem Terminal eingibst:

Code: Alles auswählen

ls -l /media/lauber/Schreibtisch/spielwiese_aktuell.db

Edit: Randmeberkung: Namen werden in Python klein_mit_unterstrichen geschrieben. Ausnahmen sind Konstanten (KOMPLETT_GROSS) und Klassen (PascalCase).

`sqliteCon` sollte also `sqlite_con` heissen. Wobei man keine kryptischen Abkürzungen in Namen verwenden sollte, also `sqlite_connection`. Sofern es keine anderen Verbindungen gibt, kann man sich das `sqlite` sparen, also nur `connection`.

Datenbankverbindungen sollte man nach gebrauch schliessen. Um das sicherzustellen bietet sich die ``with``-Anweisung und `contextlib.closing()` an.

[Ynkelonium]

Danke für die schnelle Reaktion.

Also zumindest ich kenne Linux Mint in erster Linie über diese Nummern, aber beides sind 64-Bit Versionen und tragen nach meinen Unterlagen je den Namen "Cinnamon".

Also normalerweise liegt die Datenbank auf einer zweiten separaten Festplatte (reine Datenplatte), auf die ich von beiden Linux-Versionen problemlos zugreifen kann. Da der Fehler aber zuerst dort aufgetreten ist, habe ich die Datenbank testweise auf meinen "Linux-Schreibtisch" verlegt. Aber der Fehler ist derselbe geblieben.

Folgende Ausgabe im Terminal ergibt sich:

"lauber@lauber-LinuxMint20:~$ ls -l /media/Lauber/Schreibtisch/spielwiese_aktuell.db
ls: Zugriff auf '/media/Schreibtisch/spielwiese_aktuell.db' nicht möglich: Datei oder Verzeichnis nicht gefunden"

Also mir selbst fehlt für dieses Ergebnis jede Erklärung. Die Datenbank liegt tatsächlich am angegebenen Ort und kann mit z.b. SQLite-Werkzeugen problemlos geöffnet und bearbeitet werden.

Im übrigen natürlich danke für die Hinweise zur Schreibweise in Python.

[sparrow]

__blackjack__ wollte darauf hinweisen, dass du den Namen der Distribution nicht genannt hattest. Ob sich inter dem "Linux 18.3" ein Mint, Suse oder Arch verbirgt macht einen großen Unterschied.

Die Fehlermeldung aus deinem Beitrag passt nicht zum Befehl. In deinem Befehl hast du "/media/Lauber" geschrieben in der Fehlermeldung steht "/media/Schreibtisch".
Und grundsätzlich musst du schauen, ob die Datei tatsächlich dort liegt, wo du sie vermutest.
Wie genau lautet die Ausgabe von dem Befehl, den __blackjack__ angemerkt hat? Ich bim mir ziemlich sicher, dass sie von dem geposteten abweicht.

[Ynkelonium]

Danke für den Hinweis, aber da ist mir nur beim posten der Abfrage ein Fehler unterlaufen. Das Ergebnis bzw. die Fehlermeldung ist völlig gleich, egal ob ich mit "/media/Lauber" oder "/media/Schreibtisch" abfrage. Tatsächlich liegt die Datenbank aber auf "Schreibtisch". Entschuldigung.

Aber die Ausgabe stimmt 100 %.

[sparrow]

Wo liegt das Python Programm? Auch auf dem Schreibtisch?
Falls ja, zeigt die Fehlermeldung, dass du media mit /home verwechselst.

[__blackjack__]

@Ynkelonium: Naja dann existiert diese Datei unter dem Pfad ganz offensichtlich nicht. Also kann man sie dort auch nicht öffnen.

[DeaD_EyE]

Öffne ein Terminal. Dann wechsle mit cd in das Verzeichnis, in dem sich das Programm und die Datenbank befindet.
Dann pwd eingeben. Das Programm pwd gibt den aktuellen Pfad im Terminal aus. Steht auch meist bei der Eingabeaufforderung dabei.

Ein ~ verweist auf das Home-Verzeichnis das aktuell angemeldeten Benutzers. Im Verzeichnis /media sollten nur Wechseldatenträger angezeigt werden.
Falls die DB auf einem USB-Stick ist, dann ist das eine ganz schlechte Idee.

[Ynkelonium]

Danke für die Antworten bis hierher.
Das Problem ist - zumindest im Ansatz - gelöst. Geholfen hat mir hier ganz wesentlich der Hinweis von sparrow bezüglich des Speicherortes von Programm und Datenbank.
Es scheinen sich jetzt aber wohl einige "Folgeprobleme" zu ergeben, aber da will ich schauen, dass ich diese selbst einer Lösung zuführen kann.

[oldboyJR]

Ich kenne mich zwar nicht mit Linux besonders gut aus aber eher mit Windows. Ich benutze unter anderem in Windows Open Office weil es eine sql Anbindung hat und dazu eine Bedienoberfläche wie in Microsoft office 97. Wenn ich ein neues Windows aufsetze und Open Office installiere dann bekomme ich keine Verbindung zu den Datenbanken des Programms. Wenn man das Aufsetzen immer erst macht wenn es überfällig wird (kein Service mehr) dann vergisst man hat aber noch ein bisschen im Hinterkopf. Kurz und gut Open Office braucht eine 32 bit Java Umgebung und die Jar. Open Office hat ein Interne Programm dazu welches dann die Java Umgebung einbindet wie eine IDE Oberfläche.

[__blackjack__]

@oldboyJR: Das hat alles so überhaupt gar nichts mit diesem Thema zu tun. Hier geht es weder um Windows, noch um Office-Anwendungen, noch um Java, noch um eine Datenbank die etwas ausserhalb der Python-Standardinstallation benötigt um eine ”Verbindung” herzustellen.

[oldboyJR]

Es gibt ja soviele SQL Treiber wie Systeme. Die selbe SQL datei mit MariaDB aufzurufen kann eine SQL Datei die mit MySql erstellt zum Absturz bringen. Auch doppelter gleichzeitiger Zugriff mit beiden Treibern oder einzelnen haben ab und zu heftige folgen. Das vergeben eines Paßwortes hat mal bei mir einen Absturz verursacht!!

[__blackjack__]

@oldboyJR: Es geht hier nicht um SQL-Dateien, nicht um MariaDB, nicht um MySQL, und auch nicht um irgendwelche Treiber.

[oldboyJR]

oho dann reden wir über ein neues Linux system mit neuen Datenbanktreibern obwohl dieser post im Datenbankürogrammieren steht nicht über Datenbanken? Währe es möglich das die neue Software eine neue ID erzeugt die durch den hasch dann kein gleiches Passwort erzeugt? Obwohl bekanntlich ja oft bei Ubuntu und Co, Systemwechsel häufig auf Treibern aufbauen die es in Opensoftware benutzen kann. Und viele dieser Opensoftware dann verkauft werden und zu Salesoftware werden.

[LeanUnd]

oho dann reden wir über ein neues Linux system mit neuen Datenbanktreibern obwohl dieser post im Datenbankürogrammieren steht nicht über Datenbanken? Währe es möglich das die neue Software eine neue ID erzeugt die durch den hasch dann kein gleiches Passwort erzeugt? Obwohl bekanntlich ja oft bei Ubuntu und Co, Systemwechsel häufig auf Treibern aufbauen die es in Opensoftware benutzen kann. Und viele dieser Opensoftware dann verkauft werden und zu Salesoftware werden.

Die Diskussion über Treiber ist durchaus relevant, da die Qualität und Kompatibilität von Treibern sich direkt auf den Code auswirkt.

[oldboyJR]

Ps: Mir fällt noch, ein das neue Systeme von Ubuntu und Co. häufig versucht Windowsvoreinstellungen zu emulieren um den Systemwechsel zu erleichtern. Wenn dann die Steuerungssoftware der Serveranwendung z.B. Apache automatisch angepasst wird dann ein anderes Protokoll aktiviert wurde um die Kompatibilität zu gewährleisten ? Die Sequencen sich ändern? Ich habe verschiedenes probiert. Ach evtl. hat er auch den Port verändert oder nicht übernommen!

[__blackjack__]

@oldboyJR: Ja genau, der Port bei einer SQLite3-Datenbank hat sich geändert. Du schreibst Unsinn.

[oldboyJR]

Nun es gibt immer etwas was der Normalo normalerweise macht wie den Port verändern. Wenn man Xampp installiert hat und nicht den allgemeinen Port verwenden möchte dann kann man das doch machen. Zugegeben in den neusten frei zugänglichen Software gibt es Bestrebungen indirekt zu profitieren. So nach dem Motto ich zeige dir die neusten Module und du arbeites mit an unserem Wissenspool. Die Standallone spider die ich installierte meldet zum Beispiel. Du hast Module installiert die nicht von unserer Version unterstützt wird. Die Folge ist das nur die Spider 5 die mit Anaconda durch lounch gestartet wird, ordendlich funktioniert. Wenn ich das aber richtig verstehe dann läuft das über eine virtuelle ebene mit indirekter python _self_ vorgaben / <modul> und mit Responsistories abhängigkeiten die man dann auch für Standallone-Systeme zwangsweise mitnehmen muß. Was gegen die Absicht des Programmierers ist wenn er eine StandalloneVersion benutzt. Zu den möglichen Ursachen ist dann auch das vermeindlich geladene Module im aktuellen Editor zwar fehlerlos eingebunden werden und keine Fehler angezeigt werden aber die aufgerufene Konsole einer anderen viertuellen Umgebung diese Module nicht haben. Wie läd man solche virtuellen Umgebungen ?? Wie stellt man fest in welcher virtuellen Umgebung man jetzt das Modul installiert har?

[oldboyJR]

Da ich ähnliche Probleme habe beschäftigte ich mich mit meiner SQL Abfrage ebenso. Ich hatte mysql unter PHP und HTLM Script eingerichtet um Post abzufragen und in der Datenbank zu speichern. Ich tat dieses weil ich in dieser Richtung mit Python nicht ans Ziel kam. Mein Wissen ist also darüber eher aus der PHP Schnittstelle. Nun versuche ich das selbe in Python zu machen und scheiterte an den Abfragen die indirekt mit def abfra_ge_my_tabel(): hinterlegt war. In spyder wirft es Probleme mit dem Modul hervor. Im Variablenmanager wurde ein ERgebnis nicht angezeigt. Erst die aktiivierung der anzeige für module und aufrufbares schafte Ergebnisse mit dem Wehrmutstropfen das beim Editier/Sichtversuch key error auslöste. Letztendlich habe ich die Abfrage ohne def(): umgewandelt. Also versuche doch mal folgendes listing mit deinen Einträgen

Code: Alles auswählen

import mysql.connector
Error = None
conn = mysql.connector.connect(
    host="localhost",
    user="root",
    password="xxxx",
    database="xxxx",
    port="3306")

cursor = conn.cursor()
cursor.execute("SELECT * from unterstuezer")
result = cursor.fetchall()  # alles steht im Variablenmanager
print(result)  # schreibt alles durcheinander
cursor.close()
for data in result:
    print("Nummer: " + str(data[0]) + "; Text: " + data[1], data[2],
          data[3], data[4], data[5], data[6], data[7])  
    #schreibt alles schön untereinander
    # Man sieht wieviele indexe pro data hat 
    #und kann die Printanweisung dahin anpassen