Nota
L'accesso a questa pagina richiede l'autorizzazione. È possibile provare ad accedere o modificare le directory.
L'accesso a questa pagina richiede l'autorizzazione. È possibile provare a modificare le directory.
Il linguaggio DAX (Data Analysis Expression Language) può essere usato per creare misure e altre formule personalizzate da usare nei modelli tabulari di Analysis Services, nei modelli di dati PowerPivot nelle cartelle di lavoro di Excel e nei modelli di dati di Power BI Desktop. Nella maggior parte dei casi, i modelli creati in questi ambienti sono identici ed è possibile usare le stesse misure, relazioni e indicatori KPI e così via. Tuttavia, se si crea un modello tabulare di Analysis Services e lo si distribuisce in modalità DirectQuery, esistono alcune restrizioni sulle formule che è possibile usare. Questo argomento offre una panoramica di tali differenze, elenca le funzioni non supportate nel modello tabulari di SQL Server 2014 Analysis Services a livello di compatibilità 1100 o 1103 e in modalità DirectQuery ed elenca le funzioni supportate ma che potrebbero restituire risultati diversi.
In questo argomento viene usato il termine modello in memoria per fare riferimento a modelli tabulari, che sono dati memorizzati nella cache completamente in memoria in un server Analysis Services in esecuzione in modalità tabulare. I modelli DirectQuery vengono usati per fare riferimento a modelli tabulari creati e/o distribuiti in modalità DirectQuery. Per informazioni sulla modalità DirectQuery, vedere Modalità DirectQuery (SSAS tabulare).
Differenze tra la modalità in memoria e directQuery
Le query su un modello distribuito in modalità DirectQuery possono restituire risultati diversi rispetto allo stesso modello distribuito in modalità in memoria. Questo avviene perché con DirectQuery, i dati vengono sottoposti a query direttamente da un archivio dati relazionale e le aggregazioni richieste dalle formule usando il motore relazionale pertinente, invece di usare il motore di analisi in memoria xVelocity (VertiPaq) per l'archiviazione e il calcolo.
Esistono ad esempio differenze nel modo in cui determinati archivi dati relazionali gestiscono valori numerici, date, valori Null e così via.
Al contrario, il linguaggio DAX è progettato per emulare il più possibile il comportamento delle funzioni in Microsoft Excel. Ad esempio, quando si gestiscono valori Null, stringhe vuote e valori zero, Excel tenta di fornire la risposta migliore indipendentemente dal tipo di dati preciso e pertanto il motore xVelocity esegue la stessa operazione. Tuttavia, quando un modello tabulare viene distribuito in modalità DirectQuery e passa formule a un'origine dati relazionale per la valutazione, i dati devono essere gestiti in base alla semantica dell'origine dati relazionale, che in genere richiede una gestione distinta di stringhe vuote e valori Null. Per questo motivo, la stessa formula potrebbe restituire un risultato diverso quando viene valutato rispetto ai dati memorizzati nella cache e rispetto ai dati restituiti esclusivamente dall'archivio relazionale.
Inoltre, alcune funzioni non possono essere usate in modalità DirectQuery perché il calcolo richiederebbe l'invio dei dati nel contesto corrente all'origine dati relazionale come parametro. Ad esempio, le misure in una cartella di lavoro di PowerPivot spesso usano funzioni di intelligenza temporale che fanno riferimento agli intervalli temporali disponibili all'interno della cartella di lavoro. Tali formule in genere non possono essere usate in modalità DirectQuery.
Differenze semantiche
In questa sezione vengono elencati i tipi di differenze semantiche che è possibile prevedere e vengono descritte le limitazioni che potrebbero essere applicate all'utilizzo delle funzioni o ai risultati delle query.
Confronti
I modelli DAX in memoria supportano confronti di due espressioni che si risolvono in valori scalari di tipi di dati diversi. Tuttavia, i modelli distribuiti in modalità DirectQuery usano i tipi di dati e gli operatori di confronto del motore relazionale e pertanto possono restituire risultati diversi.
I confronti seguenti restituiscono sempre un errore quando viene usato in un calcolo in un'origine dati DirectQuery:
Tipo di dati numerico confrontato con qualsiasi tipo di dati stringa
Tipo di dati numerico confrontato con un valore booleano
Qualsiasi tipo di dati stringa confrontato con un valore booleano
In generale, DAX è più tollerante nei confronti delle discrepanze nei tipi di dati nei modelli in memoria e eseguirà un cast implicito di valori fino a due volte, come descritto in questa sezione. Tuttavia, le formule inviate a un archivio dati relazionale in modalità DirectQuery vengono valutate in modo più rigoroso, seguendo le regole del motore relazionale e hanno maggiori probabilità di avere esito negativo.
Confronti di stringhe e numeri
ESEMPIO: "2" < 3
La formula confronta una stringa di testo con un numero. L'espressione è true sia in modalità DirectQuery che in modelli in memoria.
In un modello in memoria il risultato è true perché i numeri come stringhe vengono implicitamente cast a un tipo di dati numerico per i confronti con altri numeri. SQL esegue anche il cast implicito dei numeri di testo come numeri per il confronto con i tipi di dati numerici.
Si noti che rappresenta una modifica del comportamento rispetto alla prima versione di PowerPivot, che restituisce false, perché il testo "2" verrebbe sempre considerato più grande di qualsiasi numero.
Confronto del testo con booleano
ESEMPIO: "VERDADERO" = TRUE
Questa espressione confronta una stringa di testo con un valore booleano. In generale, per i modelli DirectQuery o In-Memory, il confronto di un valore stringa con un valore booleano genera un errore. Le uniche eccezioni alla regola sono quando la stringa contiene la parola true o la parola false; se la stringa contiene uno dei valori true o false, viene eseguita una conversione in booleano e il confronto viene eseguito fornendo il risultato logico.
Confronto di valori Null
ESEMPIO: EVALUATE ROW("X", BLANK() = BLANK())
Questa formula confronta l'equivalente SQL di un valore Null con un valore Null. Restituisce true nei modelli in memoria e DirectQuery; viene effettuato un provisioning nel modello DirectQuery per garantire un comportamento simile al modello in memoria.
Si noti che in Transact-SQL un valore Null non è mai uguale a un valore Null. In DAX, tuttavia, uno spazio vuoto è uguale a un altro vuoto. Questo comportamento è lo stesso per tutti i modelli in memoria. È importante notare che la modalità DirectQuery usa, la maggior parte, la semantica di SQL Server; ma, in questo caso, separa da esso dando un nuovo comportamento ai confronti NULL.
Cast
Non esiste alcuna funzione cast come tale in DAX, ma i cast impliciti vengono eseguiti in molte operazioni di confronto e aritmetiche. Si tratta del confronto o dell'operazione aritmetica che determina il tipo di dati del risultato. Ad esempio:
I valori booleani vengono considerati numerici nelle operazioni aritmetiche, ad esempio TRUE + 1 o la funzione MIN applicata a una colonna di valori booleani. Un'operazione NOT restituisce anche un valore numerico.
I valori booleani vengono sempre considerati come valori logici nei confronti e quando vengono usati con EXACT, AND, OR, && o ||.
Cast da Stringa a Booleano
Nei modelli in memoria e DirectQuery, i cast sono autorizzati a valori booleani solo da queste stringhe: "" (stringa vuota), "true", "false"; dove viene eseguito il cast di una stringa vuota su un valore false.
Il casting al tipo di dati booleano di qualsiasi altra stringa comporta un errore.
Eseguire il cast dalla stringa alla data/ora
In modalità DirectQuery, i cast dalle rappresentazioni di stringa di date e ore ai valori datetime effettivi si comportano allo stesso modo in SQL Server.
Per informazioni sulle regole che regolano i cast da string a tipi di dati datetime nei modelli PowerPivot, vedere Informazioni di riferimento sulla sintassi DAX.
I modelli che usano l'archivio dati in memoria supportano un intervallo di formati di testo più limitato per le date rispetto ai formati stringa per le date supportate da SQL Server. TUTTAVIA, DAX supporta formati di data e ora personalizzati.
Eseguire il cast da stringa ad altri tipi di dato non booleani
Quando si esegue il cast da stringhe a valori non booleani, la modalità DirectQuery si comporta come SQL Server. Per altre informazioni, vedere CAST e CONVERT (Transact-SQL).
Conversione da numero a stringa non consentita
ESEMPIO: CONCATENATE(102,",345")
Il cast da numeri a stringhe non è consentito in SQL Server.
Questa formula restituisce un errore nei modelli tabulari e in modalità DirectQuery; Tuttavia, la formula produce un risultato in PowerPivot.
Nessun supporto per i tentativi di cast multipli in DirectQuery
I modelli in memoria spesso tentano un secondo cast quando il primo ha esito negativo. Questo non avviene mai in modalità DirectQuery.
ESEMPIO: TODAY() + "13:14:15"
In questa espressione il primo parametro ha tipo datetime e il secondo parametro ha tipo string. Tuttavia, i cast quando si combinano gli operandi vengono gestiti in modo diverso. DAX eseguirà un cast implicito da string a double. Nei modelli in memoria, il motore di formule tenta di eseguire il cast direttamente a double e, in caso di errore, tenterà di eseguire il cast della stringa in datetime.
In modalità DirectQuery si applicherà solo il cast diretto da string a double. Se il cast dovesse fallire, la formula restituirà un errore.
Funzioni matematiche e operazioni aritmetiche
Alcune funzioni matematiche restituiranno risultati diversi in modalità DirectQuery a causa delle differenze nel tipo di dati sottostante o nei cast che possono essere applicati nelle operazioni. Inoltre, le restrizioni descritte in precedenza sull'intervallo di valori consentito potrebbero influire sul risultato delle operazioni aritmetiche.
Ordine di addizione
Quando si crea una formula che aggiunge una serie di numeri, un modello in memoria potrebbe elaborare i numeri in un ordine diverso rispetto a un modello DirectQuery. Pertanto, quando si hanno molti numeri positivi e negativi molto grandi, è possibile che si verifichi un errore in un'operazione e che ciò influenzi il risultato di un'altra operazione.
Uso della funzione POWER
ESEMPIO: POWER(-64, 1/3)
In modalità DirectQuery, la funzione POWER non può usare valori negativi come base quando viene elevata a un esponente frazionario. Si tratta del comportamento previsto in SQL Server.
In un modello in memoria la formula restituisce -4.
Operazioni di overflow numeriche
In Transact-SQL le operazioni che generano un overflow numerico restituiscono un errore di overflow; pertanto, le formule che generano un overflow generano anche un errore in modalità DirectQuery.
Tuttavia, la stessa formula se usata in un modello in memoria restituisce un intero a otto byte. Ciò è dovuto al fatto che il motore di calcolo delle formule non esegue controlli per gli overflow numerici.
Le funzioni LOG con spazi vuoti restituiscono risultati diversi
SQL Server gestisce valori Null e spazi vuoti in modo diverso rispetto al motore xVelocity. Di conseguenza, la formula seguente restituisce un errore in modalità DirectQuery, ma restituisce infinity (-inf) in modalità in memoria.
EXAMPLE: LOG(blank())
Le stesse limitazioni si applicano alle altre funzioni logaritmiche: LOG10 e LN.
Per altre informazioni sul tipo di dati vuoto in DAX, vedere Guida di riferimento alla sintassi DAX.
Divisione per 0 e divisione per vuoto
In modalità DirectQuery, divisione per zero (0) o divisione per BLANK genererà sempre un errore. SQL Server non supporta la nozione di infinito e poiché il risultato naturale di qualsiasi divisione per 0 è infinito, il risultato è un errore. SQL Server supporta tuttavia la divisione per valori Null e il risultato deve essere sempre uguale a Null.
Anziché restituire risultati diversi per queste operazioni, in modalità DirectQuery, entrambi i tipi di operazioni (divisione per zero e divisione per null) restituiscono un errore.
Si noti che, in Excel e nei modelli PowerPivot, la divisione per zero restituisce anche un errore. La divisione per un valore vuoto restituisce un valore vuoto.
Le espressioni seguenti sono tutte valide nei modelli in memoria, ma avranno esito negativo in modalità DirectQuery:
1/BLANK
1/0
0.0/BLANK
0/0
L'espressione BLANK/BLANK è un caso speciale che restituisce BLANK in entrambi i modelli in memoria e in modalità DirectQuery.
Intervalli numerici e di data e ora supportati
Le formule nei modelli PowerPivot e tabulari in memoria sono soggette alle stesse limitazioni di Excel per quanto riguarda i valori massimi consentiti per numeri reali e date. Tuttavia, le differenze possono verificarsi quando il valore massimo viene restituito da un calcolo o una query o quando i valori vengono convertiti, cast, arrotondati o troncati.
Se i valori di tipi Currency e Real vengono moltiplicati e il risultato è maggiore del valore massimo possibile, in modalità DirectQuery non viene generato alcun errore e viene restituito un valore Null.
Nei modelli in memoria non viene generato alcun errore, ma viene restituito il valore massimo.
In generale, poiché gli intervalli di date accettati sono diversi per Excel e SQL Server, è possibile garantire che i risultati corrispondano solo quando le date rientrano nell'intervallo di date comune, incluse le date seguenti:
Data più antica: 1 marzo 1990
Data più recente: 31 dicembre 9999
Se le date utilizzate nelle formule non rientrano in questo intervallo, la formula genererà un errore o i risultati non corrispondono.
Valori a virgola mobile supportati da CEILING
ESEMPIO: EVALUATE ROW("x", CEILING(-4.398488E+30, 1))
L'equivalente Transact-SQL della funzione DAX CEILING supporta solo valori con grandezza pari o inferiore a 10^19. Una regola generale è che i valori a virgola mobile devono essere in grado di adattarsi a bigint.
Funzioni Datepart con date non comprese nell'intervallo
I risultati in modalità DirectQuery sono garantiti che corrispondano a quelli nei modelli in memoria solo quando la data usata come argomento è nell'intervallo di date valido. Se queste condizioni non vengono soddisfatte, verrà generato un errore oppure la formula restituirà risultati diversi in DirectQuery rispetto alla modalità in memoria.
ESEMPIO: MONTH(0) o YEAR(0)
In modalità DirectQuery le espressioni restituiscono rispettivamente 12 e 1899.
Nei modelli in memoria, le espressioni restituiscono rispettivamente 1 e 1900.
ESEMPIO: EOMONTH(0.0001, 1)
I risultati di questa espressione corrispondono solo quando i dati forniti come parametro rientrano nell'intervallo di date valido.
ESEMPIO: EOMONTH(blank(), blank()) o EDATE(blank(), blank())
I risultati di questa espressione devono essere gli stessi in modalità DirectQuery e in modalità in memoria.
Troncamento dei valori temporali
ESEMPIO: SECOND(1231.04097222222)
In modalità DirectQuery il risultato viene troncato, seguendo le regole di SQL Server e l'espressione restituisce 59.
Nei modelli in memoria i risultati di ogni operazione provvisoria vengono arrotondati; pertanto, l'espressione restituisce 0.
Nell'esempio seguente viene illustrato come viene calcolato questo valore:
La frazione dell'input (0,04097222222) viene moltiplicata per 24.
Il valore dell'ora risultante (0,9833333328) viene moltiplicato per 60.
Il valore del minuto risultante è 58,999999968.
La frazione del valore del minuto (0,9999999968) viene moltiplicata per 60.
Il secondo valore risultante (59,999999808) arrotonda fino a 60.
60 equivale a 0.
Tipo di dati SQL Time non supportato
I modelli in memoria non supportano l'uso del nuovo tipo di dati SQL Time . In modalità DirectQuery, le formule che fanno riferimento a colonne con questo tipo di dati restituiranno un errore. Le colonne di dati temporali non possono essere importate in un modello in memoria.
Tuttavia, in PowerPivot e nei modelli memorizzati nella cache, a volte il motore converte il valore temporale in un tipo di dati accettabile e la formula restituisce un risultato.
Questo comportamento influisce su tutte le funzioni che usano una colonna di data come parametro.
Valuta
In modalità DirectQuery, se il risultato di un'operazione aritmetica ha il tipo Currency, il valore deve essere compreso nell'intervallo seguente:
Minimo: -922337203685477.5808
Massimo: 922337203685477.5807
Combinazione di tipi di dati Currency e REAL
ESEMPIO: Currency sample 1
Se i tipi Currency e Real vengono moltiplicati e il risultato è maggiore di 9223372036854774784 (0x7ffffffffffffc00), la modalità DirectQuery non genererà un errore.
In un modello in memoria viene generato un errore se il valore assoluto del risultato è maggiore di 922337203685477.4784.
L'operazione restituisce un valore non compreso nell'intervallo
ESEMPIO: Currency sample 2
Se le operazioni su due valori di valuta generano un valore esterno all'intervallo specificato, viene generato un errore nei modelli in memoria, ma non nei modelli DirectQuery.
Combinazione di valuta con altri tipi di dati
La divisione dei valori di valuta in base ai valori di altri tipi numerici può comportare risultati diversi.
Funzione di aggregazione
Le funzioni statistiche in una tabella con una riga restituiscono risultati diversi. Le funzioni di aggregazione su tabelle vuote si comportano anche in modo diverso nei modelli in memoria rispetto a quelli in modalità DirectQuery.
Funzioni statistiche su una tabella con una singola riga
Se la tabella utilizzata come argomento contiene una singola riga, in modalità DirectQuery, funzioni statistiche come STDEV e VAR restituiscono null.
In un modello in memoria, una formula che usa STDEV o VAR su una tabella con una singola riga restituisce un errore di divisione per zero.
Funzioni di testo
Poiché gli archivi dati relazionali forniscono tipi di dati di testo diversi rispetto a Excel, è possibile che vengano visualizzati risultati diversi durante la ricerca di stringhe o l'utilizzo di sottostringhe. La lunghezza delle stringhe può anche essere diversa.
In generale, tutte le funzioni di manipolazione delle stringhe che usano colonne a dimensione fissa come argomenti possono avere risultati diversi.
Inoltre, in SQL Server alcune funzioni di testo supportano argomenti aggiuntivi che non vengono forniti in Excel. Se la formula richiede l'argomento mancante, è possibile ottenere risultati o errori diversi nel modello in memoria.
Le operazioni che restituiscono un carattere utilizzando LEFT, RIGHT e così via possono restituire il carattere corretto, ma in un caso diverso o nessun risultato
ESEMPIO: LEFT(["text"], 2)
In modalità DirectQuery, la distinzione tra maiuscole e minuscole del carattere restituito è sempre identica alla lettera archiviata nel database. Tuttavia, il motore xVelocity usa un algoritmo diverso per la compressione e l'indicizzazione dei valori, per migliorare le prestazioni.
Per impostazione predefinita, vengono usate le regole di confronto Latin1_General, senza distinzione tra maiuscole e minuscole, ma con distinzione tra caratteri accentati. Pertanto, se sono presenti più istanze di una stringa di testo in lettere minuscole, maiuscole o minuscole, tutte le istanze vengono considerate la stessa stringa e solo la prima istanza della stringa viene archiviata nell'indice. Tutte le funzioni di testo che operano sulle stringhe archiviate recupereranno la parte specificata del modulo indicizzato. Pertanto, la formula di esempio restituisce lo stesso valore per l'intera colonna, usando la prima istanza dell'input.
Archiviazione di stringhe e regole di confronto nei modelli tabulari
Questo comportamento si applica anche ad altre funzioni di testo, tra cui RIGHT, MID e così via.
La lunghezza della stringa influisce sui risultati
ESEMPIO: SEARCH("within string", "sample target text", 1, 1)
Se si cerca una stringa usando la funzione SEARCH e la stringa di destinazione è più lunga della stringa all'interno della stringa, la modalità DirectQuery genera un errore.
In un modello in memoria, la stringa cercata viene restituita, ma con la relativa lunghezza troncata alla lunghezza del <testo>.
ESEMPIO: EVALUATE ROW("X", REPLACE("CA", 3, 2, "California") )
Se la lunghezza della stringa di sostituzione è maggiore della lunghezza della stringa originale, in modalità DirectQuery la formula restituisce Null.
Nei modelli in memoria, la formula segue il comportamento di Excel, che concatena la stringa di origine e la stringa di sostituzione, che restituisce CACalifornia.
TRIM implicito al centro delle stringhe
ESEMPIO: TRIM(" A sample sentence with leading white space")
La modalità DirectQuery converte la funzione DAX TRIM nell'istruzione LTRIM(RTRIM(<column>))SQL . Di conseguenza, viene rimosso solo lo spazio bianco iniziale e finale.
Al contrario, la stessa formula in un modello in memoria rimuove gli spazi all'interno della stringa, seguendo il comportamento di Excel.
RTRIM implicito con uso della funzione LEN
ESEMPIO: LEN('string_column')
Analogamente a SQL Server, la modalità DirectQuery rimuove automaticamente lo spazio vuoto dalla fine delle colonne stringa, ovvero esegue un rtRIM implicito. Pertanto, le formule che usano la funzione LEN possono restituire valori diversi se la stringa ha spazi finali.
La funzione in memoria supporta parametri aggiuntivi per "SUBSTITUTE"
ESEMPIO: SUBSTITUTE([Title],"Doctor","Dr.")
ESEMPIO: SUBSTITUTE([Title],"Doctor","Dr.", 2)
In modalità DirectQuery è possibile usare solo la versione di questa funzione con tre parametri (3): un riferimento a una colonna, il testo precedente e il nuovo testo. Se si usa la seconda formula, viene generato un errore.
Nei modelli in memoria è possibile usare un quarto parametro facoltativo per specificare il numero di istanza della stringa da sostituire. Ad esempio, è possibile sostituire solo la seconda istanza e così via.
Restrizioni sulle lunghezze delle stringhe per le operazioni REPT
Nei modelli in memoria, la lunghezza di una stringa risultante da un'operazione che usa REPT deve essere inferiore a 32.767 caratteri.
Questa limitazione non si applica in modalità DirectQuery.
Le operazioni di sottostringa restituiscono risultati diversi a seconda del tipo di carattere
ESEMPIO: MID([col], 2, 5)
Se il testo di input è varchar o nvarchar, il risultato della formula è sempre lo stesso.
Tuttavia, se il testo è a lunghezza fissa e il valore per <num_chars> è maggiore della lunghezza della stringa di destinazione, in modalità DirectQuery viene aggiunto uno vuoto alla fine della stringa di risultato.
In un modello in memoria, il risultato termina all'ultimo carattere della stringa, senza riempimento interno.
Funzioni supportate in modalità DirectQuery
Le funzioni DAX seguenti possono essere usate in modalità DirectQuery, ma con le qualifiche descritte nella sezione precedente.
Funzioni di testo
CONCATENARE
TROVARE
Sinistra
LEN
MEZZO
SOSTITUIRE
RIPETI
A DESTRA
SOSTITUTO
TAGLIARE
funzioni statistiche
CONTARE
STDEV. P
STDEV. S
STDEVX. P
STDEVX. S
VAR. P
VAR.S
VARX. P
VARX. S
Funzioni di data/ora
DATTERO
EDATE
EOMONTH
DATTERO
TEMPO
Secondo
Funzioni matematiche e numeri
SOFFITTO
LN
REGISTRO
LOG10
Energia
Interrogazioni di tabelle DAX
Esistono alcune limitazioni quando si valutano le formule rispetto a un modello DirectQuery usando query da tabella DAX. DirectQuery non supporta il riferimento alla stessa colonna due volte in una clausola ORDER BY. Non è possibile creare l'istruzione equivalente Transact-SQL e la query fallisce.
In un modello in memoria, la ripetizione della clausola ORDER by non ha alcun effetto sui risultati.
Funzioni non supportate in modalità DirectQuery
Alcune funzioni DAX non sono supportate nei modelli distribuiti in modalità DirectQuery. I motivi per cui una determinata funzione non è supportata può includere una o una combinazione di questi motivi:
Il motore relazionale sottostante non può eseguire calcoli equivalenti a quelli eseguiti dal motore xVelocity.
La formula non può essere convertita in un'espressione SQL equivalente.
Le prestazioni dell'espressione convertita e i calcoli risultanti sarebbero inaccettabili.
Le funzioni DAX seguenti non possono essere usate nei modelli DirectQuery.
Funzioni percorso
SENTIERO
PATHCONTAINS
PATHITEM
PATHITEMREVERSE
lunghezza del percorso
Funzioni varie
COUNTBLANK
FISSATO
FORMATO
RAND
RANDBETWEEN
Funzioni di intelligenza temporale: date di inizio e fine
DATESQTD
DATESYTD
DATESMTD
DATESQTD
DATEINPERIODO
TOTALMTD
TOTALQTD
TOTALYTD
DATESINPERIOD
lo stesso periodo dell'anno scorso
PARALLELPERIOD
Funzioni di intelligenza temporale: Saldi
MESEDEL SALDOINIZIALE
SALDOINIZIALETRIMESTRALE
ANNO_DI_SALDO_INIZIALE
Saldo di Fine Mese
SALDOFINEQUARTO
SALDO DI CHIUSURA ANNUALE
Funzioni di intelligenza temporale: periodi precedenti e successivi
GIORNOPRECEDENTE
MESEPRECEDENTE
TRIMESTRE PRECEDENTE
ANNO PRECEDENTE
Giorno Dopo
IL PROSSIMO MESE
PROSSIMO TRIMESTRE
PROSSIMO ANNO
Funzioni di Intelligenza Temporale: periodi e calcoli sui periodi
STARTOFMONTH
INIZIO DEL TRIMESTRE
STARTOFYEAR
ENDOFMONTH
ENDOFQUARTER
ENDOFYEAR
FIRSTDATE
LASTDATE
DATEADD