Le traduzioni sono generate tramite traduzione automatica. In caso di conflitto tra il contenuto di una traduzione e la versione originale in Inglese, quest'ultima prevarrà.
# Comprendere l'architettura e la configurazione di Babelfish
La gestione del cluster database Aurora PostgreSQL-Compatible Edition che esegue Babelfish è simile a quella di qualsiasi cluster database Aurora. Ovvero, è possibile sfruttare la scalabilità, l'elevata disponibilità con il supporto per il failover e la replica integrata forniti da un cluster database Aurora. Per ulteriori informazioni su queste funzionalità, consulta [Gestione delle prestazioni e del dimensionamento dei cluster DB Aurora](Aurora.Managing.Performance.md), [Elevata disponibilità di Amazon Aurora](Concepts.AuroraHighAvailability.md) e [Replica con Amazon Aurora](Aurora.Replication.md). È disponibile inoltre l'accesso a molti altri strumenti e utilità AWS, inclusi i seguenti:
+ Amazon CloudWatch è un servizio di monitoraggio e osservabilità che fornisce dati e approfondimenti fruibili. Per ulteriori informazioni, consulta [Monitoraggio dei parametri di Amazon Aurora con Amazon CloudWatch](monitoring-cloudwatch.md).
+ Performance Insights è una funzionalità di ottimizzazione e monitoraggio delle prestazioni del database che consente di valutare rapidamente il carico sul database. Per ulteriori informazioni, consulta [Monitoraggio del carico DB con Performance Insights su Amazon Aurora](USER_PerfInsights.md).
+ I database globali Aurora si sviluppano su più Regioni AWS, consentendo letture globali a bassa latenza e offrendo un ripristino di emergenza rapido in caso di eventuali interruzioni che potrebbero interessare un’intera Regione AWS. Per ulteriori informazioni, consulta [Utilizzo di Database globale Amazon Aurora](aurora-global-database.md).
+ Le patch software automatiche mantengono aggiornato il database con le ultime patch di sicurezza e funzionalità quando diventano disponibili.
+ Gli eventi Amazon RDS comunicano via e-mail o SMS eventi importanti del database, ad esempio un failover automatico. Per ulteriori informazioni, consulta [Monitoraggio di eventi Amazon Aurora](working-with-events.md).
Di seguito sono fornite ulteriori informazioni sull'architettura Babelfish e su come i database SQL Server migrati vengono gestiti da Babelfish. Quando crei il cluster database Babelfish, devi prendere alcune decisioni in anticipo su database singoli o multipli, regole di confronto e altri dettagli.
**Topics**
+ [Architettura babelfish](babelfish-architecture.md)
+ [Impostazioni del gruppo di parametri del cluster database per Babelfish](babelfish-configuration.md)
+ [Informazioni sulle regole di confronto in Babelfish per Aurora PostgreSQL.](babelfish-collations.md)
+ [Gestione degli errori di Babelfish con escape hatch](babelfish-strict.md)
# Architettura babelfish
Quando crei un cluster Aurora PostgreSQL con Babelfish attivato, Aurora fornisce il cluster un database PostgreSQL denominato `babelfish_db`. Questo database è dove risiedono tutti gli oggetti e le strutture di SQL Server migrati.
**Nota**
In un cluster Aurora PostgreSQL, il nome del database `babelfish_db` è riservato a Babelfish. La creazione del proprio database "babelfish\$1db" su un cluster database Babelfish impedisce ad Aurora di eseguire correttamente il provisioning di Babelfish.
Quando ci si connette alla porta TDS, la sessione viene inserita nel database `babelfish_db`. Da T-SQL, la struttura sembra simile alla connessione a un'istanza di SQL Server. Puoi visualizzare i database `master`, `msdb` e `tempdb` e il catalogo `sys.databases`. È possibile creare database utente aggiuntivi e passare da un database all'altro con l'istruzione USE. Quando crei un database utente di SQL Server, viene appiattito nel Database PostgreSQL `babelfish_db`. Il database mantiene la sintassi e la semantica tra database uguali o simili a quelli forniti da SQL Server.
## Utilizzo di Babelfish con un singolo database o più database
Quando si crea un cluster Aurora PostgreSQL da utilizzare con Babelfish, è possibile scegliere tra l'utilizzo di un singolo database SQL Server sul proprio database SQL Server o più database SQL Server insieme. La tua scelta influisce sul modo in cui i nomi degli schemi di SQL Server all'interno del database `babelfish_db` vengono visualizzati da Aurora PostgreSQL. La modalità di migrazione è memorizzata nel parametro `migration_mode`. Non è necessario modificare questo parametro dopo aver creato il cluster poiché si potrebbe perdere l'accesso a tutti gli oggetti SQL creati in precedenza.
In modalità database singolo, i nomi dello schema del database SQL Server rimangono uguali nel database `babelfish_db` di PostgreSQL. Se scegli di migrare un solo singolo database, i nomi dello schema del database dell'utente migrato possono essere usati come riferimento in PostgreSQL con gli stessi nomi utilizzati in SQL Server. Ad esempio, gli schemi `dbo` e `smith` risiedono all'interno del database `dbA` *.*
![\[\]](http://docs.aws.amazon.com/it_it/AmazonRDS/latest/AuroraUserGuide/images/babelfish_single_db_mode.png)
Quando ci si connette tramite TDS, è possibile eseguire `USE dba` per vedere gli schemi `dbo` e `dev` da T-SQL, come si farebbe in SQL Server. I nomi dello schema invariati sono visibili anche da PostgreSQL.
In modalità di database multipli, i nomi dello schema dei database utente diventano `dbname_schemaname` se l'accesso viene eseguito da PostgreSQL. I nomi dello schema rimangono gli stessi se l'accesso viene eseguito da T-SQL.
![\[\]](http://docs.aws.amazon.com/it_it/AmazonRDS/latest/AuroraUserGuide/images/babelfish_multi_db_mode.png)
Come mostrato nell'immagine, la modalità database multipli e la modalità database singolo sono le stesse di SQL Server durante la connessione tramite la porta TDS e l'utilizzo di T-SQL. Ad esempio, `USE dbA` elenca schemi `dbo` e `dev` proprio come in SQL Server. I nomi dello schema mappati, come `dba_dbo` e `dba_dev`, sono visibili da PostgreSQL.
Ogni database contiene ancora i tuoi schemi. Il nome di ogni database è preceduto al nome dello schema di SQL Server, utilizzando un trattino di sottolineatura come delimitatore, ad esempio:
+ `dba` contiene `dba_dbo` e `dba_dev`.
+ `dbb` contiene `dbb_dbo` e `dbb_test`.
+ `dbc` contiene `dbc_dbo` e `dbc_prod`.
All'interno del database`babelfish_db`, l'utente T-SQL deve ancora eseguire `USE dbname` per modificare il contesto del database, in modo che l'aspetto rimanga simile a SQL Server.
## Scegliere una modalità di migrazione
Ciascuna modalità di migrazione presenta vantaggi e svantaggi. Scegli la modalità di migrazione in base al numero di database utente e ai piani di migrazione. Dopo aver creato un cluster da utilizzare con Babelfish, non devi modificare la modalità di migrazione poiché potresti perdere l'accesso a tutti gli oggetti SQL creati in precedenza. Quando scegli una modalità di migrazione, considera i requisiti dei database utente e dei client.
Quando crei un cluster da utilizzare con Babelfish, Aurora PostgreSQL crea i database di sistema, `master` e `tempdb`. Se sono stati creati o modificati oggetti nei database di sistema (`master` o `tempdb`), assicurati di ricreare questi oggetti nel nuovo cluster. A differenza di SQL Server, Babelfish non si reinizializza `tempdb` dopo il riavvio di un cluster.
Utilizzare la modalità di migrazione di database singolo nei seguenti casi:
+ Se si sta eseguendo la migrazione di un singolo database SQL Server. In modalità database singolo, se l'accesso viene eseguito da PostgreSQL i nomi degli schemi migrati sono identici ai nomi dello schema originale di SQL Server. Ciò riduce le modifiche al codice per le query SQL esistenti se desideri ottimizzarle per l'esecuzione con una connessione PostgreSQL.
+ Se il tuo obiettivo finale è una migrazione completa alla nativa Aurora PostgreSQL. Prima di eseguire la migrazione, consolidare gli schemi in un unico schema (`dbo`) e quindi migrare in un singolo cluster per ridurre le modifiche richieste.
Utilizzare la modalità di migrazione di più database nei seguenti casi:
+ Se desideri l'esperienza SQL Server predefinita con più database utente nella stessa istanza.
+ Se è necessario migrare insieme più database dell'utente.
# Impostazioni del gruppo di parametri del cluster database per Babelfish
Quando crei un cluster database Aurora PostgreSQL e scegli **Turn on Babelfish** (Attiva Babelfish), un gruppo di parametri del cluster database viene creato automaticamente se scegli **Create new** (Crea nuovo). Questo gruppo di parametri del cluster database si basa sul gruppo di parametri del cluster database Aurora PostgreSQL per la versione di Aurora PostgreSQL scelta per l'installazione, ad esempio Aurora PostgreSQL versione 14. Viene chiamato utilizzando il seguente modello generale:
```
custom-aurora-postgresql14-babelfish-compat-3
```
Durante il processo di creazione del cluster puoi modificare le seguenti impostazioni, ma alcune di queste non possono essere modificate dopo che sono state memorizzate nel gruppo di parametri personalizzati, quindi scegli attentamente:
+ Database singolo o database multipli
+ Impostazioni locali delle regole di confronto predefinite
+ Nome della regola di confronto
+ DB parameter group (Gruppo di parametri database)
Per utilizzare un gruppo di parametri esistente del cluster database Aurora PostgreSQL versione 13 o successive, modifica il gruppo e imposta il parametro `babelfish_status` su `on`. Specificare tutte le opzioni Babelfish prima di creare il cluster Aurora PostgreSQL. Per ulteriori informazioni, consulta [Gruppi di parametri per Amazon Aurora](USER_WorkingWithParamGroups.md).
I seguenti parametri controllano le preferenze di Babelfish. Salvo laddove diversamente indicato nella descrizione, i parametri sono modificabili. Il valore predefinito è incluso nella descrizione. Per visualizzare i valori consentiti per qualsiasi parametro, procedi come segue:
**Nota**
Quando si associa un nuovo gruppo parametri del database a un’istanza database, i parametri statici e dinamici modificati vengono applicati solo dopo il riavvio dell’istanza database. Tuttavia, se modifichi i parametri dinamici nel gruppo di parametri database associato all’istanza database, tali modifiche vengono applicate immediatamente senza eseguire il riavvio.
1. Accedi a Console di gestione AWS e apri la console Amazon RDS all'indirizzo [https://console.aws.amazon.com/rds/](https://console.aws.amazon.com/rds/).
1. Nel menu di navigazione scegli **Parameter groups** (Gruppi di parametri).
1. Nell'elenco, scegli il gruppo di parametri del cluster database `default.aurora-postgresql14`.
1. Inserisci il nome di un parametro nel campo di ricerca. Ad esempio, inserisci `babelfishpg_tsql.default_locale` nel campo di ricerca per visualizzare questo parametro e il suo valore predefinito e le impostazioni consentite.
**Nota**
I database globali Babelfish per Aurora PostgreSQL funzionano nelle Regioni secondarie solo se in tali regioni sono attivati i seguenti parametri.
| Parametro | Description | Applica tipo | Is Modifiable |
| --- | --- | --- | --- |
| babelfishpg\$1tsql.apg\$1enable\$1correlated\$1scalar\$1transform | Consente al pianificatore di trasformare la sottoquery scalare correlata in Babelfish. (Predefinito: on) (Consentito: on, off) | dynamic | true |
| babelfishpg\$1tsql.apg\$1enable\$1subquery\$1cache | Abilita l’uso della cache per sottoquery scalari correlate in Babelfish. (Predefinito: on) (Consentito: on, off) | dynamic | true |
| babelfishpg\$1tds.tds\$1default\$1numeric\$1scale | Imposta la scala predefinita di tipo numerico da inviare nei metadati della colonna TDS se il motore non ne specifica uno. (Predefinito: 8) (Consentito: 0–38) | dynamic | true |
| babelfishpg\$1tds.tds\$1default\$1numeric\$1precision | Un valore intero che imposta la precisione predefinita del tipo numerico da inviare nei metadati della colonna TDS se il motore non ne specifica uno. (Predefinito: 38) (Consentito: 1–38) | dynamic | true |
| babelfishpg\$1tds.tds\$1default\$1packet\$1size | Un valore intero che imposta la dimensione predefinita del pacchetto per la connessione di client SQL Server. (Predefinito: 4096) (Consentito: 512–32767) | dynamic | true |
| babelfishpg\$1tds.tds\$1default\$1protocol\$1version | Un valore intero che imposta una versione del protocollo TDS predefinita per la connessione dei client. (Impostazione predefinita: IMPOSTAZIONE PREDEFINITA) (consentito: TDSv7 .0, TDSv7 .1, TDSv7 .1.1, TDSv7 .2, .3A, TDSv7 .3B, .4, IMPOSTAZIONE PREDEFINITA) TDSv7 TDSv7 | dynamic | true |
| babelfishpg\$1tds.default\$1server\$1name | Una stringa che identifica il nome predefinito del server Babelfish. (Predefinito: Microsoft SQL Server) (Consentito: null) | dynamic | true |
| babelfishpg\$1tds.tds\$1debug\$1log\$1level | Un valore intero che imposta il livello di registrazione in TDS; 0 disattiva la registrazione. (Predefinito: 1) (Consentito: 0, 1, 2, 3) | dynamic | true |
| babelfishpg\$1tds.listen\$1address | Una stringa che imposta il nome host o l'indirizzo IP o gli indirizzi su cui ascoltare TDS. Questo parametro non può essere modificato dopo la creazione del cluster database Babelfish. (Predefinito: \$1) (Consentito: null) | – | false |
| babelfishpg\$1tds.port | Un valore intero che imposta la porta TCP utilizzata per le richieste nella sintassi di SQL Server. (Predefinito: 1433) (Consentito: 1–65535) | static | true |
| babelfishpg\$1tds.tds\$1ssl\$1encrypt | Un valore booleano che attiva o disattiva la crittografia (0) (1) per i dati che attraversano la porta del listener TDS. Per informazioni dettagliate sull'utilizzo di SSL per le connessioni client, consulta [Impostazioni SSL Babelfish e connessioni client](#babelfish-ssl). (Predefinito: 0) (Consentito: 0, 1) | dynamic | true |
| babelfishpg\$1tds.tds\$1ssl\$1max\$1protocol\$1version | Una stringa che specifica la versione di protocollo più alta da utilizzare per la sessione TDS. SSL/TLS (Impostazione predefinita: 'TLSv1.2') (Consentita:' ',' .1', TLSv1 '.2'TLSv1) TLSv1 | dynamic | true |
| babelfishpg\$1tds.tds\$1ssl\$1min\$1protocol\$1version | Una stringa che specifica la versione minima del SSL/TLS protocollo da utilizzare per la sessione TDS. (Impostazione predefinita: 'TLSv1.2' da Aurora PostgreSQL versione 16,' 'per TLSv1 versioni precedenti a Aurora PostgreSQL versione 16) (consentito:' ',' .1', '.2') TLSv1 TLSv1 TLSv1 | dynamic | true |
| babelfishpg\$1tds.unix\$1socket\$1directories | Una stringa che identifica la directory socket Unix server TDS. Questo parametro non può essere modificato dopo la creazione del cluster database Babelfish. (Predefinito: /tmp) (Consentito: null) | – | false |
| babelfishpg\$1tds.unix\$1socket\$1group | Una stringa che identifica il gruppo socket Unix server TDS. Questo parametro non può essere modificato dopo la creazione del cluster database Babelfish. (Predefinito: rdsdb) (Consentito: null) | – | false |
| babelfishpg\$1tsql.default\$1locale | Una stringa che specifica le impostazioni locali predefinite utilizzate per le regole di confronto Babelfish. Le impostazioni locali predefinite sono le uniche e non includono eventuali qualificatori. Impostare questo parametro quando si esegue il provisioning di un cluster Babelfish DB. Dopo aver eseguito il provisioning del cluster database, le modifiche apportate a questo parametro vengono ignorate. (Predefinito: en\$1US) (Consentito: consulta [tabelle](babelfish-collations.md)) | static | true |
| babelfishpg\$1tsql.migration\$1mode | Un elenco non modificabile che specifica il supporto per database a un solo utente o più utenti. Impostare questo parametro quando si esegue il provisioning di un cluster Babelfish DB. Dopo aver eseguito il provisioning del cluster database, non è possibile modificare il valore di questo parametro. (Predefinito: multi-db da Aurora PostgreSQL versione 16, single db per versioni precedenti ad Aurora PostgreSQL versione 16) (Consentito: single db, multi-db, null) | static | true |
| babelfishpg\$1tsql.server\$1collation\$1name | Una stringa che specifica il nome della regola di confronto utilizzata per le azioni a livello di server. Impostare questo parametro quando si esegue il provisioning di un cluster Babelfish DB. Dopo aver eseguito il provisioning del cluster di database, non modificare il valore di questo parametro. (Predefinito: bbf\$1unicode\$1general\$1ci\$1as) (Consentito: consulta [tabelle](babelfish-collations.md)) | static | true |
| babelfishpg\$1tsql.versione | Una stringa che imposta l'output della variabile @ @VERSION. Non modificare questo valore per i cluster Aurora PostgreSQL DB. (Predefinito: null) (Consentito: default) | dynamic | true |
| rds.babelfish\$1status | Una stringa che imposta lo stato della funzionalità Babelfish. Quando questo parametro è impostato su `datatypesonly`, Babelfish è disattivato ma i tipi di dati di SQL Server sono ancora disponibili. (Predefinito: off) (Consentito: on, off, datatypesonly) | static | true |
| unix\$1socket\$1permissions | Un valore intero che imposta le autorizzazioni socket Unix server TDS. Questo parametro non può essere modificato dopo la creazione del cluster database Babelfish. (Predefinito: 0700) (Consentito: 0–511) | – | false |
## Impostazioni SSL Babelfish e connessioni client
Per richiedere SSL/TLS connessioni al cluster Babelfish for Aurora PostgreSQL DB, usa il parametro. `rds.force_ssl`
+ Per richiedere SSL/TLS connessioni, imposta il valore del `rds.force_ssl` parametro su 1 (acceso).
+ Per disattivare SSL/TLS le connessioni richieste, impostate il valore del `rds.force_ssl` parametro su 0 (disattivato).
Il valore predefinito di questo parametro dipende dalla versione di Aurora PostgreSQL:
+ Per Aurora PostgreSQL versioni 17 e successive: il valore predefinito è 1 (on).
+ Per Aurora PostgreSQL versioni 16 e precedenti: il valore predefinito è 0 (off).
**Nota**
Quando si esegue un aggiornamento di versione principale da Aurora PostgreSQL versione 16 o precedente alla versione 17 o successiva, il valore predefinito del parametro cambia da 0 (off) a 1 (on). Questa modifica può causare errori di connettività per le applicazioni non configurate per SSL. È possibile ripristinare il comportamento predefinito precedente impostando questo parametro su 0 (off).
Per informazioni specifiche del driver, consulta [Connessione a un cluster database Babelfish](babelfish-connect.md).
Quando un client si connette alla porta TDS (default `1433`), Babelfish confronta l'impostazione Secure Sockets Layer (SSL) inviata durante l'handshake del client con l'impostazione del parametro SSL Babelfish (`tds_ssl_encrypt`). Babelfish determina quindi se è consentita una connessione. Se è consentita una connessione, il comportamento di crittografia viene applicato o meno, a seconda delle impostazioni dei parametri e del supporto per la crittografia offerto dal client.
La tabella seguente mostra come si comporta Babelfish per ogni combinazione.
| Impostazione del client dell'app | Impostazione SSL Babelfish | rds.force\$1ssl | Connessione consentita? | Valore restituito al client |
| --- | --- | --- | --- | --- |
| ENCRYPT\$1ON | Qualsiasi | Qualsiasi | Consentito, l'intera connessione è crittografata | ENCRYPT\$1ON |
| ENCRYPT\$1OFF | tds\$1ssl\$1encrypt=1 | Qualsiasi | Consentito, l'intera connessione è crittografata | ENCRYPT\$1REQ |
| ENCRYPT\$1OFF | tds\$1ssl\$1encrypt=0 | rds.force\$1ssl=0 | Consentito, il pacchetto di accesso è crittografato | ENCRYPT\$1OFF |
| ENCRYPT\$1OFF | tds\$1ssl\$1encrypt=0 | rds.force\$1ssl=1 | No, connessione chiusa | ENCRYPT\$1OFF |
| ENCRYPT\$1NOT\$1SUP | tds\$1ssl\$1encrypt=0 | rds.force\$1ssl=0 | Sì | ENCRYPT\$1NOT\$1SUP |
| ENCRYPT\$1NOT\$1SUP | tds\$1ssl\$1encrypt=1 | Qualsiasi | No, connessione chiusa | ENCRYPT\$1REQ |
| ENCRYPT\$1NOT\$1SUP | tds\$1ssl\$1encrypt=0 | rds.force\$1ssl=1 | No, connessione chiusa | ENCRYPT\$1NOT\$1SUP |
| ENCRYPT\$1CLIENT\$1CERT | Qualsiasi | Qualsiasi | No, connessione chiusa | Non supportato. |
# Informazioni sulle regole di confronto in Babelfish per Aurora PostgreSQL.
Quando crei un cluster database Aurora PostgreSQL, scegli una regola di confronto per i dati. Una *regola di confronto* specifica i modelli di ordinamento e bit che producono il testo o i caratteri in una determinata lingua scritta. Una regola di confronto include regole che confrontano i dati per un determinato set di modelli di bit. La regola di confronto è correlata alla localizzazione. Le diverse impostazioni locali influenzano la mappatura dei caratteri, l'ordinamento e simili. Gli attributi della regola di confronto si riflettono nei nomi di varie regole di confronto. Per ulteriori informazioni sugli attributi, consulta [Babelfish collation attributes table](#bfish-collation-attributes-table).
Babelfish mappa le raccolte di SQL Server a raccolte comparabili fornite da Babelfish. Babelfish predefinisce le raccolte Unicode con raccolte di stringhe culturalmente sensibili e ordini di ordinamento. Babelfish fornisce anche un modo per tradurre le raccolte nel database di SQL Server nella raccolta Babelfish più vicina. Vengono fornite raccolte specifice per le diverse lingue e regioni.
Alcune raccolte specificano una pagina codice corrispondente a una codifica lato client. Babelfish traduce automaticamente dalla codifica del server alla codifica client a seconda della raccolta di ciascuna colonna di output.
Babelfish supporta le regole di confronto elencate nella [Babelfish supported collations table](#bfish-collations-table). Babelfish mappa le raccolte di SQL Server a raccolte comparabili fornite da Babelfish.
Babelfish utilizza la versione 153.80 della libreria delle regole di confronto International Components for Unicode (ICU). Per ulteriori informazioni sulle regole di confronto ICU, consulta [Collation](https://unicode-org.github.io/icu/userguide/collation/) (Regola di confronto) nella documentazione di ICU. Per ulteriori informazioni su PostgreSQL e regola di confronto, consulta [Collation Support](https://www.postgresql.org/docs/current/collation.html) (Supporto per regole di confronto) nella documentazione di PostgreSQL.
**Topics**
+ [Parametri del cluster database che controllano regole di confronto e impostazioni locali](#babelfish-collations.parameters)
+ [Regole di confronto deterministiche e non deterministiche in Babelfish](#babelfish-collations.deterministic-nondeterministic)
+ [Regole di confronto supportate a livello di database in Babelfish](#babelfish-collations.database-level)
+ [Regole di confronto di server e oggetti in Babelfish](#babelfish-collations.reference-tables-supported-collations)
+ [Comportamento della regola di confronto predefinita in Babelfish](#babelfish-collations-default)
+ [Gestione delle raccolte](collation.managing.md)
+ [Limitazioni di regole di confronto e differenze di comportamento](collation.limitations.md)
## Parametri del cluster database che controllano regole di confronto e impostazioni locali
I seguenti parametri influiscono sul comportamento della regola di confronto.
**babelfishpg\$1tsql.default\$1locale**
Questo parametro specifica le impostazioni locali predefinite utilizzate dalla regola di confronto. Questo parametro viene utilizzato in combinazione con gli attributi elencati nella [Babelfish collation attributes table](#bfish-collation-attributes-table) per personalizzare le regole di confronto per una lingua e una regione specifici. Il valore predefinito per questo parametro è `en-US`.
Le impostazioni locali predefinite si applicano a tutti i nomi delle regole di confronto Babelfish che iniziano con "BBF" e a tutte le regole di confronto SQL Server mappate alle regole di confronto Babelfish. La modifica dell'impostazione di questo parametro su un cluster database Babelfish esistente non influenza le impostazioni locali delle regole di confronto esistenti. Per l'elenco delle regole di confronto, consulta [Babelfish supported collations table](#bfish-collations-table).
**babelfishpg\$1tsql.server\$1collation\$1name**
Questo parametro specifica la regola di confronto predefinita per il server (istanza del cluster database Aurora PostgreSQL) e il database. Il valore predefinito è `sql_latin1_general_cp1_ci_as`. Il `server_collation_name` deve essere una raccolta `CI_AS` perché in T-SQL, la raccolta determina il modo in cui vengono confrontati gli identificatori.
Quando crei il tuo cluster database Babelfish, scegli il **Collation name** (Nome regola di confronto) dall'elenco selezionabile. Questi includono le regole di confronto elencate in [Babelfish supported collations table](#bfish-collations-table). Non modificare il `server_collation_name` dopo la creazione del database Babelfish.
Le impostazioni scelte durante la creazione del cluster database Babelfish per Aurora PostgreSQL vengono memorizzate nel gruppo di parametri del cluster database associato al cluster per questi parametri e impostano il comportamento della regola di confronto.
## Regole di confronto deterministiche e non deterministiche in Babelfish
Babelfish supporta le raccolte deterministiche e non deterministiche:
+ Una *regola di confronto deterministica* valuta come uguali i caratteri con sequenze di byte identiche. Ciò significa che `x` e `X` non sono uguali in una regola di confronto deterministica. Le regole di confronto deterministiche possono essere con distinzione maiuscole/minuscole (CS) e con distinzione caratteri accentati/non accentati (AS).
+ Una *regola di confronto non deterministica* non richiede una corrispondenza identica. Una raccolta non deterministica valuta `x` e `X` come uguale. Le regole di confronto non deterministiche sono senza distinzione tra maiuscole e minuscole (CI) e senza distinzione tra caratteri accentati e non accentati (AI).
Nella tabella seguente sono riportate alcune differenze di comportamento tra Babelfish e PostgreSQL quando si utilizzano le regole di confronto non deterministiche.
| Babelfish | PostgreSQL |
| --- | --- |
| Supporta la clausola LIKE per le regole di confronto CI\$1AS. | Non supporta la clausola LIKE sulle regole di confronto non deterministiche. |
| Supporta la clausola LIKE solo per le seguenti regole di confronto AI di Babelfish versione 4.2.0: [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/it_it/AmazonRDS/latest/AuroraUserGuide/babelfish-collations.html) | Non supporta la clausola LIKE sulle regole di confronto non deterministiche. |
Per un elenco di altre limitazioni e differenze di comportamento per Babelfish rispetto a SQL Server e PostgreSQL, consulta [Limitazioni di regole di confronto e differenze di comportamento](collation.limitations.md).
Babelfish e SQL Server seguono una convenzione di denominazione per le raccolte che descrivono gli attributi di raccolta, come illustrato nella tabella seguente.
| Attributo | Descrizione |
| --- | --- |
| Intelligenza artificiale | Insensibile all'accento. |
| AS | sensibile agli accenti. |
| BIN2 | BIN2 richiede che i dati siano ordinati in ordine di codice. L'ordine dei punti di codice Unicode è lo stesso ordine di caratteri per le codifiche UTF-8, UTF-16 e UCS-2. L'ordine dei punti di codice è una raccolta deterministica rapida. |
| CI | Senza distinzione tra maiuscole e minuscole |
| CS | Distinzione tra lettere maiuscole e minuscole |
| PREF | Per ordinare le lettere maiuscole prima delle lettere minuscole, utilizzare una raccolta PREF. Se la raccolta è priva di distinzione tra maiuscole e minuscole, la versione maiuscola di una lettera viene ordinata prima della versione minuscola, se non esiste altra distinzione. La libreria ICU supporta le preferenze maiuscole con `colCaseFirst=upper`, ma non per le raccolte CI\$1AS. La PREF può essere applicata solo a raccolte deterministiche `CS_AS`. |
## Regole di confronto supportate a livello di database in Babelfish
Le seguenti regole di confronto sono supportate a livello di database in Babelfish:
+ bbf\$1unicode\$1bin2
+ bbf\$1unicode\$1cp1\$1ci\$1ai
+ bbf\$1unicode\$1cp1\$1ci\$1as
+ bbf\$1unicode\$1cp1250\$1ci\$1ai
+ bbf\$1unicode\$1cp1250\$1ci\$1as
+ bbf\$1unicode\$1cp1257\$1ci\$1ai
+ bbf\$1unicode\$1cp1257\$1ci\$1as
+ estonian\$1ci\$1ai
+ estonian\$1ci\$1as
+ finnish\$1swedish\$1ci\$1ai
+ finnish\$1swedish\$1ci\$1as
+ french\$1ci\$1ai
+ french\$1ci\$1as
+ latin1\$1general\$1bin2
+ latin1\$1general\$1ci\$1ai
+ latin1\$1general\$1ci\$1as
+ latin1\$1general\$190\$1bin2
+ latin1\$1general\$1100\$1bin2
+ latin1\$1general\$1140\$1bin2
+ modern\$1spanish\$1ci\$1ai
+ modern\$1spanish\$1ci\$1as
+ polish\$1ci\$1ai
+ polish\$1ci\$1as
+ sql\$1latin1\$1general\$1cp1\$1ci\$1ai
+ SQL\$1Latin1\$1General\$1CP1\$1CI\$1AS (default)
+ sql\$1latin1\$1general\$1cp1250\$1ci\$1as
+ sql\$1latin1\$1general\$1cp1251\$1ci\$1as
+ sql\$1latin1\$1general\$1cp1257\$1ci\$1as
+ traditional\$1spanish\$1ci\$1ai
+ traditional\$1spanish\$1ci\$1as
**Nota**
Per utilizzare regole di confronto diverse a livello di database, è necessario che corrispondano a quelle a livello di server. Per ulteriori informazioni, consulta [Regole di confronto di server e oggetti in Babelfish](#babelfish-collations.reference-tables-supported-collations)
## Regole di confronto di server e oggetti in Babelfish
Utilizzare le raccolte seguenti come raccolta del server o come raccolta di oggetti.
| ID raccolta | Note |
| --- | --- |
| bbf\$1unicode\$1general\$1ci\$1as | Supporta il confronto tra maiuscole e minuscole e l'operatore LIKE. |
| bbf\$1unicode\$1cp1\$1ci\$1as | [Raccolta non deterministica](https://www.unicode.org/Public/MAPPINGS/VENDORS/MICSFT/WindowsBestFit/bestfit1252.txt) nota anche come CP1252. |
| bbf\$1unicode\$1CP1250\$1ci\$1as | [Raccolta non deterministica](https://www.unicode.org/Public/MAPPINGS/VENDORS/MICSFT/WindowsBestFit/bestfit1250.txt) utilizzata per rappresentare testi nelle lingue dell'Europa centrale e dell'Europa orientale che utilizzano lo script latino. |
| bbf\$1unicode\$1CP1251\$1ci\$1as | [Raccolta non deterministica](https://www.unicode.org/Public/MAPPINGS/VENDORS/MICSFT/WindowsBestFit/bestfit1251.txt) per le lingue che utilizzano lo script cirillico. |
| bbf\$1unicode\$1cp1253\$1ci\$1as | [Raccolta non deterministica](https://www.unicode.org/Public/MAPPINGS/VENDORS/MICSFT/WindowsBestFit/bestfit1253.txt) usata per rappresentare il greco moderno. |
| bbf\$1unicode\$1cp1254\$1ci\$1as | [Raccolta non deterministica](https://www.unicode.org/Public/MAPPINGS/VENDORS/MICSFT/WindowsBestFit/bestfit1254.txt) che supporta il turco. |
| bbf\$1unicode\$1cp1255\$1ci\$1as | [Raccolta non deterministica](https://www.unicode.org/Public/MAPPINGS/VENDORS/MICSFT/WindowsBestFit/bestfit1255.txt) che supporta l'ebraico. |
| bbf\$1unicode\$1cp1256\$1ci\$1as | [Raccolta non deterministica](https://www.unicode.org/Public/MAPPINGS/VENDORS/MICSFT/WindowsBestFit/bestfit1256.txt) utilizzata per scrivere lingue che utilizzano lo script arabo. |
| bbf\$1unicode\$1cp1257\$1ci\$1as | [Raccolta non deterministica](https://www.unicode.org/Public/MAPPINGS/VENDORS/MICSFT/WindowsBestFit/bestfit1257.txt) utilizzata per supportare le lingue estone, lettone e lituano. |
| bbf\$1unicode\$1cp1258\$1ci\$1as | [Raccolta non deterministica](https://www.unicode.org/Public/MAPPINGS/VENDORS/MICSFT/WindowsBestFit/bestfit1258.txt) utilizzata per scrivere caratteri vietnamiti. |
| bbf\$1unicode\$1cp874\$1ci\$1as | [Raccolta non deterministica](https://www.unicode.org/Public/MAPPINGS/VENDORS/MICSFT/WindowsBestFit/bestfit874.txt) utilizzata per scrivere caratteri thailandesi. |
| sql\$1latin1\$1general\$1cp1250\$1ci\$1as | [Codifica di caratteri a byte singolo non deterministico](https://www.unicode.org/Public/MAPPINGS/VENDORS/MICSFT/WindowsBestFit/bestfit1250.txt) usata per rappresentare caratteri latini. |
| sql\$1latin1\$1general\$1cp1251\$1ci\$1as | [Raccolta non deterministica](https://www.unicode.org/Public/MAPPINGS/VENDORS/MICSFT/WindowsBestFit/bestfit1251.txt) che supporta i caratteri latini. |
| SQL\$1Latin1\$1General\$1CP1\$1CI\$1AS (default) | [Raccolta non deterministica](https://www.unicode.org/Public/MAPPINGS/VENDORS/MICSFT/WindowsBestFit/bestfit1252.txt) che supporta i caratteri latini. |
| sql\$1latin1\$1general\$1cp1253\$1ci\$1as | [Raccolta non deterministica](https://www.unicode.org/Public/MAPPINGS/VENDORS/MICSFT/WindowsBestFit/bestfit1253.txt) che supporta i caratteri latini. |
| sql\$1latin1\$1general\$1cp1254\$1ci\$1as | [Raccolta non deterministica](https://www.unicode.org/Public/MAPPINGS/VENDORS/MICSFT/WindowsBestFit/bestfit1254.txt) che supporta i caratteri latini. |
| sql\$1latin1\$1general\$1cp1255\$1ci\$1as | [Raccolta non deterministica](https://www.unicode.org/Public/MAPPINGS/VENDORS/MICSFT/WindowsBestFit/bestfit1255.txt) che supporta i caratteri latini. |
| sql\$1latin1\$1general\$1cp1256\$1ci\$1as | [Raccolta non deterministica](https://www.unicode.org/Public/MAPPINGS/VENDORS/MICSFT/WindowsBestFit/bestfit1256.txt) che supporta i caratteri latini. |
| sql\$1latin1\$1general\$1cp1257\$1ci\$1as | [Raccolta non deterministica](https://www.unicode.org/Public/MAPPINGS/VENDORS/MICSFT/WindowsBestFit/bestfit1257.txt) che supporta i caratteri latini. |
| sql\$1latin1\$1general\$1cp1258\$1ci\$1as | [Raccolta non deterministica](https://www.unicode.org/Public/MAPPINGS/VENDORS/MICSFT/WindowsBestFit/bestfit1258.txt) che supporta i caratteri latini. |
| chinese\$1PRC\$1CI\$1AS | Raccolta non deterministica che supporta il cinese (RPC). |
| cyrillic\$1general\$1ci\$1as | Raccolta non deterministica che supporta il cirillico. |
| finnish\$1swedish\$1ci\$1as | Raccolta non deterministica che supporta che supporta il finlandese. |
| french\$1ci\$1as | Raccolta non deterministica che supporta il francese. |
| japanese\$1ci\$1as | Regola di confronto non deterministica che supporta il giapponese. Supportata in Babelfish 2.1.0 e versioni successive. |
| korean\$1wansung\$1ci\$1as | Raccolta non deterministica che supporta il coreano (con ordinamento del dizionario). |
| latin1\$1general\$1ci\$1as | Raccolta non deterministica che supporta i caratteri latini. |
| modern\$1spanish\$1ci\$1as | Raccolta non deterministica che supporta lo spagnolo moderno. |
| polish\$1ci\$1as | Raccolta non deterministica che supporta il polacco. |
| thai\$1ci\$1as | Raccolta non deterministica che supporta il tailandese. |
| traditional\$1spanish\$1ci\$1as | Raccolta non deterministica che supporta lo spagnolo (classificazione tradizionale). |
| turkish\$1ci\$1as | Raccolta non deterministica che supporta il turco. |
| ukrainian\$1ci\$1as | Raccolta non deterministica che supporta l'ucraino. |
| vietnamese\$1ci\$1as | Raccolta non deterministica che supporta il vietnamita. |
È possibile utilizzare le seguenti raccolte come raccolte tra oggetti.
| Dialetto | Opzioni deterministiche | Opzioni non deterministiche |
| --- | --- | --- |
| Arabo | Arabic\$1cs\$1as | Arabic\$1CI\$1AS Arabic\$1CI\$1AI |
| Alfabeto arabo | BBF\$1Unicode\$1CP1256\$1CS\$1AS BBF\$1Unicode\$1Pref\$1CP1256\$1CS\$1AS | BBF\$1Unicode\$1CP1256\$1CI\$1AI BBF\$1Unicode\$1CP1256\$1CS\$1AI |
| Binario | latin1\$1general\$1bin2 BBF\$1Unicode\$1BIN2 | – |
| Lingue dell’Europa centrale e dell’Europa orientale che utilizzano l’alfabeto latino | BBF\$1Unicode\$1CP1250\$1CS\$1AS BBF\$1Unicode\$1Pref\$1CP1250\$1CS\$1AS | BBF\$1Unicode\$1CP1250\$1CI\$1AI BBF\$1Unicode\$1CP1250\$1CS\$1AI |
| Cinese | Chinese\$1PRC\$1CS\$1AS | Chinese\$1PRC\$1CI\$1AS Chinese\$1PRC\$1CI\$1AI |
| Cyrillic\$1General | Cyrillic\$1general\$1cs\$1as | Cyrillic\$1General\$1CI\$1AS Cyrillic\$1General\$1CI\$1AI |
| Alfabeto cirillico | BBF\$1Unicode\$1CP1251\$1CS\$1AS BBF\$1Unicode\$1Pref\$1CP1251\$1CS\$1AS | BBF\$1Unicode\$1CP1251\$1CI\$1AI BBF\$1Unicode\$1CP1251\$1CS\$1AI |
| Estone | Estonian\$1cs\$1as | Estonian\$1CI\$1AS Estonian\$1CI\$1AI |
| Estone, lettone e lituano | BBF\$1Unicode\$1CP1257\$1CS\$1AS BBF\$1Unicode\$1Pref\$1CP1257\$1CS\$1AS | BBF\$1Unicode\$1CP1257\$1CI\$1AI BBF\$1Unicode\$1CP1257\$1CS\$1AI |
| Finnish\$1Swedish | Finnish\$1Swedish\$1CS\$1AS | Finnish\$1Swedish\$1CI\$1AS Finnish\$1Swedish\$1CI\$1AI |
| Francese | French\$1CS\$1AS | French\$1CI\$1AS French\$1CI\$1AI |
| Greco | Greek\$1CS\$1AS | Greek\$1CI\$1AS Greek\$1CI\$1AI |
| Ebraico | BBF\$1Unicode\$1CP1255\$1CS\$1AS BBF\$1Unicode\$1Pref\$1CP1255\$1CS\$1AS Hebrew\$1CS\$1AS | BBF\$1Unicode\$1CP1255\$1CI\$1AI BBF\$1Unicode\$1CP1255\$1CS\$1AI Hebrew\$1CI\$1AS Hebrew\$1CI\$1AI |
| Giapponese (Babelfish 2.1.0 e versioni successive) | Japanese\$1CS\$1AS | Japanese\$1CI\$1AI Japanese\$1CI\$1AS |
| Korean\$1Wamsung | Korean\$1Wamsung\$1CS\$1AS | Korean\$1Wamsung\$1CI\$1AS Korean\$1Wamsung\$1CI\$1AI |
| Caratteri latini per la tabella codici CP1252 | latin1\$1general\$1cs\$1as BBF\$1Unicode\$1General\$1CS\$1AS BBF\$1Unicode\$1General\$1Pref\$1CS\$1AS BBF\$1Unicode\$1Pref\$1CP1\$1CS\$1AS BBF\$1Unicode\$1CP1\$1CS\$1AS | latin1\$1general\$1ci\$1as latin1\$1general\$1ci\$1ai latin1\$1general\$1cs\$1ai BBF\$1Unicode\$1General\$1CI\$1AI BBF\$1Unicode\$1General\$1CS\$1AI BBF\$1Unicode\$1CP1\$1CI\$1AI BBF\$1Unicode\$1CP1\$1CS\$1AI |
| Greco moderno | BBF\$1Unicode\$1CP1253\$1CS\$1AS BBF\$1Unicode\$1Pref\$1CP1253\$1CS\$1AS | BBF\$1Unicode\$1CP1253\$1CI\$1AI BBF\$1Unicode\$1CP1253\$1CS\$1AI |
| Modern\$1Spanish | Modern\$1Spanish\$1CS\$1AS | Modern\$1Spanish\$1CI\$1AS Modern\$1Spanish\$1CI\$1AI |
| Mongolo | Mongolian\$1CS\$1AS | Mongolian\$1CI\$1AS Mongolian\$1CI\$1AI |
| Polacco | Polish\$1CS\$1AS | Polish\$1CI\$1AS Polish\$1CI\$1AI |
| Thai | BBF\$1Unicode\$1CP874\$1CS\$1AS BBF\$1Unicode\$1Pref\$1CP874\$1CS\$1AS Thai\$1CS\$1AS | BBF\$1Unicode\$1CP874\$1CI\$1AI BBF\$1Unicode\$1CP874\$1CS\$1AI Thai\$1CI\$1AS, Thai\$1CI\$1AI |
| Traditional\$1Spanish | Traditional\$1Spanish\$1CS\$1AS | Traditional\$1Spanish\$1CI\$1AS Traditional\$1Spanish\$1CI\$1AI |
| Turco | BBF\$1Unicode\$1CP1254\$1CS\$1AS BBF\$1Unicode\$1Pref\$1CP1254\$1CS\$1AS Turkish\$1CS\$1AS | BBF\$1Unicode\$1CP1254\$1CI\$1AI BBF\$1Unicode\$1CP1254\$1CS\$1AI Turkish\$1CI\$1AS, Turkish\$1CI\$1AI |
| Ucraino | Ukranian\$1CS\$1AS | Ukranian\$1CI\$1AS Ukranian\$1CI\$1AI |
| Vietnamita | BBF\$1Unicode\$1CP1258\$1CS\$1AS BBF\$1Unicode\$1Pref\$1CP1258\$1CS\$1AS Vietnamese\$1CS\$1AS | BBF\$1Unicode\$1CP1258\$1CI\$1AI BBF\$1Unicode\$1CP1258\$1CS\$1AI Vietnamese\$1CI\$1AS Vietnamese\$1CI\$1AI |
## Comportamento della regola di confronto predefinita in Babelfish
In precedenza, la regola di confronto predefinita dei tipi di dati di regola di confronto era `pg_catalog.default`. I tipi di dati e gli oggetti che dipendono da questi tipi di dati seguono la regola di confronto con distinzione tra maiuscole e minuscole. Questa condizione ha un potenziale impatto sugli oggetti T-SQL del set di dati con la regola di confronto senza distinzione tra maiuscole e minuscole. A partire da Babelfish 2.3.0, la regola di confronto predefinita per i tipi di dati di regola di confronto (eccetto TEXT e NTEXT) è uguale alla regola di confronto del parametro `babelfishpg_tsql.server_collation_name`. Quando esegui l'aggiornamento a Babelfish 2.3.0, la regola di confronto predefinita viene selezionata automaticamente al momento della creazione del cluster database, senza alcun impatto visibile.
# Gestione delle raccolte
La libreria ICU fornisce il tracciamento delle raccolte per garantire che gli indici che dipendono dalle raccolte possano essere reindicizzati quando diventa disponibile una nuova versione di ICU. Per verificare se il database corrente contiene regole di confronto che richiedono l'aggiornamento, puoi utilizzare la seguente query dopo aver effettuato la connessione utilizzando `psql` o `pgAdmin`:
```
SELECT pg_describe_object(refclassid, refobjid,
refobjsubid) AS "Collation",
pg_describe_object(classid, objid, objsubid) AS "Object"
FROM pg_depend d JOIN pg_collation c ON refclassid = 'pg_collation'::regclass
AND refobjid = c.oid WHERE c.collversion <> pg_collation_actual_version(c.oid)
ORDER BY 1, 2;
```
Questa query restituisce un output del tipo seguente:
```
Collation | Object
-----------+--------
(0 rows)
```
In questo esempio, non è necessario aggiornare regole di confronto.
Per ottenere un elenco delle regole di confronto predefinite nel database Babelfish, puoi utilizzare `psql` o `pgAdmin` con la seguente query:
```
SELECT * FROM pg_collation;
```
Le raccolte predefinite sono memorizzate nella tabella `sys.fn_helpcollations`. È possibile utilizzare il seguente comando per visualizzare informazioni su una raccolta (ad esempio i flag lcid, style e collate). Per ottenere un elenco di tutte le regole di confronto utilizzando `sqlcmd`, esegui la connessione alla porta T-SQL (1433, per impostazione predefinita) ed esegui la seguente query:
```
1> :setvar SQLCMDMAXVARTYPEWIDTH 40
2> :setvar SQLCMDMAXFIXEDTYPEWIDTH 40
3> SELECT * FROM fn_helpcollations()
4> GO
name description
---------------------------------------- ----------------------------------------
arabic_cs_as Arabic, case-sensitive, accent-sensitive
arabic_ci_ai Arabic, case-insensitive, accent-insensi
arabic_ci_as Arabic, case-insensitive, accent-sensiti
bbf_unicode_bin2 Unicode-General, case-sensitive, accent-
bbf_unicode_cp1250_ci_ai Default locale, code page 1250, case-ins
bbf_unicode_cp1250_ci_as Default locale, code page 1250, case-ins
bbf_unicode_cp1250_cs_ai Default locale, code page 1250, case-sen
bbf_unicode_cp1250_cs_as Default locale, code page 1250, case-sen
bbf_unicode_pref_cp1250_cs_as Default locale, code page 1250, case-sen
bbf_unicode_cp1251_ci_ai Default locale, code page 1251, case-ins
bbf_unicode_cp1251_ci_as Default locale, code page 1251, case-ins
bbf_unicode_cp1254_ci_ai Default locale, code page 1254, case-ins
...
(124 rows affected)
```
Le righe 1 e 2 mostrate nell'esempio restringono l'output solo ai fini della leggibilità della documentazione.
```
1> SELECT SERVERPROPERTY('COLLATION')
2> GO
serverproperty
---------------------------------------------------------------------------
sql_latin1_general_cp1_ci_as
(1 rows affected)
1>
```
# Limitazioni di regole di confronto e differenze di comportamento
Babelfish utilizza la libreria ICU per il supporto delle raccolte. PostgreSQL è costruito con una versione specifica di ICU e può corrispondere al massimo a una versione di un confronto. Le variazioni tra le versioni sono inevitabili, così come le piccole variazioni nel tempo man mano che le lingue evolvono. Nella sezione seguente sono disponibili le limitazioni note e le variazioni di comportamento delle regole di confronto Babelfish:
+ **Indici e dipendenza tipo regola di confronto**: un indice su un tipo definito dall'utente che dipende dalla libreria di regole di confronto ICU (International Components for Unicode) (la libreria utilizzata da Babelfish) non viene invalidato quando la versione della libreria viene modificata.
+ **Funzione COLLATIONPROPERTY**: le proprietà delle regole di confronto sono implementate solo per le regole di confronto Babelfish BBF supportate. Per ulteriori informazioni, consulta [Babelfish supported collations table](babelfish-collations.md#bfish-collations-table).
+ **Differenze regole di ordinamento Unicode**: le regole di confronto SQL per SQL Server ordinano i dati con codifica Unicode (`nchar` e `nvarchar`) in modo diverso rispetto ai dati senza codifica Unicode (`char` e `varchar`). I database Babelfish sono sempre codificati UTF-8 e applicano sempre regole di ordinamento Unicode in modo coerente, a prescindere dal tipo di dati, pertanto l'ordinamento per `char` o `varchar` è uguale a quello per `nchar` o `nvarchar`.
+ **Regole di confronto secondarie uguali e comportamento di ordinamento**: la regola di confronto predefinita Unicode secondaria uguale (`CI_AS`) ordina i segni di punteggiatura e altri caratteri non alfanumerici prima dei caratteri numerici e i caratteri numerici prima dei caratteri alfabetici. Tuttavia, l'ordine di punteggiatura e altri caratteri speciali sono diversi.
+ **Regole di confronto terziarie, soluzione alternativa per ORDER BY**: le regole di confronto SQL, ad esempio `SQL_Latin1_General_Pref_CP1_CI_AS`, supportano la funzione `TERTIARY_WEIGHTS` e la capacità di ordinare stringhe che si confrontano allo stesso modo in una regola di confronto `CI_AS` da ordinare prima in maiuscolo: `ABC`, `ABc`, `AbC`, `Abc`, `aBC`, `aBc`, `abC` e infine `abc`. Pertanto la funzione analitica `DENSE_RANK OVER (ORDER BY column)` valuta queste stringhe come aventi lo stesso rango, ma le ordina prima in maiuscolo all'interno di una partizione.
Puoi ottenere un risultato simile con Babelfish aggiungendo una clausola `COLLATE`alla clausola `ORDER BY` che specifica una raccolta terziaria `CS_AS` che specifica `@colCaseFirst=upper`. Tuttavia, il modificatore `colCaseFirst` si applica esclusivamente alle stringhe terziarie uguali (piuttosto che secondarie-uguali come una regola di confronto `CI_AS`). Pertanto, non è possibile emulare raccolte SQL terziarie utilizzando una singola relazione ICU.
Come soluzione alternativa, consigliamo di modificare le applicazioni che utilizzano la raccolta `SQL_Latin1_General_Pref_CP1_CI_AS` per utilizzare la raccolta `BBF_SQL_Latin1_General_CP1_CI_AS` prima di iniziare la raccolta. Quindi aggiungere `COLLATE BBF_SQL_Latin1_General_Pref_CP1_CS_AS`a qualsiasi clausola `ORDER BY` per questa colonna.
+ **Espansione di caratteri**: un'espansione di caratteri tratta un singolo carattere come uguale a una sequenza di caratteri a livello primario. La regola di confronto `CI_AS` predefinita di SQL Server supporta l'espansione di caratteri. Le regole di confronto ICU supportano l'espansione di caratteri solo per regole di confronto senza distinzione caratteri accentati/non accentati.
Quando è richiesta l'espansione dei caratteri, utilizzare una raccolta `AI` per confronti. Tuttavia, tali raccolte non sono attualmente supportate dall'operatore LIKE.
+ **Codifica char e varchar**: quando le regole di confronto SQL vengono utilizzate per i tipi di dati `char` o `varchar`, l'ordinamento per i caratteri precedenti a ASCII 127 è determinato dalla pagina codice specifica per tale regola di confronto SQL. Per le regole di confronto SQL, le stringhe dichiarate come `char` o `varchar` potrebbero essere ordinate in modo diverso rispetto alle stringhe dichiarate come `nchar` o `nvarchar`.
PostgreSQL codifica tutte le stringhe con la codifica del database, pertanto tutti i caratteri vengono convertiti in UTF-8 e ordinati utilizzando regole Unicode.
Poiché le regole di confronto SQL ordinano i tipi di dati nchar e nvarchar utilizzando regole Unicode, Babelfish codifica tutte le stringhe sul server utilizzando UTF-8. Babelfish ordina le stringhe nchar e nvarchar nello stesso modo in cui ordina le stringhe char e varchar, usando regole Unicode.
+ **Caratteri supplementari**: le funzioni SQL Server `NCHAR`, `UNICODE`, e `LEN` supportano i caratteri per i punti di codice al di fuori di Unicode Basic Multilingual Plane (BMP). Al contrario, le raccolte non SC utilizzano caratteri di coppia surrogata per gestire caratteri supplementari. Per i tipi di dati Unicode, SQL Server può rappresentare fino a 65.535 caratteri utilizzando UCS-2 o l'intervallo Unicode completo (1,114,114 caratteri) se si utilizzano caratteri supplementari.
+ **Regole di confronto con distinzione Kana (KS)**: una regola di confronto con distinzione Kana (KS) gestisce i caratteri Kana giapponesi `Hiragana` e `Katakana` in modo diverso. ICU supporta lo standard di raccolta giapponese`JIS X 4061`. Il modificatore di localizzazione `colhiraganaQ [on | off]` oramai obsoleto potrebbe fornire la stessa funzionalità delle raccolte KS. Tuttavia, le raccolte KS con lo stesso nome di SQL Server non sono attualmente supportate da Babelfish.
+ **Regole di confronto con distinzione della larghezza (WS)**: quando un carattere a byte singolo (mezza larghezza) e lo stesso carattere rappresentato come carattere a doppio byte (larghezza intera) vengono trattati in modo diverso, la regola di confronto viene chiamata *con distinzione della larghezza (WS)*. Le raccolte WS con lo stesso nome di SQL Server non sono attualmente supportate da Babelfish.
+ **Regole di confronto con distinzione selettore di variazione (VSS)**: le regole di confronto con distinzione selettore di variazione (VSS) distinguono tra selettori variazione ideografica nelle regole di confronto giapponesi `Japanese_Bushu_Kakusu_140` e `Japanese_XJIS_140`. Una sequenza di varianti è costituita da un carattere base più un selettore di varianti aggiuntivo. Se non viene selezionata l'opzione `_VSS`, il selettore delle varianti non è considerato nel confronto.
Le relazioni VSS attualmente non sono supportate da Babelfish.
+ **Regole di confronto BIN e BIN2**: una regola di confronto BIN2 ordina i caratteri in base all'ordine dei punti di codice. L'ordine binario byte per byte di UTF-8 conserva l'ordine dei punti di codice Unicode, quindi è probabile che questo sia anche il confronto con le migliori raccolte. Se l'ordine dei punti di codice Unicode funziona per un'applicazione, prendere in considerazione l'utilizzo di una raccolta BIN2. Tuttavia, l'utilizzo di una raccolta BIN2 può comportare la visualizzazione dei dati sul client in un ordine culturalmente inaspettato. I nuovi mapping con caratteri minuscoli vengono aggiunti a Unicode man mano che il tempo progredisce, quindi la funzione `LOWER` potrebbe funzionare in modo diverso su diverse versioni di ICU. Questo è un caso speciale del problema di controllo delle versioni di raccolta più generale piuttosto che come qualcosa di specifico per la raccolta BIN2.
Babelfish fornisce la raccolta `BBF_Latin1_General_BIN2` con la distribuzione Babelfish da collare nell'ordine dei punti di codice Unicode. In una raccolta BIN solo il primo carattere viene ordinato come wchar. I caratteri rimanenti vengono ordinati byte per byte, in modo efficace in ordine di codice in base alla sua codifica. Questo approccio non segue le regole di confronto Unicode e non è supportato da Babelfish.
+ **Regole di confronto non deterministiche e limitazione CHARINDEX**: per versioni di Babelfish precedenti alla versione 2.1.0, non è possibile utilizzare CHARINDEX con regole di confronto non deterministiche. Per impostazione predefinita, Babelfish utilizza una regola di confronto senza distinzione maiuscole/minuscole (non deterministica). L'utilizzo di CHARINDEX per le versioni precedenti di Babelfish genera il seguente errore di runtime:
```
nondeterministic collations are not supported for substring searches
```
**Nota**
Questa limitazione e la soluzione alternativa si applicano solo a Babelfish versione 1.x (Aurora PostgreSQL versioni 13.x). Babelfish 2.1.0 e versioni successive non presentano questo problema.
Puoi risolvere il problema in uno dei seguenti modi:
+ Converti esplicitamente l'espressione in un confronto con distinzione tra maiuscole e minuscole e trasforma entrambi gli argomenti applicando LOWER o UPPER. Ad esempio, `SELECT charindex('x', a) FROM t1` diventa ciò che è indicato qui di seguito:
```
SELECT charindex(LOWER('x'), LOWER(a COLLATE sql_latin1_general_cp1_cs_as)) FROM t1
```
+ Crea una funzione SQL f\$1charindex e sostituisci le chiamate CHARINDEX con le chiamate alla seguente funzione:
```
CREATE function f_charindex(@s1 varchar(max), @s2 varchar(max)) RETURNS int
AS
BEGIN
declare @i int = 1
WHILE len(@s2) >= len(@s1)
BEGIN
if LOWER(@s1) = LOWER(substring(@s2,1,len(@s1))) return @i
set @i += 1
set @s2 = substring(@s2,2,999999999)
END
return 0
END
go
```
# Gestione degli errori di Babelfish con escape hatch
Babelfish simula il comportamento SQL per flusso di controllo e stato della transazione quando possibile. Se Babelfish rileva un errore, restituisce un codice di errore simile al codice di errore di SQL Server. Se Babelfish non riesce a mappare l'errore a un codice SQL Server, restituisce un codice di errore fisso (`33557097`) ed esegue azioni specifiche in base al tipo di errore, come segue:
+ Per errori in fase di compilazione, Babelfish esegue il rollback della transazione.
+ Per errori di runtime, Babelfish termina il batch ed esegue il rollback della transazione.
+ Per errore di protocollo tra client e server, non viene eseguito il rollback della transazione.
Se un codice di errore non può essere mappato a un codice equivalente e il codice per un errore simile è disponibile, il codice di errore viene mappato al codice alternativo. Ad esempio, i comportamenti che causano i codici SQL Server `8143` e `8144` sono entrambi mappati su `8143`.
Gli errori che non possono essere mappati non rispettano un costrutto `TRY... CATCH`.
È possibile utilizzare `@@ERROR` per restituire un codice di errore di SQL Server oppure la funzione `@@PGERROR` per restituire un codice di errore PostgreSQL. È possibile utilizzare anche la funzione `fn_mapped_system_error_list` per restituire un elenco di codici di errore mappati. Per informazioni sui codici di errore PostgreSQL, consulta il sito web di [https://www.postgresql.org/docs/current/errcodes-appendix.html](https://www.postgresql.org/docs/current/errcodes-appendix.html).
## Modifica delle impostazioni dell'escape hatch Babelfish
Per gestire meglio le istruzioni che potrebbero non andare a buon fine, Babelfish definisce alcune opzioni chiamate escape hatch. Una *via di fuga* è un'opzione che specifica il comportamento di Babelfish quando incontra una caratteristica o una sintassi non supportata.
Puoi utilizzare la procedura memorizzata `sp_babelfish_configure` per controllare le impostazioni di una via di fuga. Usa lo script per impostare la via di fuga su `ignore` o `strict`. Se è impostata su `strict`, Babelfish restituisce un errore che è necessario correggere prima di continuare.
Includere la parola chiave `server` per applicare le modifiche alla sessione corrente e a livello di cluster.
L'utilizzo è il seguente:
+ Per elencare tutte le vie di fuga e il relativo stato, oltre alle informazioni sull'utilizzo, eseguire `sp_babelfish_configure`.
+ Per elencare i tratteggi escape denominati e i relativi valori, per la sessione corrente o in tutto il cluster, eseguire il comando `sp_babelfish_configure 'hatch_name'` dove `hatch_name` è l'identificatore di una o più vie di fuga. *hatch\$1name* può utilizzare caratteri jolly SQL, ad esempio '%'.
+ Per impostare una o più vie di fuga sul valore specificato, eseguire `sp_babelfish_configure ['hatch_name' [, 'strict'|'ignore' [, 'server']]`. Per rendere le impostazioni permanenti a livello di cluster, includi la parola chiave `server`, come nell'esempio seguente:
```
EXECUTE sp_babelfish_configure 'escape_hatch_unique_constraint', 'ignore', 'server'
```
Per impostarle solo per la sessione corrente, non utilizzare `server`.
+ Per ripristinare tutti gli escape hatch ai valori predefiniti, esegui `sp_babelfish_configure 'default'` (Babelfish 1.2.0 e versioni successive).
La stringa che identifica il tratteggio (o i tratteggi) può includere caratteri jolly SQL. Ad esempio, il seguente imposta tutte le trattezze di escape sintassi su `ignore` per il cluster Aurora PostgreSQL.
```
EXECUTE sp_babelfish_configure '%', 'ignore', 'server'
```
Nella tabella seguente è possibile trovare descrizioni e valori predefiniti per gli escape hatch predefiniti di Babelfish.
| Via di fuga | Descrizione | Default |
| --- | --- | --- |
| escape\$1hatch\$1checkpoint | Consente l'uso dell'istruzione CHECKPOINT nel codice procedurale, ma l'istruzione CHECKPOINT non è attualmente implementata. | ignora |
| escape\$1hatch\$1constraint\$1name\$1for\$1default | Controlla il comportamento di Babelfish correlato ai nomi dei vincoli predefiniti. | ignora |
| escape\$1hatch\$1database\$1misc\$1options | Controlla il comportamento di Babelfish correlato alle seguenti opzioni su CREATE DATABASE: CONTAINMENT, DB\$1CHAINING, TRUSTWORTHY, PERSISTENT\$1LOG\$1BUFFER. | ignora |
| escape\$1hatch\$1for\$1replication | Controlla il comportamento di Babelfish correlato alla clausola [NOT] FOR REPLICATION durante la creazione o la modifica di una tabella. | strict |
| escape\$1hatch\$1fulltext | Controlla il comportamento di Babelfish correlato alle funzionalità FULLTEXT, ad esempio DEFAULT\$1FULLTEXT\$1LANGUAGE in CREATE/ALTER DATABASE, CREATE FULLTEXT INDEX o sp\$1fulltext\$1database. | ignora |
| escape\$1hatch\$1ignore\$1dup\$1key | Controlla il comportamento di Babelfish relativo a CREATE/ALTER TABLE e CREATE INDEX. Quando IGNORE\$1DUP\$1KEY=ON, genera un errore quando impostato su `strict` (impostazione predefinita) o ignora l'errore quando impostato su `ignore` (Babelfish 1.2.0 e versioni successive). | strict |
| escape\$1hatch\$1index\$1clustering | Controlla il comportamento di Babelfish correlato alle parole chiave CLUSTERED o NONCLUSTERED per indici e vincoli PRIMARY KEY o UNIQUE. Quando CLUSTERED viene ignorato, l'indice o il vincolo viene ancora creato come se fosse stato specificato NON CLUSTERED. | ignora |
| escape\$1hatch\$1index\$1columnstore | Controlla il comportamento di Babelfish relativo alla clausola COLUMNSTORE. Se si specifica `ignore`, Babelfish crea un normale indice B-tree. | strict |
| escape\$1hatch\$1join\$1hints | Controlla il comportamento delle parole chiave in un operatore JOIN: LOOP, HASH, MERGE, REMOTE, REDUCE, REDISTRIBUITE, REPLICATE. | ignora |
| escape\$1hatch\$1language\$1non\$1english | Controlla il comportamento di Babelfish relativo a lingue diverse dall'inglese per i messaggi sullo schermo. Al momento, Babelfish supporta solo `us_english` per messaggi sullo schermo. SET LANGUAGE potrebbe utilizzare una variabile contenente il nome della lingua, quindi la lingua effettiva impostata può essere rilevata solo in fase di esecuzione. | strict |
| escape\$1hatch\$1login\$1hashed\$1password | Se ignorato, elimina l'errore per la parola chiave `HASHED` per `CREATE LOGIN` e `ALTER LOGIN`. | strict |
| escape\$1hatch\$1login\$1misc\$1options | Se ignorato, elimina l'errore per altre parole chiave oltre `HASHED`, `MUST_CHANGE`, `OLD_PASSWORD`, e `UNLOCK` per `CREATE LOGIN` and `ALTER LOGIN`. | strict |
| escape\$1hatch\$1login\$1old\$1password | Se ignorato, elimina l'errore per la parola chiave `OLD_PASSWORD` per `CREATE LOGIN` e `ALTER LOGIN`. | strict |
| escape\$1hatch\$1login\$1password\$1must\$1change | Se ignorato, elimina l'errore per la parola chiave `MUST_CHANGE` per `CREATE LOGIN` e `ALTER LOGIN`. | strict |
| escape\$1hatch\$1login\$1password\$1unlock | Se ignorato, elimina l'errore per la parola chiave `UNLOCK` per `CREATE LOGIN` e `ALTER LOGIN`. | strict |
| escape\$1hatch\$1nocheck\$1add\$1constraint | Controlla il comportamento di Babelfish relativo alla clausola WITH CHECK o NOCHECK per i vincoli. | strict |
| escape\$1hatch\$1nocheck\$1existing\$1constraint | Controlla il comportamento di Babelfish correlato ai vincoli FOREIGN KEY o CHECK. | strict |
| escape\$1hatch\$1query\$1hints | Controlla il comportamento di Babelfish correlato ai suggerimenti sulle query. Quando questa opzione è impostata per ignorare, il server ignora i suggerimenti che utilizzano la clausola OPTION (...) per specificare gli aspetti di elaborazione delle query. Esempi includono SELECT FROM... OPZIONE (MERGE JOIN HASH, MAXRECURSION 10)). | ignora |
| escape\$1hatch\$1rowversion | Controlla il comportamento dei tipi di dati ROWVERSION e TIMESTAMP. Per informazioni sull'utilizzo, consulta [Utilizzo di funzionalità Babelfish con implementazione limitata](babelfish-compatibility.tsql.limited-implementation.md). | strict |
| escape\$1hatch\$1schemabinding\$1function | Controlla il comportamento di Babelfish relativo alla clausola WITH SCHEMABINDING. Per impostazione predefinita, la clausola WITH SCHEMABINDING viene ignorata quando specificata con il comando CREATE o ALTER FUNCTION. | ignora |
| escape\$1hatch\$1schemabinding\$1procedure | Controlla il comportamento di Babelfish relativo alla clausola WITH SCHEMABINDING. Per impostazione predefinita, la clausola WITH SCHEMABINDING viene ignorata quando specificata con il comando CREATE o ALTER PROCEDURE. | ignora |
| escape\$1hatch\$1rowguidcol\$1column | Controlla il comportamento di Babelfish correlato alla clausola ROWGUIDCOL durante la creazione o la modifica di una tabella. | strict |
| escape\$1hatch\$1schemabinding\$1trigger | Controlla il comportamento di Babelfish relativo alla clausola WITH SCHEMABINDING. Per impostazione predefinita, la clausola WITH SCHEMABINDING viene ignorata quando specificata con il comando CREATE o ALTER TRIGGER. | ignora |
| escape\$1hatch\$1schemabinding\$1view | Controlla il comportamento di Babelfish relativo alla clausola WITH SCHEMABINDING. Per impostazione predefinita, la clausola WITH SCHEMABINDING viene ignorata quando specificata con il comando CREATE o ALTER VIEW. | ignora |
| escape\$1hatch\$1session\$1settings | Controlla il comportamento di Babelfish verso affermazioni SET a livello di sessione non supportate. | ignora |
| escape\$1hatch\$1showplan\$1all | Controlla il comportamento di Babelfish relativo a SET SHOWPLAN\$1ALL e SET STATISTICS PROFILE. Se impostati su "ignore", si comportano come SET BABELFISH\$1SHOWPLAN\$1ALL e SET BABELFISH\$1STATISTICS PROFILE, se impostati su "strict", vengono ignorati silenziosamente. | strict |
| escape\$1hatch\$1storage\$1on\$1partition | Controlla il comportamento di Babelfish correlato alla clausola `ON partition_scheme column ` durante la definizione del partizionamento. Babelfish attualmente non implementa il partizionamento. | strict |
| escape\$1hatch\$1storage\$1options | Via di fuga su qualsiasi opzione di archiviazione utilizzata in CREATE, ALTER DATABASE, TABLE, INDEX. Sono incluse le clausole (LOG) ON, TEXTIMAGE\$1ON, FILESTREAM\$1ON che definiscono le posizioni di archiviazione (partizioni, gruppi di file) per tabelle, indici e vincoli e anche per un database. Questa impostazione di escape hatch si applica a tutte queste clausole (inclusi ON [PRIMARY] e ON “DEFAULT”). L'eccezione è quando viene specificata una partizione per una tabella o un indice con ON partition\$1scheme (colonna). | ignora |
| escape\$1hatch\$1table\$1hints | Controlla il comportamento dei suggerimenti di tabella specificati utilizzando la clausola WITH (...). | ignora |
| escape\$1hatch\$1unique\$1constraint | Se impostato su strict, un'oscura differenza semantica tra SQL Server e PostgreSQL nella gestione dei valori NULL nelle colonne indicizzate può generare errori. La differenza semantica emerge solo in casi d'uso non realistici, quindi puoi impostare questo hatch di escape su "ignore" per evitare di vedere l'errore. Deprecato dalle seguenti versioni: 3.6.0 e versioni successive, 4.2.0 e versioni successive | strict |