Nello script Re-indirizzamento di pagina con invio di variabili Risultato di query casuale, abbiamo visto come sia piuttosto facile produrre uno script ASP per generare la visualizzazione di record da una tabella in modo casuale.
Lo script in questione offre un approccio di tipo client-side al problema,
ciò significa che l'elaborazione più significativa viene svolta sulla pagina
ASP.
Proviamo ora a vedere come invece sia possibile approcciare la questione dal
punto di vista server-side (database), sfruttando cioè la potenza del T-SQL
e di SQL Server 2000 con la funzione NEWID() ed utilizzando la pagina ASP solamente per richiamare la procedura e visualizzare i record ordinati casualmente.
Questo tipo di approccio offre due grossi vantaggi:
- Aumento delle performance dell'applicazione (riduzione del traffico di rete tra client e server, benifici dell'uso delle stored procedure come chaching e riutilizzo dei piani di esecuzione, ecc...)
- Aumenta l'eleganza e l'efficacia del codice scritto (il numero di righe di codice ASP si riduce drasticamente, niente loop o cicli if..else, minor numero di variabili dichiarate, cioè minore memoria utilizzata dall'applicazione)
- Riduzione della possibilità di generari errori nell'applicazione (il debug si fa a livello di SQL Server cioè sulla procedura memorizzata e non nella pagina ASP)
Lo script elaborato è stato testato su SQL Server 2000 e Win 2000, non funziona con NT4. (Su SQL Server 7.0 lo script non è stato provato)
La funzione NEWID()
NEWID()Â ritorna un valore unico del tipo uniqueidentifier (identificatore globale), diverso da computer a computer, grazie all'uso di una API specifica di Windows.
Provate ad aprire QA (Query Analyzer) e incollate il codice qui sotto:
-- Creiamo una variabile globale per contenere un dato uniqueidentifier
USE pubs
DECLARE @myid uniqueidentifier
SET @myid = NEWID()
PRINT 'Il valore di @myid è: '+ CONVERT(varchar(255), @myid)
Se fate girare lo script premendo F5 più volte potrete vedere come il valore
della variabile @myid cambi continuamente, questo perché ad ogni chiamata la funzione NEWID() genera un valore unico e globale.
Detto questo il gioco è fatto, per avere record ordinati
casualmente sarà sufficiente includere nella clausola ORDER BY della nostra
query NEWID()!
Provate il codice qui sotto:
USE pubs
SELECT TOP 10 [au_id], [au_lname], [au_fname] FROM [pubs].[dbo].[authors] ORDER
BY NEWID()
Facendo girare la query più volte avremo valori sempre differenti per gli
autori!
Costruiamo la pagina ASP
Il codice per la stored procedure è piuttosto semplice:
USE pubs
GO
CREATE PROCEDURE P_RandomAutori
AS
SELECT TOP 10 [au_id], [au_lname], [au_fname]
FROM [pubs].[dbo].[authors] ORDER BY NEWID()
Per richiamare la procedura dalla pagina asp:
<html>
<head>
<title>Ordinare i record casualmente</title>
</head>
<body bgcolor="#ffffff">
<%Â Â Â
Dim sADOConStr, oADOCon , oADORec, oADOCom
sADOConStr = "Provider=SQLOLEDB;Data Source=LUCALUCA2000;"
&_
"User ID=sa;Password=miapwd;Initial Catalog=pubs"
Set oADOCon = Server.CreateObject("ADODB.Connection")
Set oADORec = Server.CreateObject("ADODB.RecordSet")
Set oADOCom = Server.CreateObject("ADODB.Command")
oADOCon.CursorLocation = 3
oADOCon.open sADOConStr
oADOCom.activeconnection = oADOCon
oADOCom.commandtext = "P_RandomAutori"
oADOCom.commandtype = &H0004
Set oADORec = oADOCom.Execute
Do until (oADORec.eof)
%>
<!-- Visualizzo i risultati della query random -->
<%= "<li>" & oADORec(2) &
"Â " & oADORec(1) %> <br>
<!-- ***************************************** -->
<%
oADORec.MoveNext
Loop
If oADORec.STATE = adStateOpen Then oADORec.Close
If oADOCon.STATE = adStateOpen Then oADOCon.Close
Set oADORec = Nothing
Set oADOCon = Nothing
Set oADOCom = nothing
%>
<hr>
<a href="?">Refresh della pagina autori</a>
</body>
</html>
Il listato della pagina ASP ci mostra come in 19 righe di codice attivo possiamo implementare facilmente una soluzione che prima ne richiedeva ben 51!
Inoltre la compattezza del codice è notevolmente migliorata, non ci sono clicli if...else, loop vari e le stringhe SQL non vengono più generate sul client attraverso la pagina ASP come visto in precedenza, la possibilità di errori si riduce drasticamente e il debug dell'applicazione si sposta completamente a livello del T-SQL debugger di SQL Server (è molto più semplice ed efficace) e non della pagina ASP.
Nella pagina appena creata difatti dobbiamo solamente richiamare la stored
procedure attraverso l'oggetto COMMAND di ADO e creare un recordset eseguendo la procedura con il metodo .execute.
Tutto il resto del lavoro lo fa la procedura memorizzata che risiede sul SQL
Server.
