Senti...non so`se posso esserti utile ma...anchio quando Recuperare un recordset ado da una stored procedure in Oracle....feci un casino...mi vedo meglio il tuo problema...e ti faccio sape`..cmq..ho un`amico che mi fece risolvere il problema con questo suo tutorial:
Recuperare un recordset ado da una stored procedure in Oracle
Ci avete mai provato? Hehe... bene.
Su SQL Server si potrebbe fare così:
/* Supposto che ci sia una tabella TUTENTI, con i campi utilizzati nella SELECT, vogliamo trovare l'utente con UFFICIO = al parametro indicato */DECLARE PROCEDURE GetUtenti (@UFF CHAR)AS SELECT UID, PWD, NOME, UFFICIO FROM TUTENTI WHERE UFFICIO LIKE @UFF + '%';GO
Non importa se la sintassi non è proprio quella precisa precisa... il concetto è quello.
Da VB che dovrei fare? Semplice! In linea generale (ci sono 2000 modi per farlo) questo:
Dim cn As New ADODB.ConnectionDim cmd As New ADODB.CommandDim rst As New ADODB.Recordsetcn.ConnectionString = "La mia stringa di connessione ad SQL Srv"cn.OpenSet cmd.ActiveConnection = cncmd.CommandType = adCmdStoredProccmd.CommandText = "GetUtenti"cmd.Parameters("@UFF") = "Vendite"Set rst = cmd.ExecuteSet cmd = Nothing'Pareo con il recordsetrst.Closecn.CloseSet rst = NothingSet cn = Nothing
E fino a qua bene o male lo sapevamo un po' tutti. Ma se vado a connettermi ad Oracle, le cose cambiano drasticamente. Pigliamo in faccia un macello di errori e per di più non esplicativi.
Come risolvere questa tremenda situazione? Il vostro aff.mo si è calato le peggio anfetamine ed è riuscito nell'impresa !
Prima di tutto: sapete cos'è un recordset? Io fino a ieri credevo che fosse in qualche modo una tabella SQL e qualche funzione di manipolazione... In realtà è un discreto bordellone!!! Si tratta di un insieme di vettori (le colonne della tabella), memorizzati in modo gerarchico (poi ne parleremo, per ora lasciamo stare se no incasiniamo) con una botta di cursori e classi che gestiscono la manipolazione dei dati. In pratica è un micro DBMS!
Tutto questo per spiegare che: SQL Srv, essendo di zio Bill, si integra al 100% con ado e simili, apparando tutte le conversioni necessarie alla restituzione dei dati delle query nelle stored procedure, nel formato che ci serve.
Oracle se ne sbatte altamente, rifilandoci diversi metri di 8=======D nei posti più indesiderati!
Infatti la procedura descritta più avanti non può essere definita su Oracle. Otterremmo un errore che ci dice più o meno che dopo la SELECT si aspetta un INTO. Questo perché non è possibile definire cursori come parametri di uscita da una procedura.
E qui ci viene in aiuto l'anfetamina. Presi da una forza paranormale, decidiamo di definire e implementare un package che faccia scorrere il cursore lungo tutti i records recuperati nella procedura e li inserisca in tanti vettori, quante sono i campi di ogni record recuperato.
I più furbetti avranno già intecchiato... Giaaaaà... Diamo i vettori come parametri di uscita e ado penserà a schiaffarli nel recordset. Mo sì che parliamo nella sua stessa lingua!
Eccovi un esempio fresco fresco... probabile cacata sintattica, ma l'idea è quella.
Prima di tutto occorre definire il package che ci farà da recordset di ritorno. Il concetto è quello di definire un record e un cursore, con i campi che corrispondano ai campi recuperati nella nostra procedura.
CREATE OR REPLACE PACKACGE GETUTENTIPKGAS TYPE RT IS RECORD ( uid TUTENTI.uid%TYPE pwd TUTENTI.pwd%TYPE nome TUTENTI.nome%TYPE ufficio TUTENTI.ufficio%TYPE); TYPE RC IS REF CURSOR RETURN RT;END;
Dove RT è il tipo RECORD che otterremo in uscita dalla procedura e RC è il cursore, che ci permette di scorrere lungo i vettori ottenuti. Abbiamo costruito un record di vettori, che può essere immaginato come una specie di matrice.
La dichiarazione %TYPE (comodissima ) indica che il tipo del campo appena dichiarato, corrisponde al tipo del campo da cui provengono i dati.
Successivamente occorre definire la nostra procedura:
CREATE OR REPLACE PROCEDURE GETUTENTI( UFF VARCHAR2 DEFAULT NULL, io_RC IN OUT GETUTENTIPKG.RC) AS BEGIN UFF := UFF + '%' OPEN io_RC FOR SELECT tutenti.uid, tutenti.pwd, tutenti.nome, tutenti.ufficio FROM tutenti WHERE tutenti.ufficio LIKE UFF; ENDEND GETUTENTI;
Come si può vedere, la dichiarazione è un po' più pallosa...
In pratica la procedura apre RC (il cursore del package) facendogli ciucciare i record che ci interessano tramite la select.
Tutto fatto. Il cursore, essendo un parametro di input output, ci fornirà il recordset che cerchiamo. E' importante notare che da codice VB (o VC o quello che vi passa per la boccia), il cursore non va menzionato tra i parametri, così come non si utilizza esplicitamente il @RETURN_VALUE delle procedure in SQL Server. A finale: nu'll'eta mecc'r int'a chiammata si no at' cacat'!
Passiamo al codice:
'Solita notazione, ometto le dichiarazioni'CN = Connection, RS = Recordset, CMD = Command (ADO)CN.Open "Stringa di connessione ad Oracle"Set CMD.ActiveConnection = CN CMD.CommandType = adCmdStoredProc'Al posto di SA si deve inserire il nome dello schema o del ownerCMD.CommandText = "SA.GETUTENTI"'Esiste un metodo per evitare la creazionedei parametri ed enumerarli correttamente'ma pare (a detta di MS) che sia più costoso della stessa query!CMD.Parameters.Append CMD.CreateParameter("Ufficio", , adParamInput)CMD.Parameters("Ufficio") = "Vendite"Set RS = CMD.Execute
Ed è tutto! Abbiamo il nostro recordset bello pulito pulito!!!
Morale: se sviluppiamo dei componenti COM+ o semplici librerie di classi che accedono ai dati, possiamo tranquillamente usare lo stesso codice e cambiare la connection string ed il gioco è fatto!!! Migriamo da SQL Server ad Oracle con la sola modifica della connessione!
Chierico - incantesimo di 5°liv.
ciao
C@V@y