Python 2.5 sqlite3 kann Datenbank nicht richtig öffnen

[vIiRuS]

Ahoi

Ich hoffe mal das hier noch support für Python 2.5 geleistet wird... (da Debian stable das noch hat gehe ich einfach mal von aus )

Ich habe mit Sqliteman eine sqlite Datenbank erstellt. Lokal mit Python 2.6 kann ich die auch super aufmachen und abfragen, wenn ich das ganze jetzt aber auf meinem Server aufmachen will, bekomme ich folgenden error:

sqlite3.OperationalError: no such column: texte.TID

Das seltsame ist, das er die Datenbank aufmachen kann, und auch sieht das eine Tabelle namens "texte" vorhanden ist.. (da hörts dann aber wohl auch leider wieder auf).

Code snippet mit dem ichs versuche:

Code: Alles auswählen

#!/usr/bin/python
import sqlite3

connection = sqlite3.connect("datenbank.db")
cur = connection.cursor()
cur.execute ("""SELECT texte.TID, texte.Titel, texte.Text, benutzer.Name, fach.Fach FROM 
    (texte INNER JOIN benutzer ON texte.UID = benutzer.UID) INNER JOIN fach ON fach.FID = texte.FID""")
for row in cur:
	print row

Kennt jemand vllt das problem und weiß wie ich das lösen kann?

[Hyperion]

Sicher, dass das auch die gleiche Version der DB auf dem Server ist? Gibt es dort wirklich die Spalte TID?

Was sollen die "(..)" im where-Teil? Kapiere da den Sinn dahinter nicht...

[vIiRuS]

Sicher, dass das auch die gleiche Version der DB auf dem Server ist? Gibt es dort wirklich die Spalte TID?

wenn md5sum mich nicht anflunkert sind das genau die gleichen dateien

Was sollen die "(..)" im where-Teil? Kapiere da den Sinn dahinter nicht...

was meinst du damit? welcher where teil?

[Hyperion]

Sicher, dass das auch die gleiche Version der DB auf dem Server ist? Gibt es dort wirklich die Spalte TID?

wenn md5sum mich nicht anflunkert sind das genau die gleichen dateien

Ok.

Was sollen die "(..)" im where-Teil? Kapiere da den Sinn dahinter nicht...

was meinst du damit? welcher where teil?

Wieviele Klammern siehst Du in Deiner Query?

[vIiRuS]

achso die klammern meinst du... (wobei das ja eig der from teil ist aber egal..)

Soweit ich weiß braucht man das so wenn man zwei mal nen Inner Join macht... vllt war ich da aber auch falsch informiert... auf jeden fall funktioniert es so auch. (da die abfrage ja in sqliteman und bei mir lokal funktioniert)

[Hyperion]

achso die klammern meinst du... (wobei das ja eig der from teil ist aber egal..)

Ich wüßte nicht, dass man die braucht... aber ok, hilft beim Problem nicht.

Ggf müßtest du mal einen kleinen Dump posten. dann könnte man es versuchen nachzuvollziehen

[vIiRuS]

Ggf müßtest du mal einen kleinen Dump posten. dann könnte man es versuchen nachzuvollziehen

öööhm. dump von? Datenbank? Irgend ein Python Dump?

[Hyperion]

Ggf müßtest du mal einen kleinen Dump posten. dann könnte man es versuchen nachzuvollziehen

öööhm. dump von? Datenbank? Irgend ein Python Dump?

Datenbank.

[Hyperion]

Seh ich erst jetzt: Wo kommt denn der Fehler? Zeile 6 oder 8?

[vIiRuS]

Datenbankdump:

PRAGMA foreign_keys=OFF;
BEGIN TRANSACTION;
CREATE TABLE texte (
"tid" INTEGER,
"titel" TEXT,
"text" TEXT,
"uid" TEXT,
"fid" TEXT,
"dateiname" TEXT
);
INSERT INTO "texte" VALUES(1,'test1','bla!','1','1',NULL);
INSERT INTO "texte" VALUES(2,'test2','bla!','2','2',NULL);
CREATE TABLE fach (
"fid" INTEGER,
"fach" TEXT
);
INSERT INTO "fach" VALUES(1,'Mathe');
INSERT INTO "fach" VALUES(2,'Informatik');
CREATE TABLE benutzer (
"uid" INTEGER,
"name" TEXT DEFAULT ('Anonymous'),
"schule" TEXT,
"bundesland" TEXT,
"klassenstufe" TEXT,
"nickname" TEXT
);
INSERT INTO "benutzer" VALUES(1,'Anonymous','sone schule','B','12','Anonymous');
INSERT INTO "benutzer" VALUES(2,'Anonymous','eine','T','12','Anonymous');
INSERT INTO "benutzer" VALUES(3,'Anonymous','keine','null','1','Anonymous');
COMMIT;

Der Fehler tritt schon in Zeile 6 auf, also wenn er versucht den execute befehl auszuführen (sry. das ich vergessen hab das mitzukopieren)

[Hyperion]

Und wenn Du "TID" mal klein schreibst?

Edit: Tabellen ohne PK sind übrigens keine gute Idee! Wieso willst Du keine definieren?

[vIiRuS]

