Namnlösning

Gäller för: markerad ja Databricks SQL Databricks Runtime

Namnlösning är den process som identifierare löses till specifika kolumn-, fält-, parameter- eller tabellreferenser.

Kolumn-, fält-, parameter- och variabelupplösning

Identifierare i uttryck kan vara referenser till något av följande:

Kolumnnamn baserat på en vy, tabell, ett vanligt tabelluttryck (CTE) eller en column_alias.
Fältnamn eller kartnyckel i en struct eller karta. Fält och nycklar kan aldrig vara utan kvalifikationer.
Parameternamn för en SQL-användardefinierad funktion eller SQL-procedur.
Lokalt variabelnamn för sessions- eller SQL-skript.
En särskild funktion som current_user eller current_date som inte kräver användning av ().
Nyckelordet DEFAULT som används i kontexten för INSERT, UPDATE, MERGEeller SET VARIABLE för att ange ett kolumn- eller variabelvärde till standardvärdet.

Namnuppslagning tillämpar följande principer:

Den närmaste matchande referensen vinner och
Kolumner och parameter vinner över fält och nycklar.

I detalj följer lösningen av identifierare till en specifik referens dessa regler i ordning:

Lokala referenser
1. Kolumnreferens
  
  Matcha identifieraren, som kan vara kvalificerad, med ett kolumnnamn i en tabellreferens för FROM clause.
  
  Om det finns fler än en sådan matchning ska ett AMBIGUOUS_COLUMN_OR_FIELD-fel visas.
2. Parameterlös funktionsreferens
  
  Om identifieraren är okvalificerad och matchar current_user, current_dateeller current_timestamp: Lös det som en av dessa funktioner.
3. standardspecifikation för kolumn
  
  Om identifieraren är okvalificerad matchar den default och utgör hela uttrycket i kontexten av en UPDATE SET, INSERT VALUESeller MERGE WHEN [NOT] MATCHED: Lös det som det respektive DEFAULT-värdet för måltabellen i INSERT, UPDATE eller MERGE.
4. Referens för strukturfält eller mappnyckel
  
  Om identifieraren är kvalificerad ska du försöka matcha den med ett fält eller en kartnyckel enligt följande steg:
  
  A. Ta bort den sista identifieraren och behandla den som ett fält eller en nyckel. B. Matcha resten med en kolumn i tabellreferens för FROM clause.
  
  Om det finns fler än en sådan matchning ska ett AMBIGUOUS_COLUMN_OR_FIELD-fel visas.
  
  Om det finns matchning och kolumnen är en:
  - STRUCT: Anpassa fältet.
    
    Om fältet inte kan matchas skapar du ett FIELD_NOT_FOUND fel.
    
    Om det finns fler än ett fält skapar du ett AMBIGUOUS_COLUMN_OR_FIELD fel.
  - MAP: Generera ett fel om nyckeln är kvalificerad.
    
    Ett körningsfel kan inträffa om nyckeln inte finns på kartan.
  - Annan typ: Utlösa ett fel. C. Upprepa föregående steg för att ta bort den avslutande identifieraren som ett fält. Tillämpa regler (A) och (B) medan det finns en identifierare kvar att tolka som en kolumn.
Lateral kolumnalias

Gäller för: Databricks SQL Databricks Runtime 12.2 LTS och senare

Om uttrycket finns i en SELECT-lista, ska den inledande identifieraren matchas med ett föregående -kolumnalias i den SELECT-listan.

Om det finns fler än en sådan matchning genereras ett AMBIGUOUS_LATERAL_COLUMN_ALIAS-fel.

Matcha varje återstående identifierare som ett fält eller en nyckel i en kartstruktur och utlös felet FIELD_NOT_FOUND eller AMBIGUOUS_COLUMN_OR_FIELD om de inte kan matchas.
Korrelation
- LATERAL
  
  Om frågan föregås av ett LATERAL nyckelord tillämpar du reglerna 1.a och 1.d med tanke på tabellreferenserna i FROM som innehåller frågan och före LATERAL.
- Vanligt
  
  Om frågan är en skalär underfråga, IN, eller EXISTS underfråga tillämpar du reglerna 1.a, 1.d och 2 med tanke på tabellreferenserna i den innehållande frågans sats FROM .
Kapslad korrelation

Gäller för: Databricks SQL Databricks Runtime 20.0 och högre

