2010-11-11 11 views
5

Ho SQL Server 2008 con un server Sybase collegato e sto cercando di eseguire una procedura memorizzata sul server Sybase utilizzando OPENQUERY. Se ho un proc memorizzato che non accetta parametri, va bene. Se ho un proc memorizzato con parametri fallisce. Ho anche provato un proc memorizzato di base che ha preso solo un int che ancora non è riuscito. Di seguito è riportato la sintassi che sto usando:Esegui proc memorizzato con OPENQUERY

select * from 
OPENQUERY([LINKSERVER],'exec database.user.my_stored_proc ''AT'',''XXXX%'',''1111'',1') 

Msg 7357, livello 16, stato 2, riga 3 Impossibile elaborare l'oggetto "database.user.my_stored_proc exec 'A', 'XXXX%', '1111' , 1" . Il provider OLE DB "ASEOLEDB" per il server collegato "LINKSERVER" indica che l'oggetto non ha colonne o che l'utente corrente non dispone delle autorizzazioni per quell'oggetto.

Poiché il proc verrà eseguito correttamente senza parametri, non penso che sia un problema di autorizzazione.

+0

hai provato a eseguire il testo SQL direttamente sul Sybase? – Andomar

+0

Sì si esegue bene su Sybase –

risposta

1

Server collegati e OPENQUERY, gemme di MS SQL Server ... che sono lupi nell'abbigliamento delle pecore. Ho trovato le seguenti soluzioni per lavorare quando si tratta di parametri

  1. Se la SP è fondamentalmente dichiarazioni basta selezionare, la mossa lo stesso ad una vista e basta passare istruzioni SQL tramite OPENQUERY.

  2. Costruire OPENQUERY come stringa e quindi utilizzare execute_sql.

1

Si potrebbe anche vedere se funziona precedere exec con SET FMTONLY ON:

OPENQUERY ([LINKSERVER], 'SET FMTONLY ON; database.user.my_stored_proc exec '' A' '' 'XXXX%' ',' '1111' ', 1')

Se si prova questo e funziona, si dovrebbe probabilmente FMTONLY + OPENQUERY di Google per avere un'idea di cosa significa.

+1

No, questo non ha funzionato –

12

Questo ha funzionato per me,

SELECT * FROM OPENQUERY(LOCALSERVER, 'SET FMTONLY OFF EXEC snr.dbo.GetAllSignals @controlRunId = 25, @experimentRunId = 26') 

stavo creando tabelle temporanee, ed è per questo che ho ottenuto l'accesso negato

qui è più informazioni http://www.sommarskog.se/share_data.html#OPENQUERY

+0

+1 questo ha funzionato anche per me. Grazie! Non stavo usando tabelle temporanee, ma stavo facendo un EXEC (@VariableWithQuery) nel processo remoto in cui è stata impostata tale variabile da un'istruzione SELECT. Questo non ha funzionato fino a quando non ho aggiunto "SET FMTONLY OFF"; all'inizio Tuttavia, se imposto la variabile tramite un comando SET, ha funzionato senza bisogno di SET FMTONLY. Dispari. –

+0

Grazie!Questo ha funzionato anche per me !!! :) – Erick

+0

Giusto avviso che ci sono alcune conseguenze potenzialmente non intenzionali a questo metodo, come discusso in questa risposta: https://stackoverflow.com/a/14299989; ma, è il modo più semplice per "farlo funzionare" ed evitare di occuparsi di DTC, che è probabilmente peggio, quindi questo ('SET FMTONLY OFF') è una buona soluzione. – NateJ

2

creo un SP che non lo fa restituire qualsiasi valore e non funziona. Il tuo SP in mysql deve restituire un valore! per esempio faccio questo in "mysql":

CREATE DEFINER=`root`@`localhost` PROCEDURE `MyPro`(IN `Name` VARCHAR(50), IN `Id` INT, OUT `Result` INT) 
MODIFIES SQL DATA 
BEGIN 
DECLARE Result INT; 
    SET Result = 0; 
INSERT into MyTable (Id,Name) VALUES(Id,Name); 
SELECT Result; 

END 

Quel "ID" e "Nome" è parametro di input e "Risultato" è parametro di uscita e creare server collegato in SQL Server e chiamare in questo modo:

select * from openquery 
(
    Test,'call mydb.MyPro(''Name'',''16'', @P0);' 
) 

funziona per me: D

Problemi correlati