Comment puis-je corriger le décalage des nombre de début et de COMMETTRE des états?

J'obtiens cette erreur:

Nombre de transactions après EXECUTE indique des différences de nombre de
Lancer et valider les déclarations. Nombre précédent = 2, compte courant = 3.

Mais je ne sais pas assez sur SQL Server pour arrêter l'erreur.

Voici mon DROP PROCEDURE commande:

--Specify database in which to uninstall procedure
USE SalesLogix_Dev
GO

IF EXISTS (SELECT * FROM dbo.sysobjects WHERE id = object_id(N'usp_matt_db_tasks')
            AND OBJECTPROPERTY(id, N'IsProcedure') = 1)
DROP PROCEDURE usp_matt_db_tasks
GO

Et voici le CREATE PROCEDURE:

--Specify database in which to install procedure
USE SalesLogix_Dev
GO
--Drop existing objects in order to guanrantee error-free install
IF EXISTS (SELECT * FROM dbo.sysobjects WHERE id = object_id(N'usp_matt_db_tasks')
AND OBJECTPROPERTY(id, N'IsProcedure') = 1)
DROP PROCEDURE usp_matt_db_tasks
GO
CREATE PROCEDURE usp_matt_db_tasks
-- Add the parameters for the stored procedure here
AS
BEGIN
-- SET NOCOUNT ON added to prevent extra result sets from
-- interfering with SELECT statements.
SET NOCOUNT ON;
BEGIN TRANSACTION
INSERT INTO [SalesLogix_Dev].[sysdba].[LEAD] (
CREATEUSER,
CREATEDATE,
MODIFYUSER,
MODIFYDATE,
FIRSTNAME,
ACCOUNTMANAGERID,
ASSIGNDATE,
COMPANY,
COMPANY_UC,
EMAIL,
DONOTSOLICIT,
ISPRIMARY,
LEADSOURCEID,
SECCODEID,
STATUS,
LASTNAME,
LASTNAME_UC,
INDUSTRY,
NOTES,
HOMEPHONE) 
SELECT 
,'something'
,CURRENT_TIMESTAMP
,'something'    
,CURRENT_TIMESTAMP
,replace(firstname, '"', '')
,'something'
,CURRENT_TIMESTAMP
,replace(company, '"', '')
,replace(UPPER(company), '"', '')
,replace(email, '"', '')
,'1'
,'T'
,''
,'SYST00000001'
,'New'
,replace(lastname, '"', '')
,replace(UPPER(lastname), '"', '')
,replace(department, '"', '')
,replace(comments, '"', '')
,replace(phone, '"', '')
FROM [SalesLogix_Dev].[sysdba].[CSVTemp]
update  [SalesLogix_Dev].[sysdba].[LEAD] set LEAD_ADDRESSID = 'Q' + LEADID where DONOTSOLICIT = 1
INSERT INTO [SalesLogix_Dev].[sysdba].[LEAD_ADDRESS] (
LEAD_ADDRESSID,
LEADID,
CREATEUSER,
CREATEDATE,
MODIFYUSER,
MODIFYDATE,
ISMAILING,
ISPRIMARY) 
SELECT 
LEAD_ADDRESSID
,LEADID
,'something'
,CURRENT_TIMESTAMP
,'something'      
,CURRENT_TIMESTAMP
,'T'
,'T'
FROM [SalesLogix_Dev].[sysdba].[LEAD] where DONOTSOLICIT = 1
update  [SalesLogix_Dev].[sysdba].[LEAD] set DONOTSOLICIT = 0 where DONOTSOLICIT = 1
DROP TABLE [SalesLogix_Dev].[sysdba].[CSVTemp]
ROLLBACK  TRANSACTION
COMMIT TRANSACTION
END

Et enfin j'exécute comme suit:

USE SalesLogix_Dev
GO
EXEC usp_matt_db_tasks;
  • Pourquoi avez-vous un ROLLBACK suivi immédiatement par une COMMIT? Êtes-vous essayer de valider ou d'annuler? Je pense que cette procédure a plus d'exemples de BEGIN TRANSACTION (ou elle est appelée par une autre procédure qui a son propre contexte de transaction). Je préfère de beaucoup une question complète à une réduction de la question qui manque des informations vitales. Pouvez-vous nous montrer l'ensemble de la procédure s'il vous plaît?
  • j'ai ajouté la restauration parce que je pensais que ce serait résoudre le problème
  • est-il un moyen de supprimer toutes les occurrences de cette procédure
  • Vous avez plusieurs instances de la procédure? C'est probablement parce que vous n'êtes pas à l'aide de la dbo. préfixe. Au lieu de CREATE PROCEDURE usp_whatever toujours, toujours, toujours utiliser CREATE PROCEDURE dbo.usp_whatever... et de référence de cette façon, lorsque vous êtes en l'appelant, trop. De toute façon, nous montrent l'ENSEMBLE de la procédure... la réponse du cerveau posté montre pourquoi il n'est pas très utile de ne poster que des parties de la procédure.
  • Ok je vais voir la chose d'un sec
  • Mise à jour de ma question
  • Je soupçonne qu'il ya plus d'info, vous n'êtes pas à nous dire. Êtes-vous à l'appel de cette procédure stockée à partir d'une autre procédure, ou à partir d'une session où vous avez déjà lancé des opérations? Ce n' SELECT @@TRANCOUNT; rendement dans la fenêtre actuelle? Êtes-vous à 100% positif que vous appelez le droit d'instance de usp_matt_db_tasks? Ou est-il possible qu'il existe plusieurs copies sous différents schémas, et vous êtes à la recherche des mauvais?
  • laissez-nous continuer cette discussion dans le chat
  • Il a juste commencé à travailler, et pas sûr de ce qu'il se passe....merci encore @aaron
  • désolé, je suis juste apprendre SQL
  • Tout d'abord, vous devez utiliser try catch block lors de l'utilisation de transactions. Ce que vous avez besoin est d'avoir deux chemins, l'un pour l'engager si tout va bien et l'autre pour la restauration.
  • J'ai envisagé d'ajouter TRY/CATCH à ma réponse, mais j'ai jugé préférable de s'attaquer à un problème à la fois. 🙂
  • Bertrand, c'est pourquoi je l'ai fait un commentaire, si il ne sait pas à regarder comment le faire, mais à ne pas confondre avec ce problème.
  • droit, j'ai fait un commentaire similaire à la fin de ma réponse. Je n'ai pas de questionnement ou pas, vous devriez le mettre trop, juste faire une excuse pour expliquer pourquoi je n'ai pas d'ajouter la gestion d'erreur à la procédure dans ma réponse...