ibh_compucat - Di 30.03.10 14:01
Titel: Integer in SQL STring übergeben

---

Hallo,

wie kann man in einem SQL-String einen Wert an ein Integer-Feld in der Zieltabelle übergeben?



wobei das Feld Telefonnr in der Zieltabelle z.B. Integer ist.

Gruß ibh_compucat

Xentar - Di 30.03.10 14:07

---

Arbeite mit Parametern.


Der Doppelpunkt gibt an, dass es sich um einen Parameter mit folgendem Namen handelt, diesem Parameter kannst du anschließend einen Wert zuweisen.

artelogic - Di 30.03.10 14:22

---

vorausgesetzt deine Variable, die die Telefonnummer enthält ist auch integer, sonst



Wobei die Telefonnummer ja sicherlich ursprünglich per Eingabe aus'm TEdit.Text kommt und damit string ist?

ibh_compucat - Di 30.03.10 14:32

---

Danke für Eure Antworten,

@Xentar: ich bekomm' nur die Auswahl (mit der Programmierhilfe) Query1.Parameters, ParamByNames bietet er mir nicht an. Muss man da etwas vorbereiten?

@artelogic:
die Richtung ist die, die mir vorschwebt, aber mein Zielfeld in der Zieltabelle ist numerisch. Dein Vorschlag wandelt mir den zu übertragenden Wert in einen String (für den SQL-String) um. Aber wie erfährt meine Zieltabelle, dass der Wert nun wieder numerisch umgewandelt werden muss für das Tabellenfeld(Integer)?

Gruß ibh_compucat

artelogic - Di 30.03.10 14:41

---

Das weiß der SQL-Server, der den SQL-String empfängt und verarbeitet!

Critter - Di 30.03.10 14:41

---

Hallo,

ibh_compucat hat folgendes geschrieben :

die Richtung ist die, die mir vorschwebt, aber mein Zielfeld in der Zieltabelle ist numerisch. Dein Vorschlag wandelt mir den zu übertragenden Wert in einen String (für den SQL-String) um. Aber wie erfährt meine Zieltabelle, dass der Wert nun wieder numerisch umgewandelt werden muss für das Tabellenfeld(Integer)?

SQL-Anweisungen sind immer Strings, wenn das Zielfeld als Numerisch angelegt ist, dann ist es Aufgabe deiner Datenbank das zu erkennen und den entsprechendes Teil des Querys wieder in eine Zahl zu wandeln. Da musst du dich nicht drum kümmern.

critter

PS: Telefonnummern-Felder sollten genau so wenig wie PLZ-Felder als Integer gespeicher werden, denn wie willst du in einem Int Feld die 04912345678 von der 004912345678 unterscheiden? Außerdem mögen Nutzer es meist nicht, wenn ihre schön formatierte Eingabe (01234/56789-10) der Formatierungszeichen beraubt wird.

ibh_compucat - Di 30.03.10 15:17

---

Hallo an alle Helfer,

Die Datenbank (MS-SQL Server) wandelt tatsächlich selber den Wert in das passende Format um, man braucht also nur lokale numerische Werte in Strings für den SQL String umzuwandeln. Und das ist ja kein Problem.
Nochmal vielen Dank an alle!

Gruß ibh_compucat

Martok - Di 30.03.10 16:11

---

Naja, Parameter wären schon richtiger geweisen. Schon allein, um nicht ganz so große SQL-Injection-Scheunentore offen zu lassen.

Critter hat folgendes geschrieben :

PS: Telefonnummern-Felder sollten genau so wenig wie PLZ-Felder als Integer gespeicher werden, denn wie willst du in einem Int Feld die 04912345678 von der 004912345678 unterscheiden?

Soweit richtig, aber:

Critter hat folgendes geschrieben :

Außerdem mögen Nutzer es meist nicht, wenn ihre schön formatierte Eingabe (01234/56789-10) der Formatierungszeichen beraubt wird.

Wer Formatierungszeichen mitspeichert gehört gevierteilt, gefedert, geteert und mit Vorlesungsmanuskripten Datenbanken geschlagen.

Die sollten bei der Eingabe entfernt und zur Anzeige wieder eingefügt werden. Wie willst du sonst 004912345678 und +49-12345-678 als gleich erkennen? Bei OpenStreetMap gibts da einen Artikel [http://wiki.openstreetmap.org/wiki/Key:phone] zum Thema, der die verschiedenen Formate und Hinweise zum Parsen gibt.

Critter - Mi 31.03.10 15:53

---

Hi,

Martok hat folgendes geschrieben :

Die sollten bei der Eingabe entfernt und zur Anzeige wieder eingefügt werden. Wie willst du sonst 004912345678 und +49-12345-678 als gleich erkennen?

Um ehrlich zu sein, ich speichere Telefonnummern meist zweifach, einmal in der Form, wie der user sie eingibt sowie in einer Normierten Variante. Ich empfände es als eine unverschämte Bevormundung des Users seine Eingabe in eine Standardform zu bringen. Gerade Durchwahlen könnte ich auch nicht automatisch erkennen, da muss ich mich auf die Benutzereingabe verlassen (und auch bei der habe ich schon die komischsten Trennzeichen gesehen). Suchen und Vergleiche mache ich natürlich auf der Normierten Form, anzeigen tue ich was der User eingegeben hat, es sei denn es wird eine Bestimmte Darstellung für die Ausgabe bevorzugt die kann man dann aber in der Regel aus der Normierten Form erstellen.
Natürlich gibt es ausnahmen, wenn von Auftraggeber eine bestimmte Eingabeform definiert wird, dann passe ich natürlich auf, dass der User sich an diese halten muss, im allgemeinen finde ich aber, das sich eher das Programm anpassen soll und nicht der Nutzer.

critter

artelogic - Mi 31.03.10 16:05

---

:zustimm: :zustimm: :zustimm:

Martok - Mi 31.03.10 16:35

---

Critter hat folgendes geschrieben :

Hi,

Hai.

Critter hat folgendes geschrieben :

Um ehrlich zu sein, ich speichere Telefonnummern meist zweifach, einmal in der Form, wie der user sie eingibt sowie in einer Normierten Variante.

So gehts natürlich auch. Ist zwar fast noch weniger "nach Lehrbuch", aber immerhin praktisch.
Ich muss zugeben, dass ich bisher das Problem nicht so hatte. Datumsfelder sind ja da doch freundlicher; bisher ließ sich das immer alles auf unformatierte Daten abbilden. Wobei ich bei Teilenummern schonmal ein ähnliches Problem hatte. Die betreffenden kann man entweder ohne Trenner, mit Leerzeichen oder mit Punkten schreiben. War dann so, dass ich nur die Ziffern speichere und wie oben geschrieben in ein MaskEdit werfe.

Critter hat folgendes geschrieben :

im allgemeinen finde ich aber, das sich eher das Programm anpassen soll und nicht der Nutzer.

Okay, so war das auch nicht gemeint. Mit der von dir beschriebenen Variante hat man dann auch einen guten Kompromiß zwischen starrsinnigen Usern und dem was man als Entwickler sinnvoll findet :)