Tillämpa regel 3 igen, iterera över sökningens nästlade nivåer, så att en identifierare kan lösa sig till en korrelerad referens i vilken omslutande fråga som helst, inte bara den omedelbart omslutande.
FOR-loop

Om påståendet finns i en FOR-loop:

A. Matcha identifieraren med en kolumn i en FOR loop-instruktionsfråga. Om identifieraren är kvalificerad måste kvalificeraren matcha namnet på FOR-loopvariabeln om den definieras. B. Om identifieraren är kvalificerad matchar du ett fält eller en mappnyckel för en parameter enligt regel 1.c
Sammansatt sats

Om uttalandet ingår i ett sammansatt block:

A. Matcha identifieraren med en variabel som deklarerats i den sammansatta instruktionen. Om identifieraren är kvalificerad måste kvalificeraren matcha etiketten för den sammansatta instruktionen, om en sådan har definierats. B. Om identifieraren är kvalificerad, matcha en fält- eller mappnyckel hos en variabel enligt regel 1.c
kapslad sammansatt sats eller FOR-loop

Tillämpa reglerna 5 och 6 igen och iterera över kapslingsnivåerna i den sammansatta satsen.
Rutinparametrar

Om uttrycket är en del av en CREATE FUNCTION eller CREATE PROCEDURE-instruktion :
1. Matcha identifieraren med ett parameternamn. Om identifieraren är kvalificerad måste kvalificeraren matcha namnet på rutinen.
2. Om identifieraren är kvalificerad matchar du ett fält eller en mappnyckel för en parameter enligt regel 1.c
Sessionsvariabler
1. Matcha identifieraren med ett variabelnamn. Om identifieraren är kvalificerad måste kvalificeraren vara session eller system.session. I Databricks SQL och Databricks Runtime 19 och högre matchar en okvalificerad identifierare en sessionsvariabel endast om system.session den finns på PATH.
2. Om identifieraren är kvalificerad, matcha en fält- eller mappnyckel hos en variabel enligt regel 1.c

Namnmatchning i `HAVING`, `ORDER BY`och `QUALIFY`

HAVINGSatserna , ORDER BYoch QUALIFY kan referera till namn från SELECT listan samt kolumner från de underliggande tabellerna. När ett namn i någon av dessa satser matchar både ett kolumnalias i SELECT listan och en tabellkolumn löser satserna tvetydigheten på ett annat sätt:

ORDER BYföredrar listalias framförSELECT tabellkolumnen.
HAVING föredrar tabellkolumnen framför listaliaset SELECT .
QUALIFY föredrar tabellkolumnen framför listaliaset SELECT (samma som HAVING).

Exempel

> CREATE OR REPLACE TEMPORARY VIEW t(a, b) AS VALUES (1, 10), (2, 20), (3, 30);

-- ORDER BY prefers the alias over the column.
-- 'a' in ORDER BY refers to the alias (-a), not column 'a',
-- so the row with the largest column 'a' comes first.
> SELECT -a AS a FROM t ORDER BY a LIMIT 1;
  -3

-- HAVING prefers the column over the alias.
-- 'a' in HAVING refers to column 'a', not the alias sum(b).
> SELECT sum(b) AS a FROM t GROUP BY a HAVING a > 1;
  20
  30

-- QUALIFY prefers the column over the alias (same as HAVING).
-- 'a' in QUALIFY refers to column 'a', not the alias -row_number().
> SELECT -row_number() OVER (ORDER BY b) AS a FROM t QUALIFY a > 1;
  -2
  -3

Prioritet för fältextrahering och namnmatchning

När ett kvalificerat namn, a.b till exempel används i HAVING eller ORDER BY, gäller fortfarande prioritetsreglerna ovan, men med ytterligare övervägande: den föredragna kandidaten måste ha stöd för extrahering av struct-fält eller kartnyckel. Om den inte gör det används den andra kandidaten i stället.

Om aliaset a till exempel matchas till en oformaterad INT men tabellkolumnen a är ett STRUCT med fält xORDER BYväljer du STRUCT kolumnen eftersom ett fält inte kan extraheras från aliasetINT. Om tabellkolumnen däremot är oformaterad INT och aliaset är ett STRUCT, HAVING återgår du till aliaset för fältextrahering.

Exempel

