2017-07-31 1 views
1

J'ai un nouvel environnement de développement/test qui se trouve dans IIS 10 (avec asp classic as api) et SQL Server 2016. Aujourd'hui, j'ai remarqué que certains messages doublaient les enregistrements dans la base de données. Après un examen plus approfondi, les journaux IIS affichent seulement une requête, mais SQL Trace affiche deux tracés SQL: BatchCompleted simultanés pour chaque appel à la base de données utilisant la méthode non sécurisée cn.execute "stored_procedure 'param1'", mais tout appel de base de données avec une instruction préparée n'a qu'un seul RPC: Terminé hit dans la trace et fonctionne comme d'habitude.SQL s'exécutant deux fois en IIS10 avec ASP Classic

Notre environnement de production a la même version SQL, mais est toujours en IIS6, actuellement. J'ai perdu ma boîte de dev IIS avec la même configuration il y a quelques semaines et je n'avais pas remarqué ça auparavant. Environ 90% de notre API a été utilisé dans la production pendant plus d'une décennie sans que cela se produise, et ce n'est pas le cas actuellement. Je suis un peu nouveau à IIS 10 car j'ai maintenu l'environnement IIS6 tout ce temps, donc peut-être que j'ai mal configuré quelque chose, mais à part activer les chemins ASP classiques et parents, je n'ai pas beaucoup modifié pour obtenir notre API héritée en cours d'exécution.

Exemple d'ASP qui est à l'origine des exécutions doubles:

dim cn 
dim dbConnectionString 
dim SQL 
dim rs 

dbConnectionString = "Provider=SQLNCLI11;Server=srvr\instance;Database=DB;Uid=user;Pwd=pass;" 
Set cn = Server.CreateObject("ADODB.Connection") 
cn.open dbConnectionString 
cn.CommandTimeout = 0 
SQL = "store_procedure_name 'paramValue'" 
RS.Open SQL, cn, adOpenStatic, adLockReadOnly 
Response.Write(rs(0)) 
rs.Close 
set rs = nothing 
Response.end 

Et en utilisant un résultat de déclaration préparé ADODB dans l'exécution normale. Qu'est-ce qui me manque et qui me rend fou toute la journée? La majorité de l'API utilise la méthode de chaîne moins sécurisée (je suis conscient de l'injection SQL, etc.) car nous n'avons pas eu le temps de refactoriser les instructions préparées. Cependant, Tout le nouveau code est écrit avec des instructions préparées.

MISE À JOUR

Il semble quelque chose est différent dans SQL Native Client 11. Version Grabbed 10 de SQL Server 2008 R3 et il ne fait pas double appel plus. Provider=SQLNCLI10

Je pense que, à ce stade, je peux continuer avec la version SQLNCLI 10, mais j'aimerais savoir ce qui se passe avec SQLNCLI 11 ...

+0

si vous avez oublié l'objet create rs dans le code de problème snippit: 'set rs = server.CreateObject (" ADODB.Recordset ")' – cdre

+0

Grâce à @JoshMontgomery, nous l'avons réduit à 'RS.Open' en créant un deuxième appel. Utiliser 'set RS = cn.Execute (SQL)' ne provoque pas le même problème – cdre

Répondre

1

puisque vous n'êtes pas mettre à jour l'objet recordset directement, ne pas utiliser

RS.Open SQL, cn, adOpenStatic, adLockReadOnly 

mais plutôt

set RS = cn.Execute (sql)

J'ai eu déversoir d les problèmes dans le passé en utilisant RS.Open et ne les utilisez que si je veux modifier les données directement dans le jeu d'enregistrements, ce qui est une chose inhabituelle pour moi.

+0

Merci pour la suggestion. Cela n'a pas aidé, mais c'est une bonne idée. J'utilise 'set RS = Stmt.Execute()' dans notre nouveau code de développement. – cdre

+0

En fait, je prends cela en arrière ... J'avais créé un deuxième site et testé ce changement sur le mauvais - de sorte que l'arrêt d'une deuxième trace se produise ... progrès! La prochaine question serait pourquoi RS.Open' provoquant un deuxième appel à sql et 'cn.execute' n'est pas? Je ne peux pas changer 60k + lignes de code à cause d'un serveur de test. – cdre

+0

Je suppose que c'est un problème lié au curseur, essayez RS.Open SQL, cn, 3 ,, 1, si cela ne fonctionne pas, rapportez et je verrai (ou quelqu'un d'autre) peut trouver quelque chose d'autre à essayer –