CONVERT Char in FLOAT/INT

[BaseBallBatBoy]

Welche collation brauchst du denn? SQL_Latin1_General_CP1_CI_AS? Unicode?


Zudem habe ich mal in deinem Beispiel nach den unterschiedlichen Typen gesucht und diese gefunden:

INSERT INTO t ([wert]) VALUES ('10500.00');
INSERT INTO t ([wert]) VALUES ('16409.80');
INSERT INTO t ([wert]) VALUES ('2326.12');
INSERT INTO t ([wert]) VALUES ('0');
INSERT INTO t ([wert]) VALUES ('1650.');
INSERT INTO t ([wert]) VALUES ('1900');
INSERT INTO t ([wert]) VALUES ('max400proMonat');
INSERT INTO t ([wert]) VALUES ('625');
INSERT INTO t ([wert]) VALUES ('1750.00+250');

Wenn ich mir das so anschaue, kann ich nicht verstehen, warum du denn auch Replace machst für '€', 'EUR', ',' und '-'. Ich gehe mal davon aus dein Beispiel ist nicht vollständig?

 

[BaseBallBatBoy]

Noch einmal ein Nachtrag:
http://sqlfiddle.com/#!3/9f8a4/5

item1: gehe iterativ vor wie in meinem Beispiel indem du die Komplexität immer weiter erhöhst.

item2: CONVERT ist SQL Server spezifisch, CAST ist ANSI. CONVERT kann noch etwas mehr beim Formatieren eines Datums, ansonsten sind sie gleich. In dem Fall brauchst du diese Funktionalität nicht und somit schlage ich vor brauche CAST.

item3: Anstelle vom Filter für non-numeric könntest du auch einen case brauchen: CASE WHEN ISNUMERIC(wert) = 1 THEN CAST(....) ELSE 0 END

item4: DECIMAL und NUMERIC sind was den SQL Server betrifft funktional gleich. Der SQL-92 Standard beschreibt decimal als 'exactly as precise as declared' und numeric als 'at least as precise as declared'. In SQL Server sind beide 'exactly as precise as declared', sprich numeric braucht nicht die Flexibilität welche der Standard erlauben würde. Somit schlage ich vor brauche DECIMAL.

item5: Da ich deine Daten nicht kenne habe ich mal geraten und DECIMAL(18,2) gewählt. Wenn du aber z.B. mehr Kommastellen hast, müsste das noch ergänzt werden.