Bonjour,

Je suis tout à fait conscient que les sgbdr ne sont pas la même chose
que des fichiers indexés mais l'utilisation qu'en font les utilisateurs
est quand même la même.

Si l'utilisateur préfère avoir un message indiquant qu'une autre
personne est actuellement en train de modifier des informations dans la
base plutôt que de faire ses modifications et les voir perdre lorsqu'il
valide, cela me parait quelque part cohérent. Pas la peine de perdre du
temps.

Mon but est d'indiquer d'une manière ou d'une autre, avant que
l'utilisateur commence ses modifications, que quelqu'un d'autre est
déjà en train d'en faire. Que ce soit sur un Sgbdr ou des fichiers
indexés, je ne vois pas pourquoi cela ne serait pas possible ?

Les fichiers indexés peuvent très bien aussi être organisés comme vous
l'indiquez avec des relations. C'est d'ailleurs comme cela que l'on
fait généralement. On retrouve l'organisation que vous avez défini plus
bas pour un "client".


Jean

Fred BROUARD a formulé la demande :
> Juanito a écrit :
>> Bonjour,
>>
>> Je comprends très bien que le Sgbdr gère les blocages durant les update.
>> Cependant ce que je voudrais c'est réserver une ligne d'une table pour que
>> les autres utilisateurs ne puissent pas l'utiliser. Même pendant plusieurs
>> minutes.
>>
>> A ouvre un client
>> B ouvre le même client
>
> la notion de client n'existe pas dans un SGBDR. On parle de table de
> lignes...
>
> Qu'est ce qu'un client ? Une ligne dans une table ???
>
> Pour moi un client est un objet composé de plusieurs tables :
> table des personnes (générique) avec nom, prenom
> Table des "clients" (spécifique : héritage) avec remise et enseigne par
> exemple
> table des téléphones
> table des adressees
> table des mails
> ..
>
> Vous voudriez bloquer tout cela pour pendant 10 minutes juste pour une modif
> ?
>
> Nous ne vivons pas dans le même monde. Vous en êtes resté aux fichiers plat
> dans lequel figure tout un tas d'informations inutile.
>
> Votre volonté de vouloir reproduire le monde des fichiers plat est inutiles,
> stérile et dangereuse et fait mon bonheur en matière de conseil et d'audit.
>
> C'est là que je trouve le max de pognon à gagner parce que les applications
> deviennent catastrophiquement lente et son inexploitable dès qu'il y a un peu
> de volume.
> Donc il faut tout casser et produire un modèle relationnel. Soit quelques
> dizaines de jours de conseil, d'audit et cie facturé en moyenne 900 ¤ HT /
> j.
>
> Je vous renouvelle donc mon conseil : apprenez ce que sont les SGBDR...
>
>
>> A fait des modifs et les mémorise
>> B fait d'autres modifications et les mémorise
>>
>> En fait, lorsque A rappelle le client il ne voit plus ses modifs mais
>> celles effectuées par B.
>>
>> Soit le dernier qui mémorise gagne, soit on regarde par rapport à une
>> colonne timestamp mise à jour lors des mémorisations et on indique que
>> quelqu'un d'autre a fait des modifs entre temps et on refuse de mémoriser.
>>
>> Je préférerais indiquer un message à l'ouverture de la fiche du client
>
> il n'y a pas de "fiche " dans un SGBDR !!!
>
>> que quelqu'un d'autre est en train de le modifier et qu'il ne peut pas le
>> faire actuellement.
>>
>> Donc, si on ne peut pas bloquer une ligne je pourrais gérer ces semblants
>> de blocages par une table dans laquelle je mettrais le nom de la table
>> concernée, l'identifiant unique, l'utilisateur, la date et l'heure ... Pour
>> "bloquer" une ligne j'ajoute dans cette table et pour "débloquer" je
>> l'efface.
>
> Usine à gaz !!!
>
>>
>> Mais d'où ma remarque en cas de plantage ou de coupure de réseau. Cette
>> table contiendra des lignes considérées comme bloquées alors que cela n'est
>> pas le cas.
>
> Et oui... et comment faite vous pour distinguer les vrais blocage des faux
> ??? Si le client s'est reconnecté après un plantage par exemple ??? Vous
> aller auditer le réseau et avoir une table des trames TCP émises ??? Et si
> l'auditeur de trame réseau est lui même sur une banche défaillante du réseau
> ????????
> ect, etc, ect...
>
>>
>> J'ai effectivement regardé votre site et parcouru un de vos livres. Cela
>> m'a appris beaucoup mais je n'ai pas trouvé de réponse à cette question.
>>
>
> Ne cherchez pas votre question n'a aucun sens !
>
>> Cordialement
>>
>> Jean
>>
>>
>
> A +
>
>
>>
>> Fred BROUARD avait prétendu :
>>> Juanito a écrit :
>>>> Bonjour,
>>>>
>>>
>>> [...]
>>>
>>>> En fait, j'ai travaillé avant avec des gestionnaires de fichiers indexés
>>>> dans lesquels il y a des ordres de lecture bloquantes et des déblocages.
>>>> On peut donc lire et bloquer un enregistrement, faire plein de
>>>> traitements, de saisie ... et à la fin mémoriser et débloquer. Si un
>>>> autre poste essaie de faire une lecture blocante sur le même
>>>> enregistrement cela renvoie un mesasge d'erreur. J'aimerais reproduire la
>>>> même chose.
>>>
>>> D'ou vos question et votre erreur !
>>>
>>> C'est le SGBDR qui fait tout cela de manière automatique...
>>>
>>> Commencez par apprendre comment fonctionne un SGBDR. A partir de là vous
>>> aurez compris que vos questions n'ont aucun sens...
>>>
>>> Mon site web comme mes bouquins peuvent vous y aider !
>>>
>>> A +
>>
>>