-- ORDER BY fallback: the table column is a STRUCT, the alias is an INT.
-- ORDER BY normally prefers the alias, but the alias (INT) cannot have
-- field 'x' extracted, so the struct column wins.
> CREATE OR REPLACE TEMPORARY VIEW s1(a) AS VALUES (named_struct('x', 1)), (named_struct('x', 2));

> SELECT -a.x AS a FROM s1 ORDER BY a.x LIMIT 1;
  -1

-- HAVING fallback: the table column is an INT, the alias is a STRUCT.
-- HAVING normally prefers the table column, but the column (INT) cannot have
-- field 'x' extracted, so the alias wins.
> CREATE OR REPLACE TEMPORARY VIEW s2(a) AS VALUES (1), (2);

> SELECT named_struct('x', 2) AS a FROM s2 GROUP BY a HAVING a.x > 1;
  {"x":2}
  {"x":2}

-- Map key extraction follows the same rules.
-- ORDER BY fallback: alias (INT) cannot have key extracted, map column wins.
> CREATE OR REPLACE TEMPORARY VIEW s3(a) AS VALUES (map('key', 100)), (map('key', 200));

> SELECT -a['key'] AS a FROM s3 ORDER BY a['key'] LIMIT 1;
  -100

-- HAVING fallback: column (INT) cannot have key extracted, map alias wins.
> CREATE OR REPLACE TEMPORARY VIEW s4(a) AS VALUES (100), (200);

> SELECT map('key', 200) AS a FROM s4 GROUP BY a HAVING a['key'] > 100;
  {"key":200}
  {"key":200}

Begränsningar

I Databricks SQL och Databricks Runtime 20.0 och senare stöds nästlad korrelation (en delfråga som refererar till kolumner från en innesluten fråga bortom dess närmaste förälder), med följande begränsningar:

Nästlad korrelation stöds inte för delfrågor i en HAVING klausul.
En LATERAL delfråga kan inte vara nästlad-korrelerad. Dess yttre referenser måste lösas till den direkt omslutande frågan.

I Databricks Runtime-versioner under 20.0 är korrelationen begränsad till en enda nivå: en delfråga kan endast referera till kolumner från den fråga som omedelbart omsluter den.

Exempel

-- Differentiating columns and fields
> SELECT a FROM VALUES(1) AS t(a);
 1

> SELECT t.a FROM VALUES(1) AS t(a);
 1

> SELECT t.a FROM VALUES(named_struct('a', 1)) AS t(t);
 1

-- A column takes precedence over a field
> SELECT t.a FROM VALUES(named_struct('a', 1), 2) AS t(t, a);
 2

-- Implict lateral column alias
> SELECT c1 AS a, a + c1 FROM VALUES(2) AS T(c1);
 2  4

-- A local column reference takes precedence, over a lateral column alias
> SELECT c1 AS a, a + c1 FROM VALUES(2, 3) AS T(c1, a);
 2  5

-- A scalar subquery correlation to S.c3
> SELECT (SELECT c1 FROM VALUES(1, 2) AS t(c1, c2)
           WHERE t.c2 * 2 = c3)
    FROM VALUES(4) AS s(c3);
 1

-- A local reference takes precedence over correlation
> SELECT (SELECT c1 FROM VALUES(1, 2, 2) AS t(c1, c2, c3)
           WHERE t.c2 * 2 = c3)
    FROM VALUES(4) AS s(c3);
  NULL

-- An explicit scalar subquery correlation to s.c3
> SELECT (SELECT c1 FROM VALUES(1, 2, 2) AS t(c1, c2, c3)
           WHERE t.c2 * 2 = s.c3)
    FROM VALUES(4) AS s(c3);
 1

-- Correlation from an EXISTS predicate to t.c2
> SELECT c1 FROM VALUES(1, 2) AS T(c1, c2)
    WHERE EXISTS(SELECT 1 FROM VALUES(2) AS S(c2)
                  WHERE S.c2 = T.c2);
 1

-- Nested correlation: the innermost EXISTS references t1.a from the outermost query
> CREATE OR REPLACE TEMPORARY VIEW t1(a) AS VALUES(1), (2), (3);
> CREATE OR REPLACE TEMPORARY VIEW t2(b) AS VALUES(1), (2);
> CREATE OR REPLACE TEMPORARY VIEW t3(c) AS VALUES(2), (3);

> SELECT a FROM t1
    WHERE EXISTS(SELECT 1 FROM t2
                  WHERE t2.b = t1.a
                    AND EXISTS(SELECT 1 FROM t3
                                WHERE t3.c = t1.a));
 2

