verwendetes Datenbanksystem: SQL Compact 3.5
Hallo,
ich sitze gerade an einer Anwendung die mit SQL Compact arbeitet. - SELECT's funktionieren ohne Probleme.
Auch der Insert funktioniert, solang ich eine Spalte nicht mit angebe.
meine Methode hat folgenden Inhalt:
_connection.Open();
try
{
SqlCeCommand command = new SqlCeCommand();
command.Connection = _connection;
String commandString = "INSERT INTO [User] (UserName, UserFName, UserLName, UserMail, Group, Password)";
commandString += " Values('" + userName + "', '" + userFName + "', '" + userLName + "', '" + userMail + "', '" + group + "', '" + userName + "')";
command.CommandText = commandString;
command.ExecuteScalar();
}
finally
{
_connection.Close();
}
Ein Problem hat die Abfrage mit der Spalte "Group". Ich erhalte folgende Exception, kann diese aber nicht wirklich nachvollziehen:
Fehler beim Analysieren der Abfrage. [ Token line number = 1,Token line offset = 63,Token in error = Group ]
Ich hoffe ihr könnt mir helfen.
Wissen ist nicht alles. Man muss es auch anwenden können.
PS Fritz!Box API - TR-064 Schnittstelle | PS EventLogManager |
Hallo,
vielleicht macht dir die Spalte Probleme weil sie einen ungeschickten Namen hat.
Denn Group könnte möglicherweise nicht erlaubt sein da er glaubt du willst gruppieren (Group by)
Bin mir da aber nicht sicher, ob es wirklich ein Problem macht.
Zudem kann ich dir nur nahelegen SqlParameter zu verwenden.
Dann spart man sich viele Probleme die beim zusammenfügen der Query entstehen.
Siehe: System.Data.SqlService.SqlCeCommand.Parameters
Gruß
Michael
Group war das Problem. Danke.
Auch die Sache mit den Parametern werde ich übernehmen.
Wissen ist nicht alles. Man muss es auch anwenden können.
PS Fritz!Box API - TR-064 Schnittstelle | PS EventLogManager |
Hallo inflames2k,
ich kann michlG's Verumutung bestätigen und mittlerweile auch deinige. group ist daduch ein Problem denn es is ein reserviertes Keyword und kann so nicht verwendet werden. Wenn du group verwenden willst schreibe [group].
Siehe : SqlServer Reserverd Keywords. Ich rate dir desshalb von der Verwednung eines solchen Spaltennamens ab.
Um wirklich Probleme zu vermeiden solltest du SqlParameter verweden.
Du bist nicht der einzige dem ich und andere dies vorschlagen. So gut wie jeder der Probleme mit SQL-Queries hat verwendet keine SqlParameter. Obwohl sich die primären ersichtlichen Vorteile sich auf die bessere Lesbarkeit beschränken sind die weiteren Vorteile der Bereich Sicherheit. Ich will damit nicht sagen dass dein Problem mit der nicht Verwendung von Parameter zusammenhängt, denn die Query ist ja diesbezüglich korrekt.
Gruß
Michael
Ich frag mich nur warum dann ein solcher Spaltenname überhaupt erlaubt ist und nicht sofort gemeckert wird...
Das mit den Parametern ist mir ja durchaus bewusst. - Die hätte ich ja mehr oder minder sowieso verwendet, die implementation wie oben war nur um zu schauen ob ich die Daten auch schreiben kann und nicht an anderer Stelle (Bspw. definition der Spalten) mist gebaut habe.
Im Unternehmen arbeiten wir ja auch mit Parametern.
Wissen ist nicht alles. Man muss es auch anwenden können.
PS Fritz!Box API - TR-064 Schnittstelle | PS EventLogManager |
Zu Parametern gibt es hier auch einen Artikel [Artikelserie] Parameter von SQL Befehlen
fz
"We better hurry up and start coding, there are going to be a lot of bugs to fix."
Es werden solche Spaltennamen erlaubt, um faule Entwickler nicht zu sehr dazu bewegen zu müssen, mal nachzudenken.
Oder um legacy Anwendungen bei Portierungen zu unterstützen.
Und um solche Spalten dennoch ansprechen zu können gibt es in jedem SqlDialekt dann Maskierungszeichen, bei MSSql ist das [].