Supporto a NVARCHAR per campo `rpt.denominazione_attestante`

[pperliti]

Descrizione del Bug
Dall'esame dei log di GovPay ho notato un paio di errori in fase di SendRTV2 legati alla lunghezza della denominazione del PSP. In particolare il PSP "Banca Popolare di xxxxxx e xxxxxxxxxx - società cooperativa per azioni" ha denominazione lunga 70 caratteri ma contiene una lettera accentata che "occupa più spazio" e questo genera l'errore:

String or binary data would be truncated in table 'dbo.rpt', column 'denominazione_attestante'. Truncated value: 'Banca Popolare di xxxxxx e xxxxxxxxxx - società cooperativa per azion'.

Come riprodurlo:
Basta utilizzare un PSP con nome pari a 70 caratteri e contenente una o più lettere accentate.

Risultato atteso:
Si potrebbe fare in modo che il layer di persistenza su DB troncasse eventuali campi più lunghi del dovuto. In alternativa, utilizzare il tipo NVARCHAR in luogo di VARCHAR (almeno per quei campi di lunghezza variabile come nominativi e denominazioni).

Ambiente:

• OS: Windows Server 2022
• GovPay: 3.7.6
• AS: WildFly 26
• Java: OpenJDK 11
• DBMS: MS SQL Server 2019

Note aggiuntive:
Anziché aumentare la dimensiona della colonna 'dbo.rpt.denominazione_attestante' (non sapendo se potesse avere ripercussioni di qualunque genere) l'ho convertita da VARCHAR a NVARCHAR (sperando di aver fatto bene :-).

Due domande correlate:

1. esiste un modo corretto per recuperare manualmente questo errore su GovPay? (il versamento risulta ancora NON_ESEGUITO)
2. esiste la possibilità di essere notificati in qualche modo (es. via mail) in caso di errori legati al fallimento di una ricezione di una RT?

Grazie mille.

[nardil]

CIao Paolo,

puoi sicuramente aumentare la dimensione della colonna e darci conferma che questo risolve il problema.

Chiedo a @pintorig di:

• aggiungere questa casistica alla testsuite
• verificare se sia una problematica solo di MS SQL Server, eventualmente prevedere una patch che estenda la dimensione della colonna
• verificare, se si riesce a replicare il problema, che GovPay termini in uno stato consistente

Per le domande correlate:

1. Ti facciamo sapere, ma dovrebbe essere possibile caricare manualmente la RT (che puoi recuperare dal Giornale degli Eventi) tramite console.
2. GovPay non ha un servizio di notifica mail degli errori. Puoi pero' utilizzare il Giornale degli Eventi per individuare queste eventualita da agganciare ad un servizio di monitoraggio che faccia quello che richiedi.

[pperliti]

Grazie Lorenzo!
Per:

1. OK, attendo grazie
2. Ottimo, non ci avevo pensato!

@pintorig Errori simili li ho riscontrati (per altre applicazioni) in passato anche su Oracle, credo sia un comportamento normale (e tipicamente legato a countries che usano alfabeti estesi). Forse, più che aumentare le colonne, converrebbe passare a NVARCHAR (National VARCHAR) che dovrebbe supportare gli alfabeti estesi (ed è supportato dalla maggioranza degli RDBMS).
Aumentare solo la dimensione delle colonne non elimina completamente il rischio perché l'errore potrebbe comunque presentarsi se il valore da memorizzare ha lunghezza prossima al valore massimo previsto e contiene molti caratteri 'estesi' (accenti e simili), mentre la conversione in NVARCHAR dovrebbe tutelare maggiormente ed essere trasparente.

A proposito, la codepage utilizzata nel mio caso per il DB è Latin1_General_100_CI_AI_SC_UTF8.