-- Attempt a lateral correlation to t.c2
> SELECT c1, c2, c3
    FROM VALUES(1, 2) AS t(c1, c2),
         (SELECT c3 FROM VALUES(3, 4) AS s(c3, c4)
           WHERE c4 = c2 * 2);
 [UNRESOLVED_COLUMN] `c2`

-- Successsful usage of lateral correlation with keyword LATERAL
> SELECT c1, c2, c3
    FROM VALUES(1, 2) AS t(c1, c2),
         LATERAL(SELECT c3 FROM VALUES(3, 4) AS s(c3, c4)
                  WHERE c4 = c2 * 2);
 1  2  3

-- Referencing a parameter of a SQL function
> CREATE OR REPLACE TEMPORARY FUNCTION func(a INT) RETURNS INT
    RETURN (SELECT c1 FROM VALUES(1) AS T(c1) WHERE c1 = a);
> SELECT func(1), func(2);
 1  NULL

-- A column takes precedence over a parameter
> CREATE OR REPLACE TEMPORARY FUNCTION func(a INT) RETURNS INT
    RETURN (SELECT a FROM VALUES(1) AS T(a) WHERE t.a = a);
> SELECT func(1), func(2);
 1  1

-- Qualify the parameter with the function name
> CREATE OR REPLACE TEMPORARY FUNCTION func(a INT) RETURNS INT
    RETURN (SELECT a FROM VALUES(1) AS T(a) WHERE t.a = func.a);
> SELECT func(1), func(2);
 1  NULL

-- Lateral alias takes precedence over correlated reference
> SELECT (SELECT c2 FROM (SELECT 1 AS c1, c1 AS c2) WHERE c2 > 5)
    FROM VALUES(6) AS t(c1)
  NULL

-- Lateral alias takes precedence over function parameters
> CREATE OR REPLACE TEMPORARY FUNCTION func(x INT)
    RETURNS TABLE (a INT, b INT, c DOUBLE)
    RETURN SELECT x + 1 AS x, x
> SELECT * FROM func(1)
  2 2

-- All together now
> CREATE OR REPLACE TEMPORARY VIEW lat(a, b) AS VALUES('lat.a', 'lat.b');

> CREATE OR REPLACE TEMPORARY VIEW frm(a) AS VALUES('frm.a');

> CREATE OR REPLACE TEMPORARY FUNCTION func(a INT, b int, c int)
  RETURNS TABLE
  RETURN SELECT t.*
    FROM lat,
         LATERAL(SELECT a, b, c
                   FROM frm) AS t;

> VALUES func('func.a', 'func.b', 'func.c');
  a      b      c
  -----  -----  ------
  frm.a  lat.b  func.c

Tabell- och vyhantering

En identifierare i tabellreferens kan vara något av följande:

Beständiga tabeller eller vyer i Unity-katalogen eller Hive-metaarkivet
Gemensamt tabelluttryck (CTE)
Tillfällig vy eller tillfällig tabell

Lösningen på en identifierare beror på om den är kvalificerad:

Kvalificerad

Om identifieraren är fullständigt kvalificerad med tre delar: catalog.schema.relationär den unik.

Om identifieraren består av två delar: schema.relation, är den ytterligare kvalificerad med resultatet av SELECT current_catalog() för att göra den unik.

Om schemat är session, kvalificeras det vidare med system och tolkas som en tillfällig vy eller tillfällig tabell. Om schemat är global_temp, kvalificeras det vidare med system och tolkas som en global tillfällig vy i Databricks Runtime.

Okvalificerad

gemensamt tabelluttryck

Om referensen ligger inom omfånget för en WITH-sats matchar du identifieraren med en CTE som börjar med den omedelbart innehållande WITH-satsen och flyttar utåt därifrån.

Schemasökväg

I Databricks SQL och Databricks Runtime 19 och uppåt kvalificerar man relationen med varje schema på PATH, i ordning, tills en träff hittas.

Saknade kataloger eller scheman: Saknade kataloger eller scheman på vägen hoppas över. Ett objekt där användaren har otillräckliga privilegier hoppas inte över; Azure Databricks ger motsvarande fel.
Tillfälliga vyer och tabeller: Tillfälliga vyer och tillfälliga tabeller finns i system.session, så de nås när som helst system.session är på PATH.
Persistenta tabeller och vyer i det aktuella schemat: Persistenta tabeller och vyer i det aktuella schemat nås via den virtuella CURRENT_SCHEMA posten.

