Schimbarea nivelului de compatibilitate în timp ce utilizatorii sunt conectați la baza de date poate duce la seturi incorecte de rezultate pentru interogările active. De exemplu, în cazul în care se modifică nivelul de compatibilitate în timpul compilării planul de interogare, planul compilate s-ar putea să se bazeze pe ambele niveluri de compatibilitate vechi și noi, care va avea ca rezultat un plan incorect și rezultate potențial inexacte. Mai mult, problema poate deveni și mai confuză dacă planul este plasat în cache-ul planului și reutilizat pentru interogările ulterioare. Pentru ca interogările să nu producă rezultate incorecte, vă recomandăm să utilizați următoarea procedură pentru a modifica nivelul de compatibilitate al bazei de date.
Mutați baza de date în modul pentru un singur utilizator utilizând ALTER DATABASE SET SINGLE_USER.
Modificați nivelul de compatibilitate al bazei de date.
Mutați baza de date în modul multi-utilizator utilizând instrucțiunea ALTER DATABASE SET MULTI_USER.
Pentru mai multe informații despre setarea modurilor bazei de date, consultați ALTER DATABASE (Transact-SQL).
Când executați o procedură stocată, se utilizează nivelul actual de compatibilitate al bazei de date în care a fost definită. Când se modifică setarea compatibilității bazei de date, toate procedurile stocate din această bază de date sunt recompilate automat.
Această secțiune descrie noile comportamente cauzate de apariția unui nivel de compatibilitate 120.
Nivel de compatibilitate 110 și mai jos
Setarea nivelului de compatibilitate 120
Se folosește vechiul optimizator de interogări.
Dacă nivelurile de compatibilitate sunt mai mici de 120, atunci când convertiți valoarea datei la un parametru șir de limbă nu este luată în considerare. Rețineți că acest comportament este specific doar pentru tipul de dată. De exemplu, următoarea interogare nu ia în considerare instrucțiunea SET LANGUAGE, cu excepția executării la nivelul de compatibilitate 120.
Parametrul de limbă nu este luat în considerare la conversia unei valori de dată la o valoare de șir.
Referințele recursive din partea dreaptă a clauzei EXCEPT creează o buclă infinită. Următorul exemplu demonstrează această situație.
La nivelul de compatibilitate 110 stil implicit are întotdeauna o valoare pentru CAST și Transformați operațiuni pe tipuri de date și timp datetime2 121. În cazul în care solicitarea se bazează pe comportamentul anterior, ar trebui să utilizați nivelul de compatibilitate este mai mică de 110, sau descrie în mod explicit stilul în interogare afectate 0.
Actualizarea bazei de date la nivelul de compatibilitate 110 nu va schimba datele utilizatorului stocate pe disc. Trebuie să corectați aceste date în mod corespunzător manual. De exemplu, dacă utilizați o sumă licitată SELECT INTO pentru a crea un tabel, pe baza sursei care conține coloana de expresie calculată descrisă mai sus, datele vor fi păstrate (pentru stilul 0), în loc de determinare a coloanei calculate în sine. Ar fi necesar să actualizați manual aceste date în conformitate cu stilul 121.
Orice coloane de tabele la distanță de tip smalldatetime. care apar în vizualizarea partiționată, sunt mapate la tipul datetime. Coloanele corespunzătoare tabelelor locale (coloanele care ocupă aceleași poziții ordonate în lista de selecție) trebuie să aibă tipul de dată.
Orice coloane de tabele la distanță de tip smalldatetime. care apar în vizualizarea partajată, sunt mapate la tipul de timp de tip smalldate. Coloanele corespunzătoare tabelelor locale (coloanele care ocupă aceleași poziții ordonate în lista de selecție) trebuie să aibă tipul smalldatetime.
După trecerea la nivelul de compatibilitate 110, vizualizarea distribuită distribuită eșuează din cauza unei nepotriviri de tip de date. Puteți rezolva această problemă modificând tipul de date din tabelul la distanță până la data dată sau setând nivelul de compatibilitate al bazei de date locale la 100 sau mai mic.
Funcția SOUNDEX implementează următoarele reguli.
Caracterele majuscule H și W sunt ignorate dacă separă 2 consoane care au același număr în codul SOUNDEX.
Dacă primele 2 caractere ale expresiei de caractere au același număr în codul SOUNDEX, ambele caractere sunt incluse. În caz contrar, dacă consoana consecutivă stabilită în codul SOUNDEX are același număr, toate sunt excluse, cu excepția primului caracter.
Funcția SOUNDEX implementează următoarele reguli.
Dacă literele (majuscule) H sau W împărtășesc două litere consonante care au același număr în codul SOUNDEX, atunci litera consonantă din dreapta este ignorată.
Dacă setul consoanelor consecutive are același număr în codul SOUNDEX, atunci toate sunt excluse, cu excepția primului caracter.
Funcția SOUNDEX implementează reguli suplimentare, în aplicarea cărora valorile calculate de funcție pot fi diferite de acele valori care au fost calculate la un alt nivel de compatibilitate. După trecerea la nivel de compatibilitate 110, este posibil să trebuiască să reconstruiți indici, grămezi sau CHECK constrângeri care utilizează funcția SOUNDEX. Pentru mai multe informații, consultați SOUNDEX (Transact-SQL).
Atributele speciale xsi: nil și xsi: type nu pot executa interogări sau nu le pot modifica utilizând instrucțiunile DML.
Aceasta înseamnă că expresia / e / @ xsi: nil nu reușește, în ciuda faptului că propunerea / e / * @ xsi atribute: zero și xsi: tip vor fi omise. Cu toate acestea, teza / e returnează atributele xsi: nil și xsi: type pentru consistență cu instrucțiunea SELECT xmlCol. chiar dacă xsi: nil = "false".
Atributele speciale xsi: nil și xsi: sunt stocate ca atribute normale și puteți executa interogări și le puteți modifica.
De exemplu, interogarea SELECT x.query ('a / b / @ *') returnează toate atributele, inclusiv xsi: nil și xsi: type. Pentru a elimina aceste tipuri de cereri, înlocuiți propoziția @ * Oferta @ * [spațiu de nume-uri (.)! = "Insert xsi namespace-uri" și nu (local-name (.) = "Tip" sau local-name (.) = „zero“.
O funcție definită de utilizator care convertește valoarea șirului unei constante XML într-un tip de date SQL Server datetime este marcată ca deterministă.
O funcție definită de utilizator care convertește valoarea șirului unei constante XML într-un tip de date date SQL Server este marcată ca non-deterministă.
Combinația dintre tipurile XML și lista nu este pe deplin acceptată.
Sindicatele și tipurile de liste sunt pe deplin acceptate, inclusiv următoarele funcționalități.
Lista tipurilor atomice
Validarea parametrilor SET necesari pentru metoda xQuery nu se efectuează dacă metoda este inclusă în vizualizare sau în funcția încorporată în tabel.
Validarea parametrilor SET necesari pentru metoda xQuery se efectuează dacă metoda este inclusă în vizualizare sau în funcția încorporată în tabel. Dacă parametrii SET ai metodei nu sunt setați corect, apare o eroare.
Valorile atributului XML care conțin caractere de la sfârșitul liniei (retur de transport și feed de linie) nu sunt normalizate în conformitate cu standardul XML. Astfel, ambele caractere sunt returnate în locul unui caracter de alimentare cu un rând.
Valorile atributului XML care conțin caractere de la sfârșitul liniei (retur de transport și feed de linie) sunt normalizate în conformitate cu standardul XML. Astfel, toate caracterele din șirul capăt de analizat în entități externe (inclusiv entitatea document), normalizate la intrare, transformând secvența două caractere #xD #xA #xD și simboluri, nu au fost urmate de simbolul #xA, într-un singur #xA caracter.
Aplicațiile care utilizează atribute pentru a muta valorile șirului care conțin caractere de la sfârșitul liniei nu primesc aceste caractere înapoi, deoarece acestea au fost transferate. Pentru a preveni acest proces de normalizare, utilizați entități XML numerice pentru a codifica toate caracterele terminale.
Proprietățile coloanelor ROWGUIDCOL și IDENTITY pot fi denumite în mod incorect constrângeri. De exemplu, instrucțiunea CREATE TABLE T (CI int CONSTRAINT MyConstraint IDENTITY) este executată, dar numele constrângerii nu este stocat și nu este disponibil pentru utilizator.
Proprietățile coloanelor ROWGUIDCOL și IDENTITY nu pot fi numite constrângeri. Eroarea 156 este returnată.
Actualizarea coloanelor utilizând o alocare bidirecțională, cum ar fi UPDATE T1 SET @v = column_name =
Acest comportament este valabil numai dacă nivelul de compatibilitate este de 90.
Actualizarea coloanelor utilizând alocarea în ambele sensuri are ca rezultat rezultatele așteptate, deoarece numai valoarea inițială a coloanei din instrucțiune este accesată în timpul executării instrucțiunii.
Alocarea unei valori variabile este permisă într-o instrucțiune care conține un operator UNION de nivel superior, dar returnează rezultate neașteptate. De exemplu, în următoarele afirmații, variabila locală @v are atribuită valoarea coloanei BusinessEntityID din asocierea a două tabele. Dacă instruciunea SELECT returnează mai multe valori, variabila este atribuită ultima valoare returnată. În acest caz, variabila este atribuită corect ultima valoare, dar setul de rezultate al instrucțiunii SELECT UNION se întoarce, de asemenea.
Trimiteți-le prietenilor: