Bonjour,
 
J'ai un souci avec une procédure stockée sous SQLSERVER 2005   .
 
Le contexte : j'ai 2 tables contenant respectivement des entêtes et lignes de commandes.

CREATE TABLE [dbo].[GCPEBL](
 [IDENT] [int] IDENTITY(1,1) NOT NULL,
 [NUMERO_DOC] [char](10) NULL,
 ...
 [DATE_BL] [datetime] NULL,
 ...
CREATE TABLE [dbo].[GCPLBL](
 [IDENT] [int] IDENTITY(1,1) NOT NULL,
 [NUMERO] [char](17) NULL,
 ...
 [DATE_BL] [datetime] NULL,
 ...

 
Le lien entre la première et la seconde table se fait par [NUMERO_DOC] et [NUMERO] :  
pour la commande 51, [GCPEBL].[NUMERO_DOC] = '51', et [GCPEBL].[NUMERO] = '51|'+numéro de ligne de commande => '51|1', '51|2', '51|3'...  
 
Ci-dessous ma procédure stockée pour mettre à jour les [DATE_BL] des 2 tables pour un enregistrement donné :
 

SET ANSI_NULLS ON
GO
SET QUOTED_IDENTIFIER OFF
GO
 
ALTER                     Procedure [dbo].[SPw_UpdateBLValide]
@sEnTeteCommande char(10),
@dt datetime
 
AS
 
IF @sEnTeteCommande <> '0'
BEGIN
 UPDATE dbo.GCPEBL
 SET DATE_BL = @dt
 WHERE NUMERO_DOC = RTRIM(@sEnTeteCommande)
 
 UPDATE dbo.GCPLBL
 SET DATE_BL = @dt
 WHERE NUMERO LIKE RTRIM(@sEnTeteCommande) + '|%'
END

 
La procédure est on ne peut plus basique.
 
Dans un premier temps, j'ai pensé que le problème venait de SQLSERVER, mais aujourd'hui, je n'en suis plus si sûr : quand j’exécute la procédure directement dans SQLSERVER, elle fonctionne.  
 
Quand je passe par le site web, écrit en ASP (ASP, pas ASP.NET) sous IIS, cette procédure ne met pas à jour la première table alors que la seconde table est mise à jour ...  
 
J'ai testé mes critères de sélection : je les utilise dans de nombreuses autres procédures et ça fonctionne très bien, mais pas pour cette procédure... Je ne sais pas ce qu'elle a de différent des autres procédures, n'empêche qu'elle ne fonctionne pas et que je me casse la tête dessus depuis beaucoup trop longtemps   !
 
Le fait que la moitié de la procédure fonctionne me rend dingue : j'ai besoin de comprendre pourquoi!!
La moindre idée ou soupçon d'idée est la bienvenue   . Et merci déjà de m'avoir lu.

Au hasard, premier point à vérifier, les droits de l'utilisateur web sur la première table ?

Ca pourrait aussi etre le parametre.
Le deuxieme Update a un LIKE, qui est moin restrictif que =.

Merci de vos réponse.
 
Les droits sur les tables sont les mêmes.
Et le problème ne vient pas des paramètres : cette procédure exécutée depuis le requêteur de SQLSERVER fonctionne.
 
Je ne comprends rien à ce qui se passe, et je ne sais même pas à qui demander de l'aide (Microsoft?)...

Quand je dis probleme de parametre, je veux dire que le parametre venant de l'ASP est peut etre different que celui entre manuellement dans le Management Studio.
 
Essaye de faire un SELECT a la place d'un Update et fais un print des parametre dans les deux cas pour voir ce qui se passe.

Les paramètres affichés sont bien les mêmes que je passe par le manager.
 
J'ai essayé aussi avec un like pour etre dans le même cas de figure que le second update :
WHERE '*'+RTRIM(NUMERO_DOC)+'*' LIKE '%*'+RTRIM(@sEnTeteCommande)+'*%'
 
mais rien de nouveau.
 
Enfin, j'ai essayé avec une valeur dans ce champ, l'update fonctionne puisqu'il me met systématiquement le champ à NULL.
 
Est-il possible qu'un champ de type datetime d'une table ne soit au meme format que les autres champ du même type? Par exemple au format de date anglaise? Et ou puis-je trouver le format de mes dates pour ce champ?

Apres maintes tentatives pour comprendre ce qui se passe, j'ai trouvé un nouvel indice : en passant par l'ASP,  un autre champ que je n'avais pas remarqué, est modifié, donc le problème ne semble pas venir de la requete...
En effet, j'ai une autre requete qui tourne apres ma requete, et qui vient écraser le champ DATE_BL...
 
Au moins une semaine de travail, juste pour ça...    
 
En tout cas, merci pour votre aide, qui m'a permis d'avancer.
Un GRAND GRAND MERCI à vous, et surtout à Oliiii qui m'a permis de voir les choses différemment.