[VB6+SQLServer] Intercettare parametro di Output di una StoredProcedure

[ladyBlu]

io ho la necessità di eseguire una storedprocedure ogni volta che devo inserire un nuovo acquisitore nella tabella tbacquisitori. questa storedprocedure deve ritornare il valore del nuovo id, tramite la parolina magica Return.
il problema è che devo chiamare la stored da vb, e sempre in vb intercettare il parametro di ritorno.

ragazzi, non ci riesco...

la stored è questa qui:

CREATE PROCEDURE sp_AggiungiAcquisitore
	(@mioAcquisitore	[varchar](100),
	@mioIDEnte 		[int] = 0,
	@mioID 		[int] output)

AS 

DECLARE @mioIDAcquisitore INT

INSERT INTO
		tbAcquisitori ([Acquisitore], [IDEnte]) 
	 
	VALUES (@mioAcquisitore,@mioIDEnte)
	
	SELECT  max(@@identity) FROM TBAcquisitori

	return @@identity
GO

il codice che uso in vb è questo:

Dim miaSQL As String, mioIDOut As Long
miaSQL = "Exec sp_AggiungiAcquisitore '" _
          & mvarAcquisitore & "',"_
          & mvarIDEnte & "," & mioIDOut
miaConn.Execute (miaSQL)

'qui dovrei leggere il nuovo idacquisitore nella variabile 
'mioIDOut ma non avviene

ragazzi, conto su di voi...

[biste]

Dim mioCmd As New ADODB.Command
Dim mioPar As ADODB.Parameter

'Oggetto Command per lanciare la stored procedure
mioCmd.CommandType = adCmdStoredProc
mioCmd.CommandText = "sp_AggiungiAcquisitore"
mioCmd.ActiveConnection = miaConn

'Il parametro di ritorno per primo
Set mioPar = New ADODB.Parameter
mioPar.Direction = adParamReturnValue
mioPar.Name = "RETURN_VALUE"
mioPar.Type = adInteger
mioCmd.Parameters.Append par

'Poi tutti gli altri, ecco un esempio del primo
Set mioPar = New ADODB.Parameter
mioPar.Direction = adParamInput
mioPar.Name = "@mioAcquisitore"
mioPar.Type = adVarChar
mioPar.Size = 100
mioPar.Value = mvarAcquisitore
mioCmd.Parameters.Append par


'Dopo aver costruito i parametri lancio la stored
mioCmd.Execute

'e quindi recupero il valore di ritorno
mioIDOut = mioCmd.Parameters(0).Value

Questo è quanto


HTH

[vonkranz]

...non sono molto sicuro ma se tu fai una cos del tipo:

dim rst as adodb.recordset

set rst = miaConn.Execute (miaSQL)

non ti ritrovi in rst 2 campi tipo

rst!mvarAcquisitore
rst!mvarIDEnte

...e' solo un'ipotesi pero'...

[biste]

ah se vuoi un consiglio... non usare sp_ come prefisso per le tue stored, xkè è un prefisso usato già dal SQL Server... qui c'è la spiegazione in inglese:

If you are creating a stored procedure to run in a database other than the Master database, don't use the prefix "sp_" in its name. This special prefix is reserved for system stored procedures. Although using this prefix will not prevent a user defined stored procedure from working, what it can do is to slow down its execution ever so slightly.

The reason for this is that by default, any stored procedure executed by SQL Server that begins with the prefix "sp_", is first attempted to be resolved in the Master database. Since it is not there, time is wasted looking for the stored procedure.

If SQL Server cannot find the stored procedure in the Master database, then it next tries to resolve the stored procedure name as if the owner of the object is "dbo". Assuming the stored procedure is in the current database, it will then execute. To avoid this unnecessary delay, don't name any of your stored procedures with the prefix "sp_".

HTH

[ladyBlu]

Originariamente inviato da biste
ah se vuoi un consiglio... non usare sp_ come prefisso per le tue stored, xkè è un prefisso usato già dal SQL Server... qui c'è la spiegazione in inglese:




HTH

grazie per il consiglio biste... però scusa, io non lavoro su master, le stored sono nel mio database quindi non dovrei avere problemi...:master:

[biste]

Originariamente inviato da ladyBlu
grazie per il consiglio biste... però scusa, io non lavoro su master, le stored sono nel mio database quindi non dovrei avere problemi...:master:

Se tu crei una stored procedure con prefisso sp_ il signor sql server va prima a vedere in tutte le stored procedure del master se quella stored esiste, dopodichè quando non l'ha trovata va a cercare nel db in cui sta lavorando. Quindi la tua stored procedure funziona lo stesso, ma in termini di prestazioni è svantaggioso... mi sono spiegazzato?

HTH

[biste]

Ma il codice ti funziona?

[ladyBlu]

Originariamente inviato da biste
Se tu crei una stored procedure con prefisso sp_ il signor sql server va prima a vedere in tutte le stored procedure del master se quella stored esiste, dopodichè quando non l'ha trovata va a cercare nel db in cui sta lavorando. Quindi la tua stored procedure funziona lo stesso, ma in termini di prestazioni è svantaggioso... mi sono spiegazzato?

HTH

...ma è terribile questa cosa!!!...
non la sapevo, ora lo farò presente al mio capoprogetto e vediamo cosa ne pensa...

il codice lo sto sistemando, ma non credo cha al capo piacerà molto.
se funziona per me va benissimo...:gren:

in ogni caso non esiste nessun altro modo per gestire questo tipo di problematica legata al return?...:master:

[ZioAlfredo]

in ogni caso non esiste nessun altro modo per gestire questo tipo di problematica legata al return ?

... a meno non che non usi il dataenvironment ...
cmq il metodo consigliato da biste è OK !

[biste]

Originariamente inviato da ladyBlu
...ma è terribile questa cosa!!!...
non la sapevo, ora lo farò presente al mio capoprogetto e vediamo cosa ne pensa...

il codice lo sto sistemando, ma non credo cha al capo piacerà molto.
se funziona per me va benissimo...:gren:

in ogni caso non esiste nessun altro modo per gestire questo tipo di problematica legata al return?...:master:

Beh non è che ci mette 2 giorni in + eh! E' solo un tip, così magari d'ora in poi che lo sapete cercate di evitare questo naming... Cmq puoi tirartela un po' col tuo capoprogetto

X quanto riguarda il codice... L'oggetto Command va istanziato sicuramente: per lanciare le stored proc va usato quello!

Se vuoi ti posso accorciare il codice in modo da non usare anche gli oggetti parameter... Però così il codice è + pulito e comprensibile...

HTH