MySql Fehlermeldung

S

Simi

Angesehenes Mitglied
Hi all,

Kann mir jemand sagen, was für eine Fehlermeldung das ist?

Ichi finde keinen Fehler in meinem Code:

CODE
#1054 - Unknown column 'ìd' in 'field list'



Kennt jemand von euch evtl. eine gute MySql Seite?

Danke und Gruss
Simone

PS: Ich hab ausnahmsweise nicht gründlich gegooglet!
 
Ist doch ganz einfach: Die Spalte 'ìd' ist nicht vorhanden. Überprüf mal den SQL-Query auf einen Typo. Oder verwendest du Umlaute/nicht-ASCII-Zeichen im Spaltennamen?

Gruß
David
 
Joah, sieht nach einem Umlaut aus, der zwischen UTF8 und iso-8859-x irgendwo verreckt ist.

Umlaute sollten grundsätzlich nie in Variabel, Spalten -und Datenbanknamen verwendet werden.
 
QUOTE (Alonso @ So 13.8.2006, 23:38)Umlaute sollten grundsätzlich nie in Variabel, Spalten -und Datenbanknamen verwendet werden.

Das gilt nicht im allgemeinen. Der Microsoft-SqlServer verträgt schon seit mindestens 2000 Unicode in den Spaltennamen, auch mit NET kann man von Anfang an Umlaute verwenden.

Es handelt sich also wohl bloß um ein PHP-Problem, in mySql konnten die Spalten ja wahrscheinlich entsprechend angelegt werden.
 
QUOTE Umlaute sollten grundsätzlich nie in Variabel, Spalten -und Datenbanknamen verwendet werden.


Meiner Meinung nach ist das allgemein richtig, einfach weil man selbst wenn man es in einer momentanen Situation verwenden kann können schnell Probleme bekommen kann wenn man an der verwendeten Technologie etwas verwenden will. Daneben kann es so unangenehme „Kleinigkeiten“ wie z.B. Tools die keine Umlaute unterstützen geben.

Daneben zahlt es sich auch aus Datenbanken + Sourcecode-Kommtentare in Englisch zu halten um auch im Entwicklerteam flexibel zu sein.
Aus Entwicklersicht kann man das natürlich umgekehrt machen damit der eigene Arbeitsplatz nicht so leicht verlagert werden kann ;-)
 
QUOTE (Alonso @ Mo 14.8.2006, 0:38)Umlaute sollten grundsätzlich nie in Variabel, Spalten -und Datenbanknamen verwendet werden.

Genau meine Meinung. Ich verwende nie Umlaute im Code und in der DB und hab mir damit schon so manchen Ärger bei Umstellungen oder Systemänderungen erspart. Sogar bei Filenamen (fürs Web) vermeide ich Umlaute, denn es kann immer Umgebungen geben, wo Umlaute Probleme machen.

Griessli
Irene
 
QUOTE (jAuer @ Mo 14.8.2006, 8:55)
QUOTE (Alonso @ So 13.8.2006, 23:38)Umlaute sollten grundsätzlich nie in Variabel, Spalten -und Datenbanknamen verwendet werden.

Das gilt nicht im allgemeinen. Der Microsoft-SqlServer verträgt schon seit mindestens 2000 Unicode in den Spaltennamen, auch mit NET kann man von Anfang an Umlaute verwenden.

Das hatte ich mal mitbekommen, ja. Habe aber kein gutes Gewissen dabei. Ich denke kaum das die Entwickler ihre Software selbst mit fremden Zeichensätzen bis ans Limit durchtesten.

Umlaut-Domains gibts ja z.B. auch schon länger.. (Der Rest sollte ja bekannt sein)
biggrin.gif


Ist sicher eine Frage der persönlichen Einstellung. Ich für meinen Teil schliesse mich Irene und hatschi an, da ich so bisher nur gute Erfahrungen gemacht habe, ohne grosse Kompromisse.
 
Ich stimme Euch dreien zu, sofern es um Code geht, der nur von Programmierern gesehen bzw. gewartet wird. Bei meinem, auf NET und MS-Sql-2000 basierenden Hauptangebot der Web-Datenbank halte ich mich an dieselben Regeln, sofern es um die internen Tabellen und Prozedurnamen geht: Namen englisch, nur Ascii-Zeichen.

Nur: Bei mir können Kunden eigene Tabellen erstellen. Zu jeder Tabelle gibt es einen Satz von gespeicherten Prozeduren, der Name der Prozedur nutzt den Tabellennamen, Spaltennamen tauchen als Parameternamen auf.

Da ist es ein erheblicher Unterschied, ob ich da Ascii fordere oder ob ich bsp. Umlaute und diverse andere Zeichen aus den entsprechenden Unicode-Kategorien der Unicode-Version 2.1 erlauben kann.

Und das gelingt eben problemlos - sowohl mit dem MS-Sql-2000 als auch mit .NET, wo alle Strings von vornherein Unicode-Strings sind. Die oben auftretenden PHP-Probleme erinnern mich an jene gruseligen C-Zeiten (bsp. API-Aufrufe aus VB6), bei denen man zwischen Ascii- oder Unicode-Funktionen (substringA/substringW) wählen muß oder bei dem es zu Sicherheitslücken kommt, weil ein WChar* doppelt so lang ist wie ein Char*.
 
QUOTE (jAuer @ Mo 14.8.2006, 11:54)Nur: Bei mir können Kunden eigene Tabellen erstellen.


Das ist natürlich ein Sonderfall, und dafür sind SQL Server und Dotnet super geeignet. Ich möchte sowas nicht mit Oracle umsetzen müssen
wacko.gif


Aber ich fänds noch schick, wenn man das einstellen könnte; also so ein Flag "AsciiDurchsetzen", analog zum "Option Strict". Das würde dem Entwickler die Disziplin erleichtern ;-)

Griessli
Irene
 
Ich verwende keine Umlaute sei es im Code wie auch Datenbank. Ich habe den Code wieder geschrieben und hat funktioniert. Keine Ahnung was falsch war.

QUOTE
Die MySql referenz in Deutsch gibts hier!

Gruß Ronny



Danke Ronny! und natürlich allen die mir geholfen haben.

Gruss
Disastro
 
Sie müssen sich einloggen oder registrieren, um hier antworten zu können.
Zurück
Oben