Bonjour,
Je cherche a utiliser les transactions dans SQLServer avec DAO/ODBC.
Voici un extrait de code:
BeginTrans
Call db.Execute("UPDATE counter SET value = value + 1 WHERE name > 'mycounter'", dbSQLPassThrough)
Set Rec = db.OpenRecordSet("SELECT value FROM counter WHERE name > 'mycounter'", dbOpenSnapshot, dbSQLPassThrough)
value = Rec(0)
CommitTrans
Donc il s'agit dans ce code de récupérer une valeur unique à partir d'un
compteur, en faisant l'UPDATE en premier pour se protéger des transactions
concurrentes. Rien de plus facile, c'est ce qu'on apprend à l'école.
Eh bien ça marche sur Oracle, Sybase, SQLServer sous OSQL, mais pas sur
SQLServer sous DAO.
La ligne du SELECT blocque entierement le programme. Que se passe t'il? Je
pense que le driver ODBC SQLServer ouvre plusieurs connections à la base et
envoie l'UPDATE sur l'une et le SELECT sur... une autre, d'ou deadlock!!
http://support.microsoft.com/default.aspx?scid=kb;EN-US;170548 parle de ce
problème mais je n'utilise pas Jet, puisque tous mes appels ont le flag
dbSQLPassThrough.
C'est vraiment rageant. Si un code aussi simple ne marche pas, je ne vois
pas trop l'intérêt des transactions dans SQLServer... Le code marche sous
OSQL, mais sous DAO/ODBC le driver se croit plus intelligent que moi et
plante même les choses les plus élémentaires.
Qu'en pensez vous?
Comment faites vous pour contourner ce probleme? ou bien personne n'utilise
de transactions sur SQLServer DAO...?
Merci d'avance,
SerGioGio
Bonjour,
Je cherche a utiliser les transactions dans SQLServer avec DAO/ODBC.
Voici un extrait de code:
BeginTrans
Call db.Execute("UPDATE counter SET value = value + 1 WHERE name > 'mycounter'", dbSQLPassThrough)
Set Rec = db.OpenRecordSet("SELECT value FROM counter WHERE name > 'mycounter'", dbOpenSnapshot, dbSQLPassThrough)
value = Rec(0)
CommitTrans
Donc il s'agit dans ce code de récupérer une valeur unique à partir d'un
compteur, en faisant l'UPDATE en premier pour se protéger des transactions
concurrentes. Rien de plus facile, c'est ce qu'on apprend à l'école.
Eh bien ça marche sur Oracle, Sybase, SQLServer sous OSQL, mais pas sur
SQLServer sous DAO.
La ligne du SELECT blocque entierement le programme. Que se passe t'il? Je
pense que le driver ODBC SQLServer ouvre plusieurs connections à la base et
envoie l'UPDATE sur l'une et le SELECT sur... une autre, d'ou deadlock!!
http://support.microsoft.com/default.aspx?scid=kb;EN-US;170548 parle de ce
problème mais je n'utilise pas Jet, puisque tous mes appels ont le flag
dbSQLPassThrough.
C'est vraiment rageant. Si un code aussi simple ne marche pas, je ne vois
pas trop l'intérêt des transactions dans SQLServer... Le code marche sous
OSQL, mais sous DAO/ODBC le driver se croit plus intelligent que moi et
plante même les choses les plus élémentaires.
Qu'en pensez vous?
Comment faites vous pour contourner ce probleme? ou bien personne n'utilise
de transactions sur SQLServer DAO...?
Merci d'avance,
SerGioGio
Bonjour,
Je cherche a utiliser les transactions dans SQLServer avec DAO/ODBC.
Voici un extrait de code:
BeginTrans
Call db.Execute("UPDATE counter SET value = value + 1 WHERE name > 'mycounter'", dbSQLPassThrough)
Set Rec = db.OpenRecordSet("SELECT value FROM counter WHERE name > 'mycounter'", dbOpenSnapshot, dbSQLPassThrough)
value = Rec(0)
CommitTrans
Donc il s'agit dans ce code de récupérer une valeur unique à partir d'un
compteur, en faisant l'UPDATE en premier pour se protéger des transactions
concurrentes. Rien de plus facile, c'est ce qu'on apprend à l'école.
Eh bien ça marche sur Oracle, Sybase, SQLServer sous OSQL, mais pas sur
SQLServer sous DAO.
La ligne du SELECT blocque entierement le programme. Que se passe t'il? Je
pense que le driver ODBC SQLServer ouvre plusieurs connections à la base et
envoie l'UPDATE sur l'une et le SELECT sur... une autre, d'ou deadlock!!
http://support.microsoft.com/default.aspx?scid=kb;EN-US;170548 parle de ce
problème mais je n'utilise pas Jet, puisque tous mes appels ont le flag
dbSQLPassThrough.
C'est vraiment rageant. Si un code aussi simple ne marche pas, je ne vois
pas trop l'intérêt des transactions dans SQLServer... Le code marche sous
OSQL, mais sous DAO/ODBC le driver se croit plus intelligent que moi et
plante même les choses les plus élémentaires.
Qu'en pensez vous?
Comment faites vous pour contourner ce probleme? ou bien personne n'utilise
de transactions sur SQLServer DAO...?
Merci d'avance,
SerGioGio
gérer des transactions sur le poste client est aussi dangereux que, pour
chirurgien, d'opérer à distance !
Passer par des procédures stockée me semble la chose la plus naturelle et
plus simple.
De plus tu as utilisé un mot réservé en tant que nom de colonne (name). Il
donc le qualifier en l'entourant de guillemets. Mais mieux vaudrait
Exemple :
CREATE PROCEDURE SP_GET_NEW_KEY @COUNTER VARCHAR(32),
@NEWVALUE INTEGER OUTPUT
AS
SET TRANSACTION ISOLATION LEVEL SERIALIZABLE
BEGIN TRANSACTION
UPDATE counter
SET value = value + 1
WHERE "name" = @COUNTER
IF @@ERROR <> 0
GOTO LBL_ERROR
SELECT @NEWVALUE = value
FROM counter
WHERE "name" = @COUNTER
IF @@ERROR <> 0
GOTO LBL_ERROR
COMMIT TRANSACTION
RETURN
LBL_ERROR:
ROLLBACK
GO
A +
--
Frédéric BROUARD, MVP SQL Server. Expert SQL / spécialiste Delphi, web
Livre SQL - col. Référence : http://sqlpro.developpez.com/bookSQL.html
Le site du SQL, pour débutants et pros : http://sqlpro.developpez.com
************************ www.datasapiens.com *************************
> 'mycounter'
SerGioGio a écrit:
> Bonjour,
>
> Je cherche a utiliser les transactions dans SQLServer avec DAO/ODBC.
> Voici un extrait de code:
>
> BeginTrans
> Call db.Execute("UPDATE counter SET value = value + 1 WHERE name > > 'mycounter'", dbSQLPassThrough)
> Set Rec = db.OpenRecordSet("SELECT value FROM counter WHERE name > > 'mycounter'", dbOpenSnapshot, dbSQLPassThrough)
> value = Rec(0)
> CommitTrans
>
> Donc il s'agit dans ce code de récupérer une valeur unique à partir d'un
> compteur, en faisant l'UPDATE en premier pour se protéger des
> concurrentes. Rien de plus facile, c'est ce qu'on apprend à l'école.
> Eh bien ça marche sur Oracle, Sybase, SQLServer sous OSQL, mais pas sur
> SQLServer sous DAO.
>
> La ligne du SELECT blocque entierement le programme. Que se passe t'il?
> pense que le driver ODBC SQLServer ouvre plusieurs connections à la base
> envoie l'UPDATE sur l'une et le SELECT sur... une autre, d'ou deadlock!!
> http://support.microsoft.com/default.aspx?scid=kb;EN-US;170548 parle de
> problème mais je n'utilise pas Jet, puisque tous mes appels ont le flag
> dbSQLPassThrough.
>
> C'est vraiment rageant. Si un code aussi simple ne marche pas, je ne
> pas trop l'intérêt des transactions dans SQLServer... Le code marche
> OSQL, mais sous DAO/ODBC le driver se croit plus intelligent que moi et
> plante même les choses les plus élémentaires.
>
> Qu'en pensez vous?
> Comment faites vous pour contourner ce probleme? ou bien personne
> de transactions sur SQLServer DAO...?
>
> Merci d'avance,
>
> SerGioGio
>
>
gérer des transactions sur le poste client est aussi dangereux que, pour
chirurgien, d'opérer à distance !
Passer par des procédures stockée me semble la chose la plus naturelle et
plus simple.
De plus tu as utilisé un mot réservé en tant que nom de colonne (name). Il
donc le qualifier en l'entourant de guillemets. Mais mieux vaudrait
Exemple :
CREATE PROCEDURE SP_GET_NEW_KEY @COUNTER VARCHAR(32),
@NEWVALUE INTEGER OUTPUT
AS
SET TRANSACTION ISOLATION LEVEL SERIALIZABLE
BEGIN TRANSACTION
UPDATE counter
SET value = value + 1
WHERE "name" = @COUNTER
IF @@ERROR <> 0
GOTO LBL_ERROR
SELECT @NEWVALUE = value
FROM counter
WHERE "name" = @COUNTER
IF @@ERROR <> 0
GOTO LBL_ERROR
COMMIT TRANSACTION
RETURN
LBL_ERROR:
ROLLBACK
GO
A +
--
Frédéric BROUARD, MVP SQL Server. Expert SQL / spécialiste Delphi, web
Livre SQL - col. Référence : http://sqlpro.developpez.com/bookSQL.html
Le site du SQL, pour débutants et pros : http://sqlpro.developpez.com
************************ www.datasapiens.com *************************
> 'mycounter'
SerGioGio a écrit:
> Bonjour,
>
> Je cherche a utiliser les transactions dans SQLServer avec DAO/ODBC.
> Voici un extrait de code:
>
> BeginTrans
> Call db.Execute("UPDATE counter SET value = value + 1 WHERE name > > 'mycounter'", dbSQLPassThrough)
> Set Rec = db.OpenRecordSet("SELECT value FROM counter WHERE name > > 'mycounter'", dbOpenSnapshot, dbSQLPassThrough)
> value = Rec(0)
> CommitTrans
>
> Donc il s'agit dans ce code de récupérer une valeur unique à partir d'un
> compteur, en faisant l'UPDATE en premier pour se protéger des
> concurrentes. Rien de plus facile, c'est ce qu'on apprend à l'école.
> Eh bien ça marche sur Oracle, Sybase, SQLServer sous OSQL, mais pas sur
> SQLServer sous DAO.
>
> La ligne du SELECT blocque entierement le programme. Que se passe t'il?
> pense que le driver ODBC SQLServer ouvre plusieurs connections à la base
> envoie l'UPDATE sur l'une et le SELECT sur... une autre, d'ou deadlock!!
> http://support.microsoft.com/default.aspx?scid=kb;EN-US;170548 parle de
> problème mais je n'utilise pas Jet, puisque tous mes appels ont le flag
> dbSQLPassThrough.
>
> C'est vraiment rageant. Si un code aussi simple ne marche pas, je ne
> pas trop l'intérêt des transactions dans SQLServer... Le code marche
> OSQL, mais sous DAO/ODBC le driver se croit plus intelligent que moi et
> plante même les choses les plus élémentaires.
>
> Qu'en pensez vous?
> Comment faites vous pour contourner ce probleme? ou bien personne
> de transactions sur SQLServer DAO...?
>
> Merci d'avance,
>
> SerGioGio
>
>
gérer des transactions sur le poste client est aussi dangereux que, pour
chirurgien, d'opérer à distance !
Passer par des procédures stockée me semble la chose la plus naturelle et
plus simple.
De plus tu as utilisé un mot réservé en tant que nom de colonne (name). Il
donc le qualifier en l'entourant de guillemets. Mais mieux vaudrait
Exemple :
CREATE PROCEDURE SP_GET_NEW_KEY @COUNTER VARCHAR(32),
@NEWVALUE INTEGER OUTPUT
AS
SET TRANSACTION ISOLATION LEVEL SERIALIZABLE
BEGIN TRANSACTION
UPDATE counter
SET value = value + 1
WHERE "name" = @COUNTER
IF @@ERROR <> 0
GOTO LBL_ERROR
SELECT @NEWVALUE = value
FROM counter
WHERE "name" = @COUNTER
IF @@ERROR <> 0
GOTO LBL_ERROR
COMMIT TRANSACTION
RETURN
LBL_ERROR:
ROLLBACK
GO
A +
--
Frédéric BROUARD, MVP SQL Server. Expert SQL / spécialiste Delphi, web
Livre SQL - col. Référence : http://sqlpro.developpez.com/bookSQL.html
Le site du SQL, pour débutants et pros : http://sqlpro.developpez.com
************************ www.datasapiens.com *************************
> 'mycounter'
SerGioGio a écrit:
> Bonjour,
>
> Je cherche a utiliser les transactions dans SQLServer avec DAO/ODBC.
> Voici un extrait de code:
>
> BeginTrans
> Call db.Execute("UPDATE counter SET value = value + 1 WHERE name > > 'mycounter'", dbSQLPassThrough)
> Set Rec = db.OpenRecordSet("SELECT value FROM counter WHERE name > > 'mycounter'", dbOpenSnapshot, dbSQLPassThrough)
> value = Rec(0)
> CommitTrans
>
> Donc il s'agit dans ce code de récupérer une valeur unique à partir d'un
> compteur, en faisant l'UPDATE en premier pour se protéger des
> concurrentes. Rien de plus facile, c'est ce qu'on apprend à l'école.
> Eh bien ça marche sur Oracle, Sybase, SQLServer sous OSQL, mais pas sur
> SQLServer sous DAO.
>
> La ligne du SELECT blocque entierement le programme. Que se passe t'il?
> pense que le driver ODBC SQLServer ouvre plusieurs connections à la base
> envoie l'UPDATE sur l'une et le SELECT sur... une autre, d'ou deadlock!!
> http://support.microsoft.com/default.aspx?scid=kb;EN-US;170548 parle de
> problème mais je n'utilise pas Jet, puisque tous mes appels ont le flag
> dbSQLPassThrough.
>
> C'est vraiment rageant. Si un code aussi simple ne marche pas, je ne
> pas trop l'intérêt des transactions dans SQLServer... Le code marche
> OSQL, mais sous DAO/ODBC le driver se croit plus intelligent que moi et
> plante même les choses les plus élémentaires.
>
> Qu'en pensez vous?
> Comment faites vous pour contourner ce probleme? ou bien personne
> de transactions sur SQLServer DAO...?
>
> Merci d'avance,
>
> SerGioGio
>
>
Bonjour,
Je cherche a utiliser les transactions dans SQLServer avec DAO/ODBC.
Voici un extrait de code:
BeginTrans
Call db.Execute("UPDATE counter SET value = value + 1 WHERE name > 'mycounter'", dbSQLPassThrough)
Set Rec = db.OpenRecordSet("SELECT value FROM counter WHERE name > 'mycounter'", dbOpenSnapshot, dbSQLPassThrough)
value = Rec(0)
CommitTrans
Donc il s'agit dans ce code de récupérer une valeur unique à partir d'un
compteur, en faisant l'UPDATE en premier pour se protéger des transactions
concurrentes. Rien de plus facile, c'est ce qu'on apprend à l'école.
Eh bien ça marche sur Oracle, Sybase, SQLServer sous OSQL, mais pas sur
SQLServer sous DAO.
La ligne du SELECT blocque entierement le programme. Que se passe t'il? Je
pense que le driver ODBC SQLServer ouvre plusieurs connections à la base
envoie l'UPDATE sur l'une et le SELECT sur... une autre, d'ou deadlock!!
http://support.microsoft.com/default.aspx?scid=kb;EN-US;170548 parle de ce
problème mais je n'utilise pas Jet, puisque tous mes appels ont le flag
dbSQLPassThrough.
C'est vraiment rageant. Si un code aussi simple ne marche pas, je ne vois
pas trop l'intérêt des transactions dans SQLServer... Le code marche sous
OSQL, mais sous DAO/ODBC le driver se croit plus intelligent que moi et
plante même les choses les plus élémentaires.
Qu'en pensez vous?
Comment faites vous pour contourner ce probleme? ou bien personne
de transactions sur SQLServer DAO...?
Merci d'avance,
SerGioGio
Bonjour,
Je cherche a utiliser les transactions dans SQLServer avec DAO/ODBC.
Voici un extrait de code:
BeginTrans
Call db.Execute("UPDATE counter SET value = value + 1 WHERE name > 'mycounter'", dbSQLPassThrough)
Set Rec = db.OpenRecordSet("SELECT value FROM counter WHERE name > 'mycounter'", dbOpenSnapshot, dbSQLPassThrough)
value = Rec(0)
CommitTrans
Donc il s'agit dans ce code de récupérer une valeur unique à partir d'un
compteur, en faisant l'UPDATE en premier pour se protéger des transactions
concurrentes. Rien de plus facile, c'est ce qu'on apprend à l'école.
Eh bien ça marche sur Oracle, Sybase, SQLServer sous OSQL, mais pas sur
SQLServer sous DAO.
La ligne du SELECT blocque entierement le programme. Que se passe t'il? Je
pense que le driver ODBC SQLServer ouvre plusieurs connections à la base
envoie l'UPDATE sur l'une et le SELECT sur... une autre, d'ou deadlock!!
http://support.microsoft.com/default.aspx?scid=kb;EN-US;170548 parle de ce
problème mais je n'utilise pas Jet, puisque tous mes appels ont le flag
dbSQLPassThrough.
C'est vraiment rageant. Si un code aussi simple ne marche pas, je ne vois
pas trop l'intérêt des transactions dans SQLServer... Le code marche sous
OSQL, mais sous DAO/ODBC le driver se croit plus intelligent que moi et
plante même les choses les plus élémentaires.
Qu'en pensez vous?
Comment faites vous pour contourner ce probleme? ou bien personne
de transactions sur SQLServer DAO...?
Merci d'avance,
SerGioGio
Bonjour,
Je cherche a utiliser les transactions dans SQLServer avec DAO/ODBC.
Voici un extrait de code:
BeginTrans
Call db.Execute("UPDATE counter SET value = value + 1 WHERE name > 'mycounter'", dbSQLPassThrough)
Set Rec = db.OpenRecordSet("SELECT value FROM counter WHERE name > 'mycounter'", dbOpenSnapshot, dbSQLPassThrough)
value = Rec(0)
CommitTrans
Donc il s'agit dans ce code de récupérer une valeur unique à partir d'un
compteur, en faisant l'UPDATE en premier pour se protéger des transactions
concurrentes. Rien de plus facile, c'est ce qu'on apprend à l'école.
Eh bien ça marche sur Oracle, Sybase, SQLServer sous OSQL, mais pas sur
SQLServer sous DAO.
La ligne du SELECT blocque entierement le programme. Que se passe t'il? Je
pense que le driver ODBC SQLServer ouvre plusieurs connections à la base
envoie l'UPDATE sur l'une et le SELECT sur... une autre, d'ou deadlock!!
http://support.microsoft.com/default.aspx?scid=kb;EN-US;170548 parle de ce
problème mais je n'utilise pas Jet, puisque tous mes appels ont le flag
dbSQLPassThrough.
C'est vraiment rageant. Si un code aussi simple ne marche pas, je ne vois
pas trop l'intérêt des transactions dans SQLServer... Le code marche sous
OSQL, mais sous DAO/ODBC le driver se croit plus intelligent que moi et
plante même les choses les plus élémentaires.
Qu'en pensez vous?
Comment faites vous pour contourner ce probleme? ou bien personne
de transactions sur SQLServer DAO...?
Merci d'avance,
SerGioGio
Bonjour,
Je cherche a utiliser les transactions dans SQLServer avec DAO/ODBC.
Voici un extrait de code:
BeginTrans
Call db.Execute("UPDATE counter SET value = value + 1 WHERE name > 'mycounter'", dbSQLPassThrough)
Set Rec = db.OpenRecordSet("SELECT value FROM counter WHERE name > 'mycounter'", dbOpenSnapshot, dbSQLPassThrough)
value = Rec(0)
CommitTrans
Donc il s'agit dans ce code de récupérer une valeur unique à partir d'un
compteur, en faisant l'UPDATE en premier pour se protéger des transactions
concurrentes. Rien de plus facile, c'est ce qu'on apprend à l'école.
Eh bien ça marche sur Oracle, Sybase, SQLServer sous OSQL, mais pas sur
SQLServer sous DAO.
La ligne du SELECT blocque entierement le programme. Que se passe t'il? Je
pense que le driver ODBC SQLServer ouvre plusieurs connections à la base
envoie l'UPDATE sur l'une et le SELECT sur... une autre, d'ou deadlock!!
http://support.microsoft.com/default.aspx?scid=kb;EN-US;170548 parle de ce
problème mais je n'utilise pas Jet, puisque tous mes appels ont le flag
dbSQLPassThrough.
C'est vraiment rageant. Si un code aussi simple ne marche pas, je ne vois
pas trop l'intérêt des transactions dans SQLServer... Le code marche sous
OSQL, mais sous DAO/ODBC le driver se croit plus intelligent que moi et
plante même les choses les plus élémentaires.
Qu'en pensez vous?
Comment faites vous pour contourner ce probleme? ou bien personne
de transactions sur SQLServer DAO...?
Merci d'avance,
SerGioGio
Bonjour,
Je cherche a utiliser les transactions dans SQLServer avec DAO/ODBC.
Voici un extrait de code:
BeginTrans
Call db.Execute("UPDATE counter SET value = value + 1 WHERE name > 'mycounter'", dbSQLPassThrough)
Set Rec = db.OpenRecordSet("SELECT value FROM counter WHERE name > 'mycounter'", dbOpenSnapshot, dbSQLPassThrough)
value = Rec(0)
CommitTrans
Donc il s'agit dans ce code de récupérer une valeur unique à partir d'un
compteur, en faisant l'UPDATE en premier pour se protéger des transactions
concurrentes. Rien de plus facile, c'est ce qu'on apprend à l'école.
Eh bien ça marche sur Oracle, Sybase, SQLServer sous OSQL, mais pas sur
SQLServer sous DAO.
La ligne du SELECT blocque entierement le programme. Que se passe t'il? Je
pense que le driver ODBC SQLServer ouvre plusieurs connections à la base
envoie l'UPDATE sur l'une et le SELECT sur... une autre, d'ou deadlock!!
http://support.microsoft.com/default.aspx?scid=kb;EN-US;170548 parle de ce
problème mais je n'utilise pas Jet, puisque tous mes appels ont le flag
dbSQLPassThrough.
C'est vraiment rageant. Si un code aussi simple ne marche pas, je ne vois
pas trop l'intérêt des transactions dans SQLServer... Le code marche sous
OSQL, mais sous DAO/ODBC le driver se croit plus intelligent que moi et
plante même les choses les plus élémentaires.
Qu'en pensez vous?
Comment faites vous pour contourner ce probleme? ou bien personne
de transactions sur SQLServer DAO...?
Merci d'avance,
SerGioGio
Bonjour,
Je cherche a utiliser les transactions dans SQLServer avec DAO/ODBC.
Voici un extrait de code:
BeginTrans
Call db.Execute("UPDATE counter SET value = value + 1 WHERE name > 'mycounter'", dbSQLPassThrough)
Set Rec = db.OpenRecordSet("SELECT value FROM counter WHERE name > 'mycounter'", dbOpenSnapshot, dbSQLPassThrough)
value = Rec(0)
CommitTrans
Donc il s'agit dans ce code de récupérer une valeur unique à partir d'un
compteur, en faisant l'UPDATE en premier pour se protéger des transactions
concurrentes. Rien de plus facile, c'est ce qu'on apprend à l'école.
Eh bien ça marche sur Oracle, Sybase, SQLServer sous OSQL, mais pas sur
SQLServer sous DAO.
La ligne du SELECT blocque entierement le programme. Que se passe t'il? Je
pense que le driver ODBC SQLServer ouvre plusieurs connections à la base
envoie l'UPDATE sur l'une et le SELECT sur... une autre, d'ou deadlock!!
http://support.microsoft.com/default.aspx?scid=kb;EN-US;170548 parle de ce
problème mais je n'utilise pas Jet, puisque tous mes appels ont le flag
dbSQLPassThrough.
C'est vraiment rageant. Si un code aussi simple ne marche pas, je ne vois
pas trop l'intérêt des transactions dans SQLServer... Le code marche sous
OSQL, mais sous DAO/ODBC le driver se croit plus intelligent que moi et
plante même les choses les plus élémentaires.
Qu'en pensez vous?
Comment faites vous pour contourner ce probleme? ou bien personne
de transactions sur SQLServer DAO...?
Merci d'avance,
SerGioGio
gérer des transactions sur le poste client est aussi dangereux que, pour
chirurgien, d'opérer à distance !
Passer par des procédures stockée me semble la chose la plus naturelle et
plus simple.
De plus tu as utilisé un mot réservé en tant que nom de colonne (name). Il
donc le qualifier en l'entourant de guillemets. Mais mieux vaudrait
Exemple :
CREATE PROCEDURE SP_GET_NEW_KEY @COUNTER VARCHAR(32),
@NEWVALUE INTEGER OUTPUT
AS
SET TRANSACTION ISOLATION LEVEL SERIALIZABLE
BEGIN TRANSACTION
UPDATE counter
SET value = value + 1
WHERE "name" = @COUNTER
IF @@ERROR <> 0
GOTO LBL_ERROR
SELECT @NEWVALUE = value
FROM counter
WHERE "name" = @COUNTER
IF @@ERROR <> 0
GOTO LBL_ERROR
COMMIT TRANSACTION
RETURN
LBL_ERROR:
ROLLBACK
GO
A +
--
Frédéric BROUARD, MVP SQL Server. Expert SQL / spécialiste Delphi, web
Livre SQL - col. Référence : http://sqlpro.developpez.com/bookSQL.html
Le site du SQL, pour débutants et pros : http://sqlpro.developpez.com
************************ www.datasapiens.com *************************
> 'mycounter'
SerGioGio a écrit:
> Bonjour,
>
> Je cherche a utiliser les transactions dans SQLServer avec DAO/ODBC.
> Voici un extrait de code:
>
> BeginTrans
> Call db.Execute("UPDATE counter SET value = value + 1 WHERE name > > 'mycounter'", dbSQLPassThrough)
> Set Rec = db.OpenRecordSet("SELECT value FROM counter WHERE name > > 'mycounter'", dbOpenSnapshot, dbSQLPassThrough)
> value = Rec(0)
> CommitTrans
>
> Donc il s'agit dans ce code de récupérer une valeur unique à partir d'un
> compteur, en faisant l'UPDATE en premier pour se protéger des
> concurrentes. Rien de plus facile, c'est ce qu'on apprend à l'école.
> Eh bien ça marche sur Oracle, Sybase, SQLServer sous OSQL, mais pas sur
> SQLServer sous DAO.
>
> La ligne du SELECT blocque entierement le programme. Que se passe t'il?
> pense que le driver ODBC SQLServer ouvre plusieurs connections à la base
> envoie l'UPDATE sur l'une et le SELECT sur... une autre, d'ou deadlock!!
> http://support.microsoft.com/default.aspx?scid=kb;EN-US;170548 parle de
> problème mais je n'utilise pas Jet, puisque tous mes appels ont le flag
> dbSQLPassThrough.
>
> C'est vraiment rageant. Si un code aussi simple ne marche pas, je ne
> pas trop l'intérêt des transactions dans SQLServer... Le code marche
> OSQL, mais sous DAO/ODBC le driver se croit plus intelligent que moi et
> plante même les choses les plus élémentaires.
>
> Qu'en pensez vous?
> Comment faites vous pour contourner ce probleme? ou bien personne
> de transactions sur SQLServer DAO...?
>
> Merci d'avance,
>
> SerGioGio
>
>
gérer des transactions sur le poste client est aussi dangereux que, pour
chirurgien, d'opérer à distance !
Passer par des procédures stockée me semble la chose la plus naturelle et
plus simple.
De plus tu as utilisé un mot réservé en tant que nom de colonne (name). Il
donc le qualifier en l'entourant de guillemets. Mais mieux vaudrait
Exemple :
CREATE PROCEDURE SP_GET_NEW_KEY @COUNTER VARCHAR(32),
@NEWVALUE INTEGER OUTPUT
AS
SET TRANSACTION ISOLATION LEVEL SERIALIZABLE
BEGIN TRANSACTION
UPDATE counter
SET value = value + 1
WHERE "name" = @COUNTER
IF @@ERROR <> 0
GOTO LBL_ERROR
SELECT @NEWVALUE = value
FROM counter
WHERE "name" = @COUNTER
IF @@ERROR <> 0
GOTO LBL_ERROR
COMMIT TRANSACTION
RETURN
LBL_ERROR:
ROLLBACK
GO
A +
--
Frédéric BROUARD, MVP SQL Server. Expert SQL / spécialiste Delphi, web
Livre SQL - col. Référence : http://sqlpro.developpez.com/bookSQL.html
Le site du SQL, pour débutants et pros : http://sqlpro.developpez.com
************************ www.datasapiens.com *************************
> 'mycounter'
SerGioGio a écrit:
> Bonjour,
>
> Je cherche a utiliser les transactions dans SQLServer avec DAO/ODBC.
> Voici un extrait de code:
>
> BeginTrans
> Call db.Execute("UPDATE counter SET value = value + 1 WHERE name > > 'mycounter'", dbSQLPassThrough)
> Set Rec = db.OpenRecordSet("SELECT value FROM counter WHERE name > > 'mycounter'", dbOpenSnapshot, dbSQLPassThrough)
> value = Rec(0)
> CommitTrans
>
> Donc il s'agit dans ce code de récupérer une valeur unique à partir d'un
> compteur, en faisant l'UPDATE en premier pour se protéger des
> concurrentes. Rien de plus facile, c'est ce qu'on apprend à l'école.
> Eh bien ça marche sur Oracle, Sybase, SQLServer sous OSQL, mais pas sur
> SQLServer sous DAO.
>
> La ligne du SELECT blocque entierement le programme. Que se passe t'il?
> pense que le driver ODBC SQLServer ouvre plusieurs connections à la base
> envoie l'UPDATE sur l'une et le SELECT sur... une autre, d'ou deadlock!!
> http://support.microsoft.com/default.aspx?scid=kb;EN-US;170548 parle de
> problème mais je n'utilise pas Jet, puisque tous mes appels ont le flag
> dbSQLPassThrough.
>
> C'est vraiment rageant. Si un code aussi simple ne marche pas, je ne
> pas trop l'intérêt des transactions dans SQLServer... Le code marche
> OSQL, mais sous DAO/ODBC le driver se croit plus intelligent que moi et
> plante même les choses les plus élémentaires.
>
> Qu'en pensez vous?
> Comment faites vous pour contourner ce probleme? ou bien personne
> de transactions sur SQLServer DAO...?
>
> Merci d'avance,
>
> SerGioGio
>
>
gérer des transactions sur le poste client est aussi dangereux que, pour
chirurgien, d'opérer à distance !
Passer par des procédures stockée me semble la chose la plus naturelle et
plus simple.
De plus tu as utilisé un mot réservé en tant que nom de colonne (name). Il
donc le qualifier en l'entourant de guillemets. Mais mieux vaudrait
Exemple :
CREATE PROCEDURE SP_GET_NEW_KEY @COUNTER VARCHAR(32),
@NEWVALUE INTEGER OUTPUT
AS
SET TRANSACTION ISOLATION LEVEL SERIALIZABLE
BEGIN TRANSACTION
UPDATE counter
SET value = value + 1
WHERE "name" = @COUNTER
IF @@ERROR <> 0
GOTO LBL_ERROR
SELECT @NEWVALUE = value
FROM counter
WHERE "name" = @COUNTER
IF @@ERROR <> 0
GOTO LBL_ERROR
COMMIT TRANSACTION
RETURN
LBL_ERROR:
ROLLBACK
GO
A +
--
Frédéric BROUARD, MVP SQL Server. Expert SQL / spécialiste Delphi, web
Livre SQL - col. Référence : http://sqlpro.developpez.com/bookSQL.html
Le site du SQL, pour débutants et pros : http://sqlpro.developpez.com
************************ www.datasapiens.com *************************
> 'mycounter'
SerGioGio a écrit:
> Bonjour,
>
> Je cherche a utiliser les transactions dans SQLServer avec DAO/ODBC.
> Voici un extrait de code:
>
> BeginTrans
> Call db.Execute("UPDATE counter SET value = value + 1 WHERE name > > 'mycounter'", dbSQLPassThrough)
> Set Rec = db.OpenRecordSet("SELECT value FROM counter WHERE name > > 'mycounter'", dbOpenSnapshot, dbSQLPassThrough)
> value = Rec(0)
> CommitTrans
>
> Donc il s'agit dans ce code de récupérer une valeur unique à partir d'un
> compteur, en faisant l'UPDATE en premier pour se protéger des
> concurrentes. Rien de plus facile, c'est ce qu'on apprend à l'école.
> Eh bien ça marche sur Oracle, Sybase, SQLServer sous OSQL, mais pas sur
> SQLServer sous DAO.
>
> La ligne du SELECT blocque entierement le programme. Que se passe t'il?
> pense que le driver ODBC SQLServer ouvre plusieurs connections à la base
> envoie l'UPDATE sur l'une et le SELECT sur... une autre, d'ou deadlock!!
> http://support.microsoft.com/default.aspx?scid=kb;EN-US;170548 parle de
> problème mais je n'utilise pas Jet, puisque tous mes appels ont le flag
> dbSQLPassThrough.
>
> C'est vraiment rageant. Si un code aussi simple ne marche pas, je ne
> pas trop l'intérêt des transactions dans SQLServer... Le code marche
> OSQL, mais sous DAO/ODBC le driver se croit plus intelligent que moi et
> plante même les choses les plus élémentaires.
>
> Qu'en pensez vous?
> Comment faites vous pour contourner ce probleme? ou bien personne
> de transactions sur SQLServer DAO...?
>
> Merci d'avance,
>
> SerGioGio
>
>
