locked
Flock() avec SQLExec() RRS feed

  • Question

  • Salut a tous

    Comment peut-on faire un FLock() avec la commande SQLExec()

    J'ai besoin d'apporter des modifications sur une table et de la verrouillé afin d'être sur que personne ne la modifie en même temps.

     

    lResultat=SQLResult(MonHandle,"UPDATE MaTable SET MonChamp="+Alltrim(Str(MaValeur))+" Where "+MaCondition)


    Remarque :
    J'utilise la fonction suivante pour me connecté :
    .Handle=SQLStringConnect("driver={Microsoft Visual FoxPro
    Driver};sourcedb="+.SourceDB+"\;sourcetype=DBF;exclusive=No;backgroundfetch=No;collate=Machine;null=No;deleted=Yes")

     



    Merci d'avance 
     

    lundi 27 octobre 2008 09:18

Réponses

  • OK, donc on poursuit ici, sur ce forum.

     

    Je comprends parfaitement ta démarche (j'ai fait une présentation sur ce même sujet aux Rencontres AtoutFox...), mais:

    Si tu veux pouvoir utiliser les commandes de VFP en SPT (dans un SLQEXEC), tu dois utiliser une connexion par le provider VFPOLEDB et pas par l'ODBC.

    Est-ce que c'est le cas? si besoin, tu vas télécharger VFOLEDB sur le site Microsoft VFP (au passage charge aussi l'aide spécifique, tu trouveras la liste des commandes VFP exécutables depuis VFPOLEDB, et celles qui ne sont pas compatibles, et consulte aussi http://msdn.microsoft.com/en-us/library/0xzsac67.aspx, http://msdn.microsoft.com/en-us/library/3haz2895.aspx).

     

    La connectstring sera donc

    Provider=vfpoledb.1;Data Source=C:\MyDbFolder\MyDbContainer.dbc;Collating Sequence=machine;
     
    Si tu veux exécuter du code fox natif, tu le mets dans ta chaine à executer, par exemple select flock() from table1
     
    MAIS, à mon humble avis, ceci est une hérésie! que ce soit pour VFP, MSSQL ou tout autre SGBDR, on ne doit jamais poser de verrous depuis l'application, mais utiliser les verrouillages implicites posés par le moteur du SGBDR. Le verrou posé à la main comme tu le fais, c'est une technique ancestrale, datant d'avant les SGBDR, qu'on ne devrait plus jamais utiliser dans de nouveaux développements (en tous cas jamais dans la couche métier ou dans la couche de présentation)
     
    par exemple, en fox, c'est une combinaison correcte du buffermode, du wheretype, et du tableupdate qui va déterminer comment fox va poser les bon verrous automatiquement quand il en a besoin pour que notre update fonctionne comme nous le voulons.
     
    mardi 28 octobre 2008 21:04

Toutes les réponses

  • Bonjour,

     

    merci de poser les questions sur 1 seul forum...

    J'ai répondu sur le newsgroup: pourquoi utilises-tu SQLExec pour écrire dans ta table (plutot que USE), et surtout, pourquoi vouloir Flocker plutot que Rlocker.

     

    Avec une vue ou un use en mode shared et les bons buffermode, tu feras un update... qui s'appliquera sur tes données en cache, et ton écriture sera envoyée au dbf par un tableupdate qui posera les verrous quand ils seront nécessaires.

    lundi 27 octobre 2008 11:14
  • Salut Michel

     

    J'ai posté sur ce forum parce que je n’arrivé pas répondre à ton commentaire hier. Quand je clique sur le bouton « Répondre », Internet Explorer revient à la page d’accueil. Je ne sais pas pourquoi !

     

    Donc j’ai essayé de poser ma question sur un autre forum.

     

    Bref,

     

    Je suis en train de développer une application (E.R.P) multiplateforme. Mes clients auront le choix de travailler sur les tables natives de VFP (DBF) ou MySQL ou SQLServer.

     

    J’ai créé une classe pour chaque serveur de base de données (VFPSQL, MySQM, MSSQL). Cette classe est chargée en fonction du choix du client.

     

    Si je veux faire une modification dans une table, j’utilise cette instruction quelque soit la plateforme :

     

    Exemple 1 :

    lRep=oSQL.Cmd(“UPDATE “+MaTable+” SET MonChamp=”+MaValeur+” WHERE “+MaCondition)

    Exemple 2 :

    lRep=oSQL.Select(“SELECT * FROM “+MaTable+” WHERE “+MaCondition,”MonCurseur”)

    Et pleins d’autres fonctions...

    Donc au niveau de mon application je fais un seul développement et c’est mes classes qui se chargent de l’adaptation des instructions SQL en fonction de la plateforme choisi.

    Au niveau de MySQL, pour verrouiller et modifier une table, j’utilise les instructions suivantes :

    IF oSQL.Cmd("LOCK TABLES "+MaTable+" Write")

                    oSQL.Cmd(“UPDATE “+MaTable+” SET MonChamp=”+MaValeur+” WHERE “+MaCondition)

                    oSQL.Cmd(“"UNLOCK TABLES")

    ENDIF

    Je n’ai pas trouvé l’équivalent en VFP

    Merci d’avance pour votre aide

     

    mardi 28 octobre 2008 08:17
  • OK, donc on poursuit ici, sur ce forum.

     

    Je comprends parfaitement ta démarche (j'ai fait une présentation sur ce même sujet aux Rencontres AtoutFox...), mais:

    Si tu veux pouvoir utiliser les commandes de VFP en SPT (dans un SLQEXEC), tu dois utiliser une connexion par le provider VFPOLEDB et pas par l'ODBC.

    Est-ce que c'est le cas? si besoin, tu vas télécharger VFOLEDB sur le site Microsoft VFP (au passage charge aussi l'aide spécifique, tu trouveras la liste des commandes VFP exécutables depuis VFPOLEDB, et celles qui ne sont pas compatibles, et consulte aussi http://msdn.microsoft.com/en-us/library/0xzsac67.aspx, http://msdn.microsoft.com/en-us/library/3haz2895.aspx).

     

    La connectstring sera donc

    Provider=vfpoledb.1;Data Source=C:\MyDbFolder\MyDbContainer.dbc;Collating Sequence=machine;
     
    Si tu veux exécuter du code fox natif, tu le mets dans ta chaine à executer, par exemple select flock() from table1
     
    MAIS, à mon humble avis, ceci est une hérésie! que ce soit pour VFP, MSSQL ou tout autre SGBDR, on ne doit jamais poser de verrous depuis l'application, mais utiliser les verrouillages implicites posés par le moteur du SGBDR. Le verrou posé à la main comme tu le fais, c'est une technique ancestrale, datant d'avant les SGBDR, qu'on ne devrait plus jamais utiliser dans de nouveaux développements (en tous cas jamais dans la couche métier ou dans la couche de présentation)
     
    par exemple, en fox, c'est une combinaison correcte du buffermode, du wheretype, et du tableupdate qui va déterminer comment fox va poser les bon verrous automatiquement quand il en a besoin pour que notre update fonctionne comme nous le voulons.
     
    mardi 28 octobre 2008 21:04
  •  

    Je tien a te remercier pour le temps que tu m’as consacré pour m’aider.

    Je vais essayer de suivre tes conseils et voir comment mon application va réagir aux modifications.

    @+

    mercredi 29 octobre 2008 22:18