J'essaye d'utiliser Windev 8 et SQL Server 2000 via l'accès natif.
Tout se passe relativement bien hormis de multiples connexions à la
base (visibles par sp_who). Est-ce que quelqu'un a le même problème ?
Là où ça se gate c'est quand j'utilise des transactions afin de mettre
à jour plusieurs tables.
En effet Windev gère les transactions via une table
$$_TRS_OPERATION_$$ : comment fait-on lorsque 2 utilisateurs veulent
mettre à jour les données en même temps --> la table est verrouillée
(et non l'enregistrement lié à l'utilisateur A).
Mieux : je lis une table A, la modifie dans une transaction et dans la
même transaction je dois lire une autre partir de la table A (des
données liées) et les modifier --> je me verouille !!!
Via sp_lock sous SQL Server, on peut voir les verrous exclusifs sur la
table $$...
Bon, est-ce que quelqu'un a une solution, ou même une explication sur
ce mode de gestion idiot de Windev (généralement les transactions
c'est la base de données qui les gèrent avec BEGIN TRAN...COMMIT ou
ROLLBACK)
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire
Veuillez sélectionner un problème
Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
tulip
bonjour,
"plo" schreef in bericht news:
J'essaye d'utiliser Windev 8 et SQL Server 2000 via l'accès natif. Tout se passe relativement bien hormis de multiples connexions à la base (visibles par sp_who). Est-ce que quelqu'un a le même problème ?
oui, nous sommes revenus à OLE DB
Là où ça se gate c'est quand j'utilise des transactions afin de mettre à jour plusieurs tables. En effet Windev gère les transactions via une table $$_TRS_OPERATION_$$ : comment fait-on lorsque 2 utilisateurs veulent mettre à jour les données en même temps --> la table est verrouillée (et non l'enregistrement lié à l'utilisateur A). Mieux : je lis une table A, la modifie dans une transaction et dans la même transaction je dois lire une autre partir de la table A (des données liées) et les modifier --> je me verouille !!! Via sp_lock sous SQL Server, on peut voir les verrous exclusifs sur la table $$... Bon, est-ce que quelqu'un a une solution, ou même une explication sur ce mode de gestion idiot de Windev (généralement les transactions c'est la base de données qui les gèrent avec BEGIN TRAN...COMMIT ou ROLLBACK)
Nous avons une procédur globale qui gére les appels à SQL, nous gérons donc ceci au cas par cas via du code SQL.
-- Stéphan
bonjour,
"plo" <plochert@club-internet.fr> schreef in bericht
news:355fd753.0407120502.9753f5@posting.google.com...
J'essaye d'utiliser Windev 8 et SQL Server 2000 via l'accès natif.
Tout se passe relativement bien hormis de multiples connexions à la
base (visibles par sp_who). Est-ce que quelqu'un a le même problème ?
oui, nous sommes revenus à OLE DB
Là où ça se gate c'est quand j'utilise des transactions afin de mettre
à jour plusieurs tables.
En effet Windev gère les transactions via une table
$$_TRS_OPERATION_$$ : comment fait-on lorsque 2 utilisateurs veulent
mettre à jour les données en même temps --> la table est verrouillée
(et non l'enregistrement lié à l'utilisateur A).
Mieux : je lis une table A, la modifie dans une transaction et dans la
même transaction je dois lire une autre partir de la table A (des
données liées) et les modifier --> je me verouille !!!
Via sp_lock sous SQL Server, on peut voir les verrous exclusifs sur la
table $$...
Bon, est-ce que quelqu'un a une solution, ou même une explication sur
ce mode de gestion idiot de Windev (généralement les transactions
c'est la base de données qui les gèrent avec BEGIN TRAN...COMMIT ou
ROLLBACK)
Nous avons une procédur globale qui gére les appels à SQL, nous gérons donc
ceci au cas par cas via du code SQL.
J'essaye d'utiliser Windev 8 et SQL Server 2000 via l'accès natif. Tout se passe relativement bien hormis de multiples connexions à la base (visibles par sp_who). Est-ce que quelqu'un a le même problème ?
oui, nous sommes revenus à OLE DB
Là où ça se gate c'est quand j'utilise des transactions afin de mettre à jour plusieurs tables. En effet Windev gère les transactions via une table $$_TRS_OPERATION_$$ : comment fait-on lorsque 2 utilisateurs veulent mettre à jour les données en même temps --> la table est verrouillée (et non l'enregistrement lié à l'utilisateur A). Mieux : je lis une table A, la modifie dans une transaction et dans la même transaction je dois lire une autre partir de la table A (des données liées) et les modifier --> je me verouille !!! Via sp_lock sous SQL Server, on peut voir les verrous exclusifs sur la table $$... Bon, est-ce que quelqu'un a une solution, ou même une explication sur ce mode de gestion idiot de Windev (généralement les transactions c'est la base de données qui les gèrent avec BEGIN TRAN...COMMIT ou ROLLBACK)
Nous avons une procédur globale qui gére les appels à SQL, nous gérons donc ceci au cas par cas via du code SQL.
-- Stéphan
Manu
> J'essaye d'utiliser Windev 8 et SQL Server 2000 via l'accès natif. Tout se passe relativement bien hormis de multiples connexions à la base (visibles par sp_who). Est-ce que quelqu'un a le même problème ?
J'avais déjà lu çà quelque part.
Là où ça se gate c'est quand j'utilise des transactions afin de mettre à jour plusieurs tables. En effet Windev gère les transactions via une table $$_TRS_OPERATION_$$ : comment fait-on lorsque 2 utilisateurs veulent mettre à jour les données en même temps --> la table est verrouillée (et non l'enregistrement lié à l'utilisateur A).
Peux-tu détailler si tu le peux (pour ma culture personnelle) car s'est toujours interessant de savoir comment les autres font.
Mieux : je lis une table A, la modifie dans une transaction et dans la même transaction je dois lire une autre partir de la table A (des données liées) et les modifier --> je me verouille !!!
Cela veut-il dire que tu à 2 transactions MSQL pour la même WD ?
Via sp_lock sous SQL Server, on peut voir les verrous exclusifs sur la table $$...
Merci pour ces explications.
> J'essaye d'utiliser Windev 8 et SQL Server 2000 via l'accès natif.
Tout se passe relativement bien hormis de multiples connexions à la
base (visibles par sp_who). Est-ce que quelqu'un a le même problème ?
J'avais déjà lu çà quelque part.
Là où ça se gate c'est quand j'utilise des transactions afin de mettre
à jour plusieurs tables.
En effet Windev gère les transactions via une table
$$_TRS_OPERATION_$$ : comment fait-on lorsque 2 utilisateurs veulent
mettre à jour les données en même temps --> la table est verrouillée
(et non l'enregistrement lié à l'utilisateur A).
Peux-tu détailler si tu le peux (pour ma culture personnelle) car s'est
toujours interessant de savoir comment les autres font.
Mieux : je lis une table A, la modifie dans une transaction et dans la
même transaction je dois lire une autre partir de la table A (des
données liées) et les modifier --> je me verouille !!!
Cela veut-il dire que tu à 2 transactions MSQL pour la même WD ?
Via sp_lock sous SQL Server, on peut voir les verrous exclusifs sur la
table $$...
> J'essaye d'utiliser Windev 8 et SQL Server 2000 via l'accès natif. Tout se passe relativement bien hormis de multiples connexions à la base (visibles par sp_who). Est-ce que quelqu'un a le même problème ?
J'avais déjà lu çà quelque part.
Là où ça se gate c'est quand j'utilise des transactions afin de mettre à jour plusieurs tables. En effet Windev gère les transactions via une table $$_TRS_OPERATION_$$ : comment fait-on lorsque 2 utilisateurs veulent mettre à jour les données en même temps --> la table est verrouillée (et non l'enregistrement lié à l'utilisateur A).
Peux-tu détailler si tu le peux (pour ma culture personnelle) car s'est toujours interessant de savoir comment les autres font.
Mieux : je lis une table A, la modifie dans une transaction et dans la même transaction je dois lire une autre partir de la table A (des données liées) et les modifier --> je me verouille !!!
Cela veut-il dire que tu à 2 transactions MSQL pour la même WD ?
Via sp_lock sous SQL Server, on peut voir les verrous exclusifs sur la table $$...
Merci pour ces explications.
plochert
Je n'ai qu'une seule transaction mais le fait de relire la table sur laquelle je viens de faire un update provoque un blocage.
Après recherche (et pas mal de tests) je viens de trouver 1 solution : HDecritConnexion(...) HOuvreConnexion() et suppression du HChangeConnexion
Par contre les multiples connexions ne sont pas réglées (le support pcsoft me dit que c'est la 1ère fois !!!)
Je n'ai qu'une seule transaction mais le fait de relire la table sur
laquelle je viens de faire un update provoque un blocage.
Après recherche (et pas mal de tests) je viens de trouver 1 solution :
HDecritConnexion(...)
HOuvreConnexion()
et suppression du HChangeConnexion
Par contre les multiples connexions ne sont pas réglées (le support
pcsoft me dit que c'est la 1ère fois !!!)