Sökvägen gäller för okvalificerade relationsnamn i frågor och DML, samt för okvalificerade namn i en fråga som är en del av en DDL-sats.

Där vägen gäller:

Context	Använda stigar
Frågor och DML (`SELECT`, `INSERT`, `UPDATE`, `DELETE`, ) `MERGE`	Sessionsväg
Fråga om CREATE TABLE AS	Sessionsväg
Fråga om en persistent CREATE VIEW	PATH fångas vid skapandetiden
Subjekt av `CREATE`, `DROP`, , `ALTER`och liknande	`current_catalog.current_schema` (ingen väguppslagning)

Tidigare versioner: I Databricks Runtime 18 och senare löses en okvalificerad relation som inte är en CTE i en fast ordning.
1. Tillfällig vy eller tillfällig tabell
  
  Matcha identifieraren med en temporär vy eller temporär tabell som definierats i den aktuella sessionen.
2. Varaktig tabell
  
  Kvalificera identifieraren fullständigt genom att vänta på resultatet av SELECT current_catalog() och SELECT current_schema() och leta upp den som en beständig relation.

Om relationen inte kan matchas till någon tabell, vy eller CTE, genererar Databricks ett TABLE_OR_VIEW_NOT_FOUND fel.

Fångad väg

En persistent vy fångar sessionens PATH vid skapandetillfället. Senare frågor i vyn löser okvalificerade namn mot den fångade vägen, inte anroparens sessionsväg. current_path() och current_schema() i den frågan returnerar fortfarande anroparens sessionsvärden.

Exempel

-- Setting up a scenario
> USE CATALOG spark_catalog;
> USE SCHEMA default;

> CREATE TABLE rel(c1 int);
> INSERT INTO rel VALUES(1);

-- An fully qualified reference to rel:
> SELECT c1 FROM spark_catalog.default.rel;
 1

-- A partially qualified reference to rel:
> SELECT c1 FROM default.rel;
 1

-- An unqualified reference to rel:
> SELECT c1 FROM rel;
 1

-- Add a temporary view with a conflicting name:
> CREATE TEMPORARY VIEW rel(c1) AS VALUES(2);

-- For unqualified references the temporary view takes precedence over the persisted table:
> SELECT c1 FROM rel;
 2

-- Temporary views cannot be qualified, so qualifiecation resolved to the table:
> SELECT c1 FROM default.rel;
 1

-- An unqualified reference to a common table expression wins even over a temporary view:
> WITH rel(c1) AS (VALUES(3))
    SELECT * FROM rel;
 3

-- If CTEs are nested, the match nearest to the table reference takes precedence.
> WITH rel(c1) AS (VALUES(3))
    (WITH rel(c1) AS (VALUES(4))
      SELECT * FROM rel);
  4

-- To resolve the table instead of the CTE, qualify it:
> WITH rel(c1) AS (VALUES(3))
    (WITH rel(c1) AS (VALUES(4))
      SELECT * FROM default.rel);
  1

-- For a CTE to be visible it must contain the query
> SELECT * FROM (WITH cte(c1) AS (VALUES(1))
                   SELECT 1),
                cte;
  [TABLE_OR_VIEW_NOT_FOUND] The table or view `cte` cannot be found.

Funktion och procedurupplösning

En rutinreferens (ett funktionsanrop eller proceduranrop) känns igen av den obligatoriska efterföljande parentesuppsättningen.

Det kan lösa sig till:

En inbyggd funktion som tillhandahålls av Azure Databricks,
En tillfällig användardefinierad funktion som är begränsad till den aktuella sessionen, eller
En persistent användardefinierad funktion eller procedur lagrad i Hive Metastore eller Unity-katalogen.

Upplösningen av ett rutinnamn beror på om det är kvalificerat:

Kvalificerad

Om namnet är fullständigt kvalificerat med tre delar: catalog.schema.routineär det unikt.

Om namnet består av två delar: schema.routineär det ytterligare kvalificerat med resultatet av SELECT current_catalog() för att göra det unikt.

Om schemat är session, kvalificeras det vidare med system och tolkas som en tillfällig funktion.

Rutinen slås sedan upp i katalogen.

Okvalificerad

