Finalmente ci siamo. L'ultima puntata della nostra serie è giunta, con quest'articolo che non solo illustra la soluzione basata su ADO ma introduce anche nuove funzionalità e capacità al nostro famoso sito "PlayWorld, un mondo di giochi". Vorrei rilevare che con questa soluzione sono stati risolti alcuni bug che i gentili e numerosi lettori hanno sollevato. Quindi, un ringraziamento particolare a quanti hanno contribuito.

Introduzione

Come promesso, la soluzione presentata in quest'articolo è basata sui Disconnected Recordset di ADO, o se preferite alla capacità di persistenza dei Recordset che questo potente modello ad aggetti OLEDB fornisce. Le funzionalità aggiuntive cui accennavo prima sono le seguenti:

• Introduzione del GLOBAL.ASA (per alcune funzioni amministrative)
• Abbandono della tabella CARRELLO
• Abilitato l'inserimento ordini con modifica della tabella relativa (ORDINI)
• Introduzione di alcune query
• Amministrazione degli ordini (solo visualizzazione) web based
• Aggiunta di una pagina di visualizzazione carrello VISCARRELLO.ASP , separata dalla logica contenuta in CARRELLO.ASP .

Nei prossimi paragrafi saranno analizzati i singoli punti, dopo aver introdotto alcuni importanti concetti.

ADO Disconnected Recordset

ADO (ActiveX Data Object) è una collezione di oggetti COM per l'accesso ai dati attraverso OLEDB; è sicuramente uno degli strumenti che hanno avuto maggiore successo. La sua massiccia diffusione è dovuta principalmente a due grandi protagonisti del Web degli ultimi anni, cioè ASP 2.0 e IIS 4.0. Il modello offerto da ADO semplifica e rende potente l'accesso ai dati (e meta dati), grazie ad interfacce intuitive e di semplice implementazione.

L'oggetto ADODB.Recordset ha tra le sue caratteristiche di base quella di rendere persistenti (quindi su di un file) i dati in esso contenuti. Il formato di questo file ADO può essere di tipo binario oppure XML , al fine di offrire il supporto per il nuovo linguaggio di descrizione dei dati (ADO 2.1 e successivi). Nei nostri esempi ci serviremo del primo tipo, che si realizza con i passaggi di seguito illustrati.

Al fine di poter rendere persistente un Recordset ADO è necessario seguire poche ma attente regole di programmazione, che sono:

• Creazione di un Recordset con cursore lato client e locking appropriato , a partire da un'origine dati (Access, Sql Server, ASCII, Index Server, ecc.);
• Utilizzare il metodo " SAVE nome_file " per registrare il Recordset su di una risorsa fisica (HD, rete);
• Creare un Recordset senza connessione;
• Recuperare i dati dal file fisico con il metodo " OPEN nome_file ".

Per informazioni dettagliate su Cursori e meccanismi di Locking vi rimando all'indirizzo www.microsoft.com/data , e ad alcuni numeri di ' Uno script @l giorno '.

Ma quali sono i vantaggio di questo approccio? Il beneficio di punta di questa soluzione risiede nella possibilità di eseguire le operazioni di modifica in modalità OFF-LINE (senza alcuna connessione al database) per poi sincronizzarle con il database una volta ristabilita la connessione. Questa modalità è detta BATCHUPDATE , in quanto non c'è interazione con la fonte dati fino al ripristino della connessione, momento in cui sarà il database stesso ad eseguire tutte le modifiche presenti nel Recordset disconnesso, con un semplice metodo, ovvero RECORDSET.UPDATEBATCH . Quindi un solo comando per convertire tutto il nostro operato in modifiche concrete.

La nostra soluzione

La soluzione da noi adottata è basata proprio sulla caratteristiche di persistenza dei Recordset ADO; infatti, quello che faremo è sintetizzabile nei seguenti punti:

• creazione e salvataggio di un Disconnected Recordset (nel NUOVOCART.ASP );
• creazione di un carrello elettronico su base utente;
• inserimento di articoli nel carrello;
• conferma dell'ordine;
• esecuzione del BatchUpdate , con il quale procederemo a registrare sia l'ordine che i dettagli (articoli, prezzi e quantità) nelle rispettive tabelle.