Dopo aver visto come inserire le immagini nella griglia ordini della desktop consolle, in questo video vi mostro l’integrazione tra Business Cube e lo spedizioniere BRT mediante l’utilizzo dello loro Rest Api per l’invio ai loro server dell spedizioni da ritirare per la consegna con generazione dell’etichetta per la spedizione riportante i dati del destinatario ed i riferimenti dell’ordine.
In questo articolo vedremo come inserire delle immagini nella griglia ordini della desktop consolle di Business Cube. In questo caso particolare gli ordini provengono da un’importazione da una piattaforma e-commerce e le immagini vengono prelevate direttamente dal sito tramite l’url dell’immagine stessa.
La prima operazione è stata quella di aggiungere il campo testo mo_hhimg alla tabella movord. In questo memorizzeremo il link al file proveniente dalla procedura di importazione. (Non stò a dilungarmi sulla procedura di import dal sito poichè si tratta di un sito costruito ad hoc. In pratica c’è un oggetto WebClient che richiama i dati da un link del sito che restituisce un elenco di ordini)
Dopo aver ereditato la DLL BNDKKONS, tramite le funzioni di editing aggiungiamo la colonna di griglia tipo text agganciandola alla colonna xx_hhimg.
Nell’ovveride della funzione Apri all’interno della BFDKKONS aggiungiamo la colonna xx_hhimg insieme all’aggiunta dell’Handler sulla ColumnChanged per caricare le immagini su ogni riga della griglia ordini della consolle.
Nella funzione inseriamo il ridemensionamento dell’immagine impostando una larghezza massima di 120px facendo in modo di mantere le proporzioni.
In questa verticalizzazione è stata inoltre effettuata un’integrazione con il corriere BRT per la stampe delle etichette di spedizione alla creazione del documento di vendita generato dall’evasione dell’ordine.
Cosa fare quando il database è in modalità RESTORING?
Durante il ripristino di un backup di un database SQL Server, probabilmente vi è capitato che il questo rimanesse in modalità RESTORING.
Questa modalità indica che il database è in fase di ripristino da un backup o da una serie di backup. Questa fase può durare da pochi minuti a diverse ore a seconda della dimensione del database, del numero e del tipo di backup da applicare, e delle prestazioni del sistema.
In questa modalità il database non è accessibile e non è possibile eseguire altre operazioni di backup o ripristino sullo stesso database.
Perché il database è in modalità RESTORING?
Quando si ripristina un backup completo del database, il processo di ripristino copia i dati dal backup al database e applica le transazioni registrate nel log delle transazioni. Questo garantisce che il database sia consistente e rifletta lo stato al momento del backup.
Tuttavia, se si vuole ripristinare anche uno o più backup differenziali o del log delle transazioni, è necessario specificare l’opzione WITH NORECOVERY nel comando RESTORE DATABASE. Questa opzione impedisce al processo di ripristino di terminare e di rendere il database accessibile. In questo modo, si può applicare il backup successivo nella sequenza senza perdere le modifiche registrate nel log delle transazioni.
Quando si applica l’ultimo backup della sequenza, si deve specificare l’opzione WITH RECOVERY nel comando RESTORE DATABASE. Questa opzione segnala al processo di ripristino di terminare e di rendere il database accessibile. Se non si specifica questa opzione, il database rimane in modalità RESTORING finché non si esegue manualmente il comando RESTORE DATABASE WITH RECOVERY.
Come uscire dalla modalità RESTORING?
Se il database è in modalità RESTORING perché si sta applicando una sequenza di backup, basta eseguire il comando RESTORE DATABASE WITH RECOVERY sull’ultimo backup della sequenza per uscire dalla modalità RESTORING e rendere il database accessibile.
Se invece il database è in modalità RESTORING perché si è interrotto il processo di ripristino o perché si è verificato un errore, si possono seguire due strade:
In conclusione, la modalità RESTORING indica che il database è in fase di ripristino da uno o più backup. Per uscire da questa modalità e rendere il database accessibile, è necessario specificare l’opzione WITH RECOVERY nell’ultimo comando RESTORE DATABASE della sequenza. Se invece si vuole annullare il processo di ripristino, si può eseguire lo stesso comando senza specificare alcun backup.
Se avete mai lavorato con SQL Server, probabilmente vi siete imbattuti in una situazione in cui un database ha lo stato RECOVERING. Questo significa che il database è in fase di ripristino dopo un’operazione di backup, restore, failover o altro evento che richiede la ricostruzione dei dati. In questo post, vedremo cosa succede durante il processo di ripristino, come verificare lo stato di un database e come risolvere eventuali problemi.
Il processo di ripristino
Quando un database SQL Server ha lo stato RECOVERING, significa che il motore di database sta eseguendo una serie di passaggi per riportare il database in uno stato consistente e pronto per l’uso. Questi passaggi sono:
Durante il processo di ripristino, il database non è accessibile agli utenti o alle applicazioni. Il tempo necessario per il ripristino dipende da diversi fattori, come la dimensione del log delle transazioni, il numero e la complessità delle transazioni da ripetere o annullare, le prestazioni del sistema e altri eventi concorrenti.
Tuttavia, in alcuni casi, il database può rimanere bloccato nello stato RECOVERING per un tempo eccessivo o indefinito, impedendo l’accesso ai dati. Questo può accadere per vari motivi, come ad esempio:
Per risolvere questi problemi, si possono provare le seguenti soluzioni:
Queste sono alcune delle possibili soluzioni per risolvere i problemi se un database SQL Server ha lo stato RECOVERING. Si consiglia di eseguire sempre un backup dei dati prima di effettuare qualsiasi operazione di ripristino e di consultare la documentazione ufficiale di SQL Server per maggiori dettagli e istruzioni.
Se il vostro database SQL Server è danneggiato o non avviabile, potete provare a ripristinarlo usando la modalità EMERGENZA. Questa modalità consente di accedere al database anche se è in uno stato inconsistente, e di eseguire operazioni di riparazione o di recupero dei dati.
La modalità EMERGENZA si attiva impostando lo stato del database a 1 con il comando ALTER DATABASE. Ad esempio:
ALTER DATABASE MioDatabase SET EMERGENCY;
Una volta attivata la modalità EMERGENZA, il database diventa accessibile solo ai membri del ruolo sysadmin. Inoltre, il database viene aperto in sola lettura e non viene eseguita alcuna operazione di rollback o di recupero.
Per ripristinare il database, è necessario eseguire i seguenti passi:
1) Verificare l’integrità fisica del file di dati e del file di log del database con il comando DBCC CHECKDB. Questo comando restituisce un report con gli eventuali errori rilevati e le possibili azioni di riparazione. Ad esempio:
DBCC CHECKDB (MioDatabase) WITH NO_INFOMSGS, ALL_ERRORMSGS;
2) Se il comando DBCC CHECKDB non restituisce errori, significa che il database è integro e può essere riportato in modalità normale con il comando ALTER DATABASE. Ad esempio:
ALTER DATABASE MioDatabase SET ONLINE;
3) Se invece il comando DBCC CHECKDB restituisce errori, significa che il database è danneggiato e richiede una riparazione. La riparazione può essere eseguita con il comando DBCC CHECKDB con l’opzione REPAIR_ALLOW_DATA_LOSS. Questa opzione consente di eliminare le pagine o le righe corrotte dal database, ma comporta una perdita di dati. Ad esempio:
DBCC CHECKDB (‘MioDatabase’, REPAIR_ALLOW_DATA_LOSS);
4) Dopo aver eseguito la riparazione, è necessario verificare nuovamente l’integrità del database con il comando DBCC CHECKDB. Se il comando non restituisce errori, significa che la riparazione è stata effettuata con successo e il database può essere riportato in modalità normale con il comando ALTER DATABASE. Ad esempio:
ALTER DATABASE MioDatabase SET ONLINE;
5) Se invece il comando DBCC CHECKDB restituisce ancora errori, significa che la riparazione non è stata sufficiente e il database è irrecuperabile. In questo caso, l’unica soluzione è ripristinare il database da un backup valido.
La modalità EMERGENZA è un’ultima risorsa per tentare di recuperare un database SQL Server danneggiato. Si raccomanda di usarla solo dopo aver esaurito tutte le altre opzioni e di essere consapevoli dei rischi di perdita di dati. Inoltre, si raccomanda di effettuare sempre dei backup regolari del database e di verificarne la validità.