fejl ved konvertering af varchar til float

Det betyder, at du har mindst én række i tabellen, som ikke kan castes til float . Udførelse af CASE er sikkert, men at kombinere CTE og tilføje en WHERE-klausul falder ind i en almindelig fejlslutning hos programmører, når de skriver T-SQL:at deklarationsrækkefølgen indebærer en udførelsesordre . Programmører er vant til den tvingende proceduremæssige stil i C-lignende sprog og forstår ikke den deklarative sæt-baserede karakter af SQL. Jeg har tidligere skrevet om dette problem og givet eksempler, når fejlslutningen forårsager fejl:

Når du har postet din fulde kode, kan vi se præcis, hvor du lavede fejlslutningen i dit tilfælde og antog en bestemt udførelsesrækkefølge.

efter opdatering

OK, så jeg er nødt til at administrere, at i dit tilfælde er koden korrekt i rækkefølgen for udførelse, result kolonne kan ikke projiceres uden først at evaluere CASE . Havde CASE været i en WHERE-klausul ville tingene have været anderledes.

Dit problem er anderledes:ISNUMERIC . Denne funktion har en meget generøs forståelse af hvad NUMERIC betyder og har bidt mange udviklere før. Den accepterer nemlig værdier, som CAST og CONVERT vil afvise. Som dem, der indeholder et komma:

declare @n varchar(8000) = '1,000';
select isnumeric(@n);
select cast(@n as float);
select case when isnumeric(@n)=1 then cast(@n as float) else null end;

Så du har værdier, der passerer ISNUMERIC test, men kan ikke konvertere. Bare et heads up, jo mere du vil grave i denne tilgang, jo flere lukkede døre vil du finde. Er bare ingen sikker måde at lave den cast, du skal bruge på serversiden. Ideelt set skal du rette datamodellen (gør feltet til et flydende, hvis det gemmer flydere). Kort over det, triage dataene og fjern alle værdier, der ikke er en ordentlig float, og fiks front-end/applikationen til ikke længere at introducere nye, og tilføj derefter en begrænsning, der vil udløse fejlen, hvis nye dårlige værdier vises. Du vil ikke være i stand til at løse dette i en forespørgsel, den vej er fyldt med lig.

Med den næste version af SQL Server får du en ny funktion, TRY_CONVERT , det ville løse dit problem.