hm nein da kommt immernoch der selbe Fehler (die idee hatte ich auch schon, und habs gerade eben auch nochmal getestet)

Das PK durchaus zu empfehlen sind weiß ich zum glück auch.... nur ist Sqlitemans "PK autoinkrement" wohl doch kein PK.... -.-

Ich habs gefühl ich sollte versuchen das ganze mal mit Python selbst (am besten direkt aufm server (also mit dem problememachenden 2.5).... vielleicht krieg ichs ja dann zum laufen (bzw. dann sollte es ja eigentlich mal klappen...)

[Hyperion]

hm nein da kommt immernoch der selbe Fehler (die idee hatte ich auch schon, und habs gerade eben auch nochmal getestet)

Hätte ja sein können, dass Case-Insensitivität nicht immer gegeben ist.

Das PK durchaus zu empfehlen sind weiß ich zum glück auch.... nur ist Sqlitemans "PK autoinkrement" wohl doch kein PK.... -.-

autoincrement hat nichts mit einem Primär Schlüssel zu tun! Der PK definiert eben exakt ein Tupel in einer Tabelle. Dabei kann er aus mehreren Attributen bestehen.

Kennst Du den Wert eines PK, dann liefert Dir eine select-Anfrage mit Test auf diese Werte eben exakt das Tupel zurück, welches durch diesen PK bestimmt wird - oder auch keines, wenn es zu einem PK kein Tupel gibt.

Ich habs gefühl ich sollte versuchen das ganze mal mit Python selbst (am besten direkt aufm server (also mit dem problememachenden 2.5).... vielleicht krieg ichs ja dann zum laufen (bzw. dann sollte es ja eigentlich mal klappen...)

Das verstehe ich nicht? Womit veruschst Du es denn sonst?

[vIiRuS]

autoincrement hat nichts mit einem Primär Schlüssel zu tun! Der PK definiert eben exakt ein Tupel in einer Tabelle. Dabei kann er aus mehreren Attributen bestehen.

Ich habe auch eher erwartet das es ein Primärschlüssel ist weil das Feld "PK autoinkrement" heißt... (Da es keine andere möglichekit gab etwas als Primärschlüssel zu definieren bin ich mal davon ausgegangen, dass er es da macht...

Kennst Du den Wert eines PK, dann liefert Dir eine select-Anfrage mit Test auf diese Werte eben exakt das Tupel zurück, welches durch diesen PK bestimmt wird - oder auch keines, wenn es zu einem PK kein Tupel gibt.

Das verstehe ich nicht? Womit veruschst Du es denn sonst?

Ich mach die sonst immer mit Sqliteman ( http://sqliteman.com/ ). Bisher hatte ich da auch keinerlei Probleme mit.

[Hyperion]

Ich habe auch eher erwartet das es ein Primärschlüssel ist weil das Feld "PK autoinkrement" heißt... (Da es keine andere möglichekit gab etwas als Primärschlüssel zu definieren bin ich mal davon ausgegangen, dass er es da macht...

Ein auto increment ist ein nützliches Zusatzfeature quasi alle RDMS; notwendig ist es aber nicht! Oftmals will man den Wert eines PK nicht automatisch setzen lassen, sondern explizit angeben; z.B. eine Email-Adresse, KFZ-Kennzeichen usw. (Diese könnten sehr gut typische PK sein)

Ich mach die sonst immer mit Sqliteman ( http://sqliteman.com/ ). Bisher hatte ich da auch keinerlei Probleme mit.

Aber Du hast die Ideen doch wohl hoffentlich mit dem Python-Script ausprobiert, oder etwa nicht? Anders wirst Du den Fehler sicherlich nicht elemninieren...

[Hyperion]

So, ich das mal bei mir getestet. Sowohl mit Deinem Script als auch direkt im SQLite Manager funzt die Query und man erhält ein Ergebnis.

Allerdings habe ich auch Python 2.6.x.

Ich würde einfach mal folgendes vorschlagen: Du reduzierst Deine Query auf das nötigste:

Code: Alles auswählen

SELECT texte.tid
FROM texte

Und prüfts mal, ob das klappt. Wenn nein, wähle eine andere Spalte, solange bis Du etwas funktionierendes hast. Dann erweitere die Query Schritt für Schritt, bis Du auf den obigen Fehler triffst.

Kleine Anmerkung noch: Ich würde die Foreign Key Beziehungn zumindest angeben, auch wenn SQLite sie nicht nutzt! (Und natürlich die PK explizit angeben)

Außerdem würde ich die FKs in der Tabelle "texte" nicht "uid" nennen, sondern "user". Den Verweis sieht m,an dann ja anhand des FK; dafür kann man sich unter "user" aber besser etwas vorstellen. Eine "uid" ist dagegen eher ein kryptischer Begriff.

[vIiRuS]

wie ich ja sagte habe ich die DB natürlich auch mit Python getestet. Lokal (mit 2.6) funktioniert es auch bei mir. Probleme macht erst 2.5.....

Ich werd da mal noch rumprobieren und dann berichten ob es geklappt hat (und wie..)


*EDIT* okay... peinliche sache -.- es waren tatsächlich die von dir am anfang angezweifelten Klammern schuld... ohne die geht die abfrage auch in 2.5... -.-
Danke an Hyperion für die Hilfe