Problema durante la chiamata della procedura memorizzata da un'altra procedura memorizzata tramite ASP classico

StackOverflow https://stackoverflow.com/questions/107585

Domanda

Abbiamo un'applicazione ASP classica che funziona semplicemente e siamo stati dispiaciuti di modificare il codice per non invocare l'ira di alcuni dei greci morti da lungo tempo.

Di recente abbiamo avuto il requisito di aggiungere una funzione a un'applicazione. L'implementazione della funzione è in realtà solo un'operazione di database che richiede una modifica minima all'interfaccia utente.

Ho cambiato l'interfaccia utente e ho apportato la modifica minore per inviare un nuovo valore di dati alla chiamata sproc (sproc1).

In sproc1 che viene chiamato direttamente da ASP, abbiamo aggiunto una nuova chiamata a un altro sproc che si trova su un altro server, sproc2.

In qualche modo, questo non funziona tramite la nostra app ASP, ma funziona in SQL Management Studio.

Ecco i dettagli tecnici:

  1. SQL 2005 su entrambi i server di database.
  2. L'accesso Sql si autentica dall'applicazione ASP a SQL 2005 Server 1.
  3. Il server collegato dal server 1 al server 2 funziona.
  4. Quando si esegue sproc1 da SQL Management Studio - funziona bene. Anche quando credenziali come lo stesso utente utilizza il nostro codice (l'applicazione sql login).
  5. sproc2 funziona quando viene chiamato indipendentemente da sproc1 da SQL Management Studio.
  6. VBScript (ASP) rileva un errore che viene restituito nell'XML al client. Il numero di errore è 0, la descrizione dell'errore è vuota. Sia dall'oggetto ADODB.Connection che da qualunque Err.Number / Err.Description restituisce in VBScript dal lato ASP.

Quindi, senza errori né riproducibilità (ad esempio tramite SQL Mgmt Studio), qualcuno conosce il problema?

Il nostro piano attuale è quello di scomporre e scavare nel codice sul lato ASP ed effettuare una chiamata completamente separata al Server 2.sproc2 direttamente da ASP piuttosto che tentare di eseguire il piggy-back tramite sproc1.

È stato utile?

Soluzione

La mia prima reazione è che questo potrebbe non essere un problema di chiamata tra server, ma uno di chiamare un secondo proc da un primo, e che questo potrebbe essere ciò che agisce in modo diverso nei due diversi ambienti.

La mia prima domanda è questa: cosa succede se si rimuove l'aspetto tra server dall'equazione? Se potessi impostare un sistema di test in cui il tuo primo proc chiama il tuo secondo proc, ma il secondo proc si trova sullo stesso server e / o nello stesso database, hai ancora lo stesso problema?

Sulla stessa linea: nella mia esperienza, quando l'applicazione e SSMS hanno ottenuto risultati diversi in questo modo, spesso è stato un problema delle impostazioni delle procedure memorizzate. Potrebbe essere, come dice Luke, NOCOUNT. Questo genere di cose è accaduto da istruzioni PRINT estranee nel codice, anche se mi sembra di ricordare che il valore PRINT sia diventato parte della descrizione dell'errore (in modo molto controintuitivo).

Se qualcosa viene restituito nella finestra Messaggi quando lo esegui in SSMS, scopri da dove proviene e fermalo. Dovrei cercare i termini tecnici, ma il mio ricordo è che ambienti di query diversi hanno sensibilità diverse a "errori" e che una connessione predefinita tramite SSSM non genererà un errore in determinati momenti quando una connessione ADO da un linguaggio di scripting farà.

Un ultimo pensiero: nel caso in cui si tratti di un ambiente, provare diverse impostazioni sulla stringa di connessione della pagina ASP. Ad esempio, se si dispone di una connessione OLEDB, provare ODBC. Prova i driver nativi e non nativi di SQL Server. Scopri quali opzioni di stringa di connessione sono supportate dal tuo provider e prova tutte quelle che sembrano valere la pena provare.

Altri suggerimenti

Hai impostato nocount su impostato in entrambe le procedure memorizzate? Ho avuto un problema simile una volta e anche se non ricordo esattamente come l'ho risolto al momento, so che aveva qualcosa a che fare con esso!

Potresti soffrire di problema del doppio hop

Il problema del doppio hop è quando la pagina ASP / X tenta di utilizzare risorse che si trovano su un server diverso dal server IIS.

Challenge / Response di Windows NT non supporta imitazioni a doppio hop (in quel caso passate al server IIS, le stesse credenziali non possono essere passate a un server back-end per l'autenticazione).

È necessario verificare la seconda connessione tentata utilizzando SQL Profiler.

Nota che con i test manuali non esegui l'autenticazione tramite IIS. È solo quando si avvia sql tramite la pagina ASP / X che si manifesta questo problema.

Altre risorse:

Ho avuto un problema simile e l'ho risolto impostando nocount e rimuovendo i comandi di stampa.

Il codice di esempio potrebbe aiutare :) Stai cercando di restituire due tabelle dalla procedura memorizzata; Non credo che ADO 2.6 possa gestire la restituzione di più tabelle.

L'ho considerato (double-hop), ma qual è la differenza tra una chiamata sproc-in-a-sproc come mi riferisco a un normale join tra server tramite INNER JOIN? Entrambi verrebbero eseguiti su Server1, utilizzando le credenziali del server collegato e autenticandosi sul server 2.

Qualcuno può confermare che chiamare un cross-server sproc è diverso dal fare un join su tabelle di dati? E perché?

Se la configurazione del server collegato è un account sql, viene considerato un doppio hop (poiché ciò a cui si fa riferimento è il doppio hop di NTLM?)

In termini di ritorno di più set di risultati - no. Sia Server1.Sproc1 che Server2.Sproc2 sarebbero " ExecuteNonQuery () " nel mondo .net e non restituisce nulla (nessun set di risultati e nessun valore di ritorno).

Prova a controllare le autorizzazioni al database per l'utente specificato nella stringa di connessione. Utilizzare lo stesso nome utente nella stringa di connessione per accedere al database mentre si utilizza sql mgmt studio.

crea una tabella temporanea per scrivere i valori intermedi e le eccezioni poiché può essere un modo efficace per il debug della tua applicazione.

Posso solo controllare: hai aggiunto Sproc2? Prima di allora funzionava bene per anni.

Non potresti cambiare da dove chiami sproc2? Invece di chiamarlo dall'interno di sproc1, puoi chiamarlo dall'ASP? In questo modo controlli l'autenticazione su SQL nel codice e non devi fare affidamento sulla configurazione di trust o sull'autenticazione remota condivisa sui server.

Come è configurato il tuo server collegato? In genere hai alcune opzioni su come si autentica sul server remoto, tra cui l'accesso come utente attualmente connesso o la specifica di un accesso SQL da utilizzare sempre. Hai provato a impostarlo per utilizzare sempre un account specifico? Ciò dovrebbe eliminare eventuali problemi di autorizzazione nel chiamare la procedura remota ...

Autorizzato sotto: CC-BY-SA insieme a attribuzione
Non affiliato a StackOverflow
scroll top