IdentifiantMot de passe
Loading...
Mot de passe oublié ?Je m'inscris ! (gratuit)
Navigation

Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter

Langage SQL Discussion :

[sql] [as400] [transaction]


Sujet :

Langage SQL

Vue hybride

Message précédent Message précédent   Message suivant Message suivant
  1. #1
    Membre averti
    Profil pro
    Inscrit en
    Mars 2005
    Messages
    41
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Mars 2005
    Messages : 41
    Par défaut [sql] [as400] [transaction]
    Bonjour,
    Pour régler un problème d'accès concurrent, je me suis interessé au merveilleux monde des transactions.
    Hélas je ne trouve rien sur l'as400, et j'ai l'impression que la syntaxe est différend d'un SGBD à l'autre.

    Je me connecte en PHP via les divers odbc à l'as400 afin de réaliser des requêtes sur des fichiers.
    J'ai un problème d'accès concurrent sur un compteur à incrémenter qui n'est apparu qu'avec la montée en charge de l'appli.

    Je suis bien embêté car je ne trouve rien sur le transactionnel avec un as400.
    Est ce possible?

    Merci d'avance!

  2. #2
    Xo
    Xo est déconnecté
    Membre Expert
    Avatar de Xo
    Inscrit en
    Janvier 2005
    Messages
    2 701
    Détails du profil
    Informations personnelles :
    Âge : 52

    Informations forums :
    Inscription : Janvier 2005
    Messages : 2 701
    Par défaut Re: [sql] [as400] [transaction]
    Citation Envoyé par eizo
    Pour régler un problème d'accès concurrent, je me suis interessé au merveilleux monde des transactions.
    Hélas je ne trouve rien sur l'as400, et j'ai l'impression que la syntaxe est différend d'un SGBD à l'autre.
    Oui, car les transactions sont implémentés dans les langages procéduraux, propres à chaque SGBD, mais ce n'est en aucun cas du SQL.

    Quel est le SGBD avec lequel tu travailles ? DB2 ?
    "Ce que l'on conçoit bien s'énonce clairement,
    Et les mots pour le dire arrivent aisément." Nicolas Boileau

    "Expliquer empêche de comprendre si cela dispense de chercher"

    Quiz Oracle : venez tester vos connaissances !

    La FAQ Oracle : 138 réponses à vos questions
    Aidez-nous à la compléter

  3. #3
    Rédacteur

    Avatar de SQLpro
    Homme Profil pro
    Expert bases de données / SQL / MS SQL Server / Postgresql
    Inscrit en
    Mai 2002
    Messages
    22 002
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Var (Provence Alpes Côte d'Azur)

    Informations professionnelles :
    Activité : Expert bases de données / SQL / MS SQL Server / Postgresql
    Secteur : Conseil

    Informations forums :
    Inscription : Mai 2002
    Messages : 22 002
    Billets dans le blog
    6
    Par défaut
    XO ce que vous dites est complétement faux !!!!

    La syntaxe de la norme SQL2 (1992) proposait que la connexion demarre et une transaction et que celle ci se termine par un ordre COMMIT [WORK] ou ROLLBACK [WORK].

    La version SQL:1999 à rajouter les principes d'autocommit et donc la possibiliter de gérer des transactions explicite avec BEGIN WORK ou START TRANSACTION.

    Ces ordre fonc partie du TCL (Transaction Control Language) sous ensemble de SQL qui s'intéresse à la gestion des transactions. Il comprend aussi l'ordre SET TRANSACTION ISOLATION LEVEL ...


    A +
    Frédéric Brouard - SQLpro - ARCHITECTE DE DONNÉES - expert SGBDR et langage SQL
    Le site sur les SGBD relationnels et le langage SQL: http://sqlpro.developpez.com/
    Blog SQL, SQL Server, SGBDR : http://blog.developpez.com/sqlpro
    Expert Microsoft SQL Server - M.V.P. (Most valuable Professional) MS Corp.
    Entreprise SQL SPOT : modélisation, conseils, audit, optimisation, formation...
    * * * * * Expertise SQL Server : http://mssqlserver.fr/ * * * * *

  4. #4
    Xo
    Xo est déconnecté
    Membre Expert
    Avatar de Xo
    Inscrit en
    Janvier 2005
    Messages
    2 701
    Détails du profil
    Informations personnelles :
    Âge : 52

    Informations forums :
    Inscription : Janvier 2005
    Messages : 2 701
    Par défaut
    Citation Envoyé par SQLpro
    XO ce que vous dites est complétement faux !!!!
    Tout à fait

    Mea Culpa, je ne ferai plus de réponses le lundi matin ...
    "Ce que l'on conçoit bien s'énonce clairement,
    Et les mots pour le dire arrivent aisément." Nicolas Boileau

    "Expliquer empêche de comprendre si cela dispense de chercher"

    Quiz Oracle : venez tester vos connaissances !

    La FAQ Oracle : 138 réponses à vos questions
    Aidez-nous à la compléter

  5. #5
    Membre Expert Avatar de Yanika_bzh
    Homme Profil pro
    Responsable Applicatif et R&D
    Inscrit en
    Février 2006
    Messages
    1 144
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : Royaume-Uni

    Informations professionnelles :
    Activité : Responsable Applicatif et R&D
    Secteur : Finance

    Informations forums :
    Inscription : Février 2006
    Messages : 1 144
    Par défaut
    Le monde de l'acces concurrent est passionant

    La solution de SQLPro est la plus sure, cependant elle fait chuter de maniere significative les performances du SGBDR, en effet, en mode serializable, les requetes sont effectuées comme si elles etaient lancées les unes apres les autres (d'ou le nom !! )

    Mais la securité des données a t elle un cout ??
    Je ne le pense pas, et je crois que SQLPro doit penser comme moi

    Tu peux aussi verrouiller au niveau de l'enregistrement (par un select for Update), mais ceci ne fonctionnera pas avec des agrégats, et peut donner lieu a des interblocages

    Ex :

    Select * from mytable where champ1=1 for update [A]
    Select * from mytable where champ1=2 for update [B]
    Select * from mytable where champ1=2 for update [A]
    Select * from mytable where champ1=1 for update [B]

    Ni [A], ni [B] ne peuvent continuer car ils sont en situation d'interblocage.

    Le select * from MyTable for update peut etre une solution, mais la encore, ne pas perdre de vue le cout de verrouillage d'une table entiere.
    Si la requete transactionnelle qui suit n'est pas trop longue alors ca peut etre une solution.

    Peut etre que SQLPro me corrigera sur ce que j'ai ecrit
    J'espere t'avoir un peu eclairer

    Bon Courage

  6. #6
    Rédacteur

    Avatar de SQLpro
    Homme Profil pro
    Expert bases de données / SQL / MS SQL Server / Postgresql
    Inscrit en
    Mai 2002
    Messages
    22 002
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Var (Provence Alpes Côte d'Azur)

    Informations professionnelles :
    Activité : Expert bases de données / SQL / MS SQL Server / Postgresql
    Secteur : Conseil

    Informations forums :
    Inscription : Mai 2002
    Messages : 22 002
    Billets dans le blog
    6
    Par défaut
    Le forçage d'un verouillage peut souvent s'avérer pire que le mal.

    Pour utiliser un compteur le plus sûr est d'utiliser une table de compteur. En effet le SELECT MAX(...) + 1 va devenir de plus en plus lourd et amener de plus en plus de contention au fur et à mesure de l'augmentation de la volumétrie des données, par ce qu'il vous un verrou exclusif sur toute la table.

    Lisez l'article que j'ai écrit à ce sujet :
    http://sqlpro.developpez.com/cours/clefs/

    A +
    Frédéric Brouard - SQLpro - ARCHITECTE DE DONNÉES - expert SGBDR et langage SQL
    Le site sur les SGBD relationnels et le langage SQL: http://sqlpro.developpez.com/
    Blog SQL, SQL Server, SGBDR : http://blog.developpez.com/sqlpro
    Expert Microsoft SQL Server - M.V.P. (Most valuable Professional) MS Corp.
    Entreprise SQL SPOT : modélisation, conseils, audit, optimisation, formation...
    * * * * * Expertise SQL Server : http://mssqlserver.fr/ * * * * *

Discussions similaires

  1. ADO + SQL Server + Transactions + Multi-User
    Par surfer2k dans le forum Bases de données
    Réponses: 1
    Dernier message: 03/03/2010, 09h43
  2. Convertion vba en SQL AS400
    Par Marc_27 dans le forum DB2
    Réponses: 1
    Dernier message: 19/11/2009, 17h52
  3. Problème requête SQL AS400.
    Par Papytruc dans le forum AS/400
    Réponses: 13
    Dernier message: 19/01/2009, 15h15
  4. Réponses: 6
    Dernier message: 19/05/2008, 17h55
  5. Réponses: 0
    Dernier message: 11/02/2008, 11h37

Partager

Partager
  • Envoyer la discussion sur Viadeo
  • Envoyer la discussion sur Twitter
  • Envoyer la discussion sur Google
  • Envoyer la discussion sur Facebook
  • Envoyer la discussion sur Digg
  • Envoyer la discussion sur Delicious
  • Envoyer la discussion sur MySpace
  • Envoyer la discussion sur Yahoo