Schemasökväg: I Databricks SQL och Databricks Runtime 19 och uppåt, kvalificera rutinnamnet med varje schema på PATH i ordning och välj den första matchningen.
Saknade kataloger eller scheman: Saknade kataloger eller scheman på vägen hoppas över. Ett objekt där användaren har otillräckliga privilegier hoppas inte över; Azure Databricks ger motsvarande fel.
Var rutiner finns: Inbyggda skalär- och tabellfunktioner finns i system.builtin, AI-funktioner i system.ai, och temporära funktioner i system.session.
Standardväg: StandardvägenPATH är system.session, då, system.builtinsedan , sedan system.ai, sedan CURRENT_SCHEMA.

Varning

Tillfälliga funktioner med samma namn som inbyggda funktioner har företräde eftersom system.session de kommer före system.builtin på standardvägen. Du kan omordna vägen med SET PATH. Lita inte på tillfälliga funktioner som skuggar inbyggda funktioner.

Där vägen gäller:

Context	Använda stigar
Okvalificerade rutinnamn i frågor och DML	Sessionsväg
Kroppen i en användardefinierad SQL-funktion	PATH fångas vid skapandetiden
Huvuddelen av en `SQL SECURITY DEFINER` projemans del	PATH fångad vid skapandetid, utan `system.session`
Huvuddelen av en `SQL SECURITY INVOKER` projemans del	Uppringaren är live PATH
Subjekt av `CREATE FUNCTION`, `DROP FUNCTION`, , `CREATE PROCEDURE`och liknande	Aktuellt schema (inte en väguppslagning)

Tidigare versioner: I Databricks Runtime 18 och senare följer Azure Databricks en fast prioritetsordning.
1. Inbyggd funktion
  
  Om det finns en funktion med det här namnet bland uppsättningen inbyggda funktioner väljs den funktionen.
2. Tillfällig funktion
  
  Om det finns en funktion med det här namnet bland uppsättningen med tillfälliga funktioner väljs den funktionen.
3. Beständiga funktioner
  
  Fullständigt kvalificera funktionsnamnet genom att vänta på resultatet av SELECT current_catalog() och SELECT current_schema() och leta upp det som en beständig funktion.

Om rutinen inte kan lösas ger Azure Databricks ett UNRESOLVED_ROUTINE fel.

Fångad väg

SQL-användardefinierad funktion: Okvalificerade namn i kroppen löses mot den PATH som fångas vid CREATE FUNCTION, inte anroparens sessionsväg. current_path() och current_schema() i den kroppen returnerar fortfarande anroparens sessionsvärden.
Procedur med SQL SECURITY DEFINER: Okvalificerade namn löses mot den PATH som fångas vid CREATE PROCEDURE, med system.session utelämnade. current_path() I den kroppen återvänder samma fångade väg.
Procedur med SQL SECURITY INVOKER: Okvalificerade namn använder uppringarens live-väg.

Exempel

> USE CATALOG spark_catalog;
> USE SCHEMA default;

-- Create a function with the same name as a builtin
> CREATE FUNCTION concat(a STRING, b STRING) RETURNS STRING
    RETURN b || a;

-- unqualified reference resolves to the builtin CONCAT
> SELECT concat('hello', 'world');
 helloworld

-- Qualified reference resolves to the persistent function
> SELECT default.concat('hello', 'world');
 worldhello

-- Create a persistent function
> CREATE FUNCTION func(a INT, b INT) RETURNS INT
    RETURN a + b;

-- The persistent function is resolved without qualifying it
> SELECT func(4, 2);
 6

-- Create a conflicting temporary function
> CREATE FUNCTION func(a INT, b INT) RETURNS INT
    RETURN a / b;

-- The temporary function takes precedent
> SELECT func(4, 2);
 2

-- To resolve the persistent function it now needs qualification
> SELECT spark_catalog.default.func(4, 3);
 6

Feedback

Var den här sidan till hjälp?

Uppdaterades senast 2026-10-30

Namnlösning

Kolumn-, fält-, parameter- och variabelupplösning

Namnmatchning i HAVING, ORDER BYoch QUALIFY

Exempel

Prioritet för fältextrahering och namnmatchning

Exempel

Begränsningar

Exempel

Tabell- och vyhantering

Fångad väg

Exempel

Funktion och procedurupplösning

Fångad väg

Exempel

Relaterade artiklar

Feedback

Ytterligare resurser

Namnmatchning i `HAVING`, `ORDER BY`och `QUALIFY`