Mais si le programme s'arrête anormalement (run-time error p.ex.), plus personne ne pourra modifier l'enregistrement (puisque le
champs n'a pas été remis a False).
Avez-vous d'autres idées ?
Mais si le programme s'arrête anormalement (run-time error p.ex.), plus personne ne pourra modifier l'enregistrement (puisque le
champs n'a pas été remis a False).
Avez-vous d'autres idées ?
Mais si le programme s'arrête anormalement (run-time error p.ex.), plus personne ne pourra modifier l'enregistrement (puisque le
champs n'a pas été remis a False).
Avez-vous d'autres idées ?
Bonjour à tous,
Dans une table (type Access & multi-users)
comment puis-je *marquer* un enregistrement pour signaler qu'il est en cours
de modification.
D'abord j'ai pensé ajouter un champ "Locked" et le mettre à True pour le
*marqué* afin d'empêcher les autres utilisateurs de faire des modifications.
Mais si le programme s'arrête anormalement (run-time error p.ex.), plus
personne ne pourra modifier l'enregistrement (puisque le champs n'a pas été
remis à False).
Avez-vous d'autres idées ?
Merci
Pascal B.
Bonjour à tous,
Dans une table (type Access & multi-users)
comment puis-je *marquer* un enregistrement pour signaler qu'il est en cours
de modification.
D'abord j'ai pensé ajouter un champ "Locked" et le mettre à True pour le
*marqué* afin d'empêcher les autres utilisateurs de faire des modifications.
Mais si le programme s'arrête anormalement (run-time error p.ex.), plus
personne ne pourra modifier l'enregistrement (puisque le champs n'a pas été
remis à False).
Avez-vous d'autres idées ?
Merci
Pascal B.
Bonjour à tous,
Dans une table (type Access & multi-users)
comment puis-je *marquer* un enregistrement pour signaler qu'il est en cours
de modification.
D'abord j'ai pensé ajouter un champ "Locked" et le mettre à True pour le
*marqué* afin d'empêcher les autres utilisateurs de faire des modifications.
Mais si le programme s'arrête anormalement (run-time error p.ex.), plus
personne ne pourra modifier l'enregistrement (puisque le champs n'a pas été
remis à False).
Avez-vous d'autres idées ?
Merci
Pascal B.
Salut,
La gestion native du locking n'est pas "bypasser"; je la gère même.
Mais ce locking se fait par PAGE donc sur plusieurs enregistrements et ne
Voici le principe:
Un dossier un composé d'un enregistrement principale et de plussieurs
Ainsi quand l'utilisateur ouvre un dossier, il doit être bloqué pour les
fermeture.
Cordialement
Pascal B.
"Quasimodo" wrote in message
| bonjour,
| MS Access via le jet, gére très bien les accès concurent, pourquoi
| voulez-vous bypasser sa gestion native par une gestion manuel de votre
| propre cru et qui ne sera peut être pas aussi bonne. Lorsque vous
| éditer un record et suivant son mode d'ouverture (optimistique, ...) le
| jet prend en charge le locking des records. Pouvez-vous peut être
| définir un peux plus ce que vous voulez fair.
Salut,
La gestion native du locking n'est pas "bypasser"; je la gère même.
Mais ce locking se fait par PAGE donc sur plusieurs enregistrements et ne
Voici le principe:
Un dossier un composé d'un enregistrement principale et de plussieurs
Ainsi quand l'utilisateur ouvre un dossier, il doit être bloqué pour les
fermeture.
Cordialement
Pascal B.
"Quasimodo" <wild_riki.@yahoo.fr> wrote in message
| bonjour,
| MS Access via le jet, gére très bien les accès concurent, pourquoi
| voulez-vous bypasser sa gestion native par une gestion manuel de votre
| propre cru et qui ne sera peut être pas aussi bonne. Lorsque vous
| éditer un record et suivant son mode d'ouverture (optimistique, ...) le
| jet prend en charge le locking des records. Pouvez-vous peut être
| définir un peux plus ce que vous voulez fair.
Salut,
La gestion native du locking n'est pas "bypasser"; je la gère même.
Mais ce locking se fait par PAGE donc sur plusieurs enregistrements et ne
Voici le principe:
Un dossier un composé d'un enregistrement principale et de plussieurs
Ainsi quand l'utilisateur ouvre un dossier, il doit être bloqué pour les
fermeture.
Cordialement
Pascal B.
"Quasimodo" wrote in message
| bonjour,
| MS Access via le jet, gére très bien les accès concurent, pourquoi
| voulez-vous bypasser sa gestion native par une gestion manuel de votre
| propre cru et qui ne sera peut être pas aussi bonne. Lorsque vous
| éditer un record et suivant son mode d'ouverture (optimistique, ...) le
| jet prend en charge le locking des records. Pouvez-vous peut être
| définir un peux plus ce que vous voulez fair.
H.S. - mais merci quand même.
Pascal B.
"YannX" wrote in message
| Bnjr,
|
| La demande de pascal me parait assez logique :
| vouloir mettre un Begin Transaction sur une lecture de table
| avec interruptions automatiques est le B.A.BA des SGBD !
| Il me semble que les modes d'ouvertures ADO d'Access permettent cela
| par certaines options du OpenRecordSet,
| mais n'etant pas plus spécialiste "pratique" que cela de l'Access
| je laisse a d'autres le soin de preciser exactement l'option voulue....
|
| transaction ----------------trouvé dans l'aide Access
| Série de modifications apportées aux données et au schéma d'une base de
| données. Marquez le début d'une transaction à l'aide de l'instruction
| BeginTrans, validez la transaction à l'aide de l'instruction CommitTrans
| annulez toutes vos modifications depuis BeginTrans à l'aide de
| Rollback. Les transactions sont facultatives et peuvent être imbriquées
| cinq niveaux. Les transactions augmentent la vitesse des opérations qui
| modifient les données et vous permettent d'inverser facilement les
| modifications. Les transactions s'appliquent globalement au Workspace de
| l'objet de base de données référencé.
| -----------------------
| quel est l'equivalent DAO et/ou ADO ? merci d'avance
|
|
| "Pascal B." a écrit dans le message de
| news:O$
| > Salut,
| >
| > La gestion native du locking n'est pas "bypasser"; je la gère même.
| > Mais ce locking se fait par PAGE donc sur plusieurs enregistrements et
| correspond pas à ce que je veux faire:
| >
| > Voici le principe:
| > Un dossier un composé d'un enregistrement principale et de plussieurs
| autres enregistrements dans des tables secondaires.
| > Ainsi quand l'utilisateur ouvre un dossier, il doit être bloqué pour
| autres en marquant son enregistrement principal jusqu'a sa
| > fermeture.
| >
| > Cordialement
| > Pascal B.
| >
| > "Quasimodo" wrote in message
| news:
| > | bonjour,
| > | MS Access via le jet, gére très bien les accès concurent, pourquoi
| > | voulez-vous bypasser sa gestion native par une gestion manuel de
| > | propre cru et qui ne sera peut être pas aussi bonne. Lorsque vous
| > | éditer un record et suivant son mode d'ouverture (optimistique, ...)
| > | jet prend en charge le locking des records. Pouvez-vous peut être
| > | définir un peux plus ce que vous voulez fair.
| >
| >
|
|
H.S. - mais merci quand même.
Pascal B.
"YannX" <ydx_nospam@yahoo.fr> wrote in message
| Bnjr,
|
| La demande de pascal me parait assez logique :
| vouloir mettre un Begin Transaction sur une lecture de table
| avec interruptions automatiques est le B.A.BA des SGBD !
| Il me semble que les modes d'ouvertures ADO d'Access permettent cela
| par certaines options du OpenRecordSet,
| mais n'etant pas plus spécialiste "pratique" que cela de l'Access
| je laisse a d'autres le soin de preciser exactement l'option voulue....
|
| transaction ----------------trouvé dans l'aide Access
| Série de modifications apportées aux données et au schéma d'une base de
| données. Marquez le début d'une transaction à l'aide de l'instruction
| BeginTrans, validez la transaction à l'aide de l'instruction CommitTrans
| annulez toutes vos modifications depuis BeginTrans à l'aide de
| Rollback. Les transactions sont facultatives et peuvent être imbriquées
| cinq niveaux. Les transactions augmentent la vitesse des opérations qui
| modifient les données et vous permettent d'inverser facilement les
| modifications. Les transactions s'appliquent globalement au Workspace de
| l'objet de base de données référencé.
| -----------------------
| quel est l'equivalent DAO et/ou ADO ? merci d'avance
|
|
| "Pascal B." <Pascbr@hotmail_ANTISPASM_.com> a écrit dans le message de
| news:O$vWSEywEHA.3292@TK2MSFTNGP15.phx.gbl...
| > Salut,
| >
| > La gestion native du locking n'est pas "bypasser"; je la gère même.
| > Mais ce locking se fait par PAGE donc sur plusieurs enregistrements et
| correspond pas à ce que je veux faire:
| >
| > Voici le principe:
| > Un dossier un composé d'un enregistrement principale et de plussieurs
| autres enregistrements dans des tables secondaires.
| > Ainsi quand l'utilisateur ouvre un dossier, il doit être bloqué pour
| autres en marquant son enregistrement principal jusqu'a sa
| > fermeture.
| >
| > Cordialement
| > Pascal B.
| >
| > "Quasimodo" <wild_riki.@yahoo.fr> wrote in message
| news:mn.2a6d7d4bb3e0910c.18602@yahoo.fr...
| > | bonjour,
| > | MS Access via le jet, gére très bien les accès concurent, pourquoi
| > | voulez-vous bypasser sa gestion native par une gestion manuel de
| > | propre cru et qui ne sera peut être pas aussi bonne. Lorsque vous
| > | éditer un record et suivant son mode d'ouverture (optimistique, ...)
| > | jet prend en charge le locking des records. Pouvez-vous peut être
| > | définir un peux plus ce que vous voulez fair.
| >
| >
|
|
H.S. - mais merci quand même.
Pascal B.
"YannX" wrote in message
| Bnjr,
|
| La demande de pascal me parait assez logique :
| vouloir mettre un Begin Transaction sur une lecture de table
| avec interruptions automatiques est le B.A.BA des SGBD !
| Il me semble que les modes d'ouvertures ADO d'Access permettent cela
| par certaines options du OpenRecordSet,
| mais n'etant pas plus spécialiste "pratique" que cela de l'Access
| je laisse a d'autres le soin de preciser exactement l'option voulue....
|
| transaction ----------------trouvé dans l'aide Access
| Série de modifications apportées aux données et au schéma d'une base de
| données. Marquez le début d'une transaction à l'aide de l'instruction
| BeginTrans, validez la transaction à l'aide de l'instruction CommitTrans
| annulez toutes vos modifications depuis BeginTrans à l'aide de
| Rollback. Les transactions sont facultatives et peuvent être imbriquées
| cinq niveaux. Les transactions augmentent la vitesse des opérations qui
| modifient les données et vous permettent d'inverser facilement les
| modifications. Les transactions s'appliquent globalement au Workspace de
| l'objet de base de données référencé.
| -----------------------
| quel est l'equivalent DAO et/ou ADO ? merci d'avance
|
|
| "Pascal B." a écrit dans le message de
| news:O$
| > Salut,
| >
| > La gestion native du locking n'est pas "bypasser"; je la gère même.
| > Mais ce locking se fait par PAGE donc sur plusieurs enregistrements et
| correspond pas à ce que je veux faire:
| >
| > Voici le principe:
| > Un dossier un composé d'un enregistrement principale et de plussieurs
| autres enregistrements dans des tables secondaires.
| > Ainsi quand l'utilisateur ouvre un dossier, il doit être bloqué pour
| autres en marquant son enregistrement principal jusqu'a sa
| > fermeture.
| >
| > Cordialement
| > Pascal B.
| >
| > "Quasimodo" wrote in message
| news:
| > | bonjour,
| > | MS Access via le jet, gére très bien les accès concurent, pourquoi
| > | voulez-vous bypasser sa gestion native par une gestion manuel de
| > | propre cru et qui ne sera peut être pas aussi bonne. Lorsque vous
| > | éditer un record et suivant son mode d'ouverture (optimistique, ...)
| > | jet prend en charge le locking des records. Pouvez-vous peut être
| > | définir un peux plus ce que vous voulez fair.
| >
| >
|
|
Ne te vexe pas ...
Je cherche *simplement* une METHODE SURE qui me permet
d'empêcher un utilisateur de modifier quelque chose qui
est DEJA EN TRAIN d'être modifié par un autre utilisateur.
Exemple:
L'utilisateur "A" double-clique sur un nom de client dans une liste pour
Une Form s'ouvrira donc avec toutes ses coordonées.
Tant que l'utilisateur "A" n'a pas fermé cette Form, la fiche de ce client
(sur un autre poste) ne puisse aussi modifié cette même fiche.
Cordialement,
Pascal B.
"YannX" wrote in message
| Désolé, je n'ai donc pas compris l'objectif précis !
| Je viens pourtant de relire tout le fil !
| ???????
Ne te vexe pas ...
Je cherche *simplement* une METHODE SURE qui me permet
d'empêcher un utilisateur de modifier quelque chose qui
est DEJA EN TRAIN d'être modifié par un autre utilisateur.
Exemple:
L'utilisateur "A" double-clique sur un nom de client dans une liste pour
Une Form s'ouvrira donc avec toutes ses coordonées.
Tant que l'utilisateur "A" n'a pas fermé cette Form, la fiche de ce client
(sur un autre poste) ne puisse aussi modifié cette même fiche.
Cordialement,
Pascal B.
"YannX" <ydx_nospam@yahoo.fr> wrote in message
| Désolé, je n'ai donc pas compris l'objectif précis !
| Je viens pourtant de relire tout le fil !
| ???????
Ne te vexe pas ...
Je cherche *simplement* une METHODE SURE qui me permet
d'empêcher un utilisateur de modifier quelque chose qui
est DEJA EN TRAIN d'être modifié par un autre utilisateur.
Exemple:
L'utilisateur "A" double-clique sur un nom de client dans une liste pour
Une Form s'ouvrira donc avec toutes ses coordonées.
Tant que l'utilisateur "A" n'a pas fermé cette Form, la fiche de ce client
(sur un autre poste) ne puisse aussi modifié cette même fiche.
Cordialement,
Pascal B.
"YannX" wrote in message
| Désolé, je n'ai donc pas compris l'objectif précis !
| Je viens pourtant de relire tout le fil !
| ???????
Bonjour à tous,
Dans une table (type Access & multi-users)
comment puis-je *marquer* un enregistrement pour signaler qu'il est en cours
de modification.
D'abord j'ai pensé ajouter un champ "Locked" et le mettre à True pour le
*marqué* afin d'empêcher les autres utilisateurs de faire des modifications.
Mais si le programme s'arrête anormalement (run-time error p.ex.), plus
personne ne pourra modifier l'enregistrement (puisque le champs n'a pas été
remis à False).
Avez-vous d'autres idées ?
Merci
Pascal B.
Bonjour à tous,
Dans une table (type Access & multi-users)
comment puis-je *marquer* un enregistrement pour signaler qu'il est en cours
de modification.
D'abord j'ai pensé ajouter un champ "Locked" et le mettre à True pour le
*marqué* afin d'empêcher les autres utilisateurs de faire des modifications.
Mais si le programme s'arrête anormalement (run-time error p.ex.), plus
personne ne pourra modifier l'enregistrement (puisque le champs n'a pas été
remis à False).
Avez-vous d'autres idées ?
Merci
Pascal B.
Bonjour à tous,
Dans une table (type Access & multi-users)
comment puis-je *marquer* un enregistrement pour signaler qu'il est en cours
de modification.
D'abord j'ai pensé ajouter un champ "Locked" et le mettre à True pour le
*marqué* afin d'empêcher les autres utilisateurs de faire des modifications.
Mais si le programme s'arrête anormalement (run-time error p.ex.), plus
personne ne pourra modifier l'enregistrement (puisque le champs n'a pas été
remis à False).
Avez-vous d'autres idées ?
Merci
Pascal B.
Non, je n'etais absolument pas sur de la vexation .......no problemo,
juste que je cherchais a etre sur de bien comprendre !
Alors, au-dela du blocage implicite automatique de Jet (au niveau page,
dis-tu ? cf.Oracle ;-)
je maintiens que la bonne technique de tout SGBD qui se respecte,
pour bloquer un-des enregistrments inter-liés en modification,
est d'encapsuler l'ensemble des opérations SELECT.......... jusqu'aux UPDATE
dans un BEGIN TRANSACTION ............ COMMIT .......or ROLLBACK
(sous-entendu, l'enregistrement maitre, et tous les enregistrements reliés).
(en cas de plantage-blocage....il est du ressort du SGBD de fermer par
Rollback...
Mais pour te donner exactement la syntaxe a utiliser,
je ne me suis pas encore penché sur le problème en Access/VB pour te
repondre comme cela!
Déjà, en VB6, mais lequel : en DAO ou en ADO ?
JET natif ou SQL Serveur / MSDE ?
@+
Y
PS : comme le blocage (ici tu veux le faire au niveau du Form_Load() peut
durer "longtemps"
les vieilles techniques de SGBD traditionnelles consistaient à faire
une copie-buffer sans blocage,
puis, au moment de la mise a jour-écriture, a enchainer dans une
opération "transaction" :
- BEGIN TRANSACTION
- relire les enreg. déjà mémorisés en buffer,
- comparer avec le buffer copié,
- si pas de modif, modifier TOUS les enregistrements en mémoire
avec ré-écriture sous controle du SGBD,
- si pas d'erreur END TRANSACTION = COMMIT de validation
sinon ROLLBACK = on n'a pas enregistré les modifications
car un autre user est venu entre-temps modifier les données
(alternative selon l'application ! appliquer les modifs,
sur la version relue juste avant !
Le tout bien sur dans une seule procedure non-interruptible
par un queconque evenement utilisateur bien sur !
Un peu lourd, oui, surout que je n'ai pas vue de belles instructions
sachant gérer tout un enregistrement en Stream (comme une zone binaire)
Mais c'est le principe garanti !!!!!!!
"Pascal B." a écrit dans le message de
news:Ne te vexe pas ...
Je cherche *simplement* une METHODE SURE qui me permet
d'empêcher un utilisateur de modifier quelque chose qui
est DEJA EN TRAIN d'être modifié par un autre utilisateur.
Exemple:
L'utilisateur "A" double-clique sur un nom de client dans une liste pour
modifier ses données. Une Form s'ouvrira donc avec toutes ses coordonées.
Tant que l'utilisateur "A" n'a pas fermé cette Form, la fiche de ce client
doit être bloqué de telle sorte que l'utilisateur "B" (sur un autre poste)
ne puisse aussi modifié cette même fiche.
Cordialement,
Pascal B.
"YannX" wrote in message
news:Désolé, je n'ai donc pas compris l'objectif précis !
Je viens pourtant de relire tout le fil !
???????
Non, je n'etais absolument pas sur de la vexation .......no problemo,
juste que je cherchais a etre sur de bien comprendre !
Alors, au-dela du blocage implicite automatique de Jet (au niveau page,
dis-tu ? cf.Oracle ;-)
je maintiens que la bonne technique de tout SGBD qui se respecte,
pour bloquer un-des enregistrments inter-liés en modification,
est d'encapsuler l'ensemble des opérations SELECT.......... jusqu'aux UPDATE
dans un BEGIN TRANSACTION ............ COMMIT .......or ROLLBACK
(sous-entendu, l'enregistrement maitre, et tous les enregistrements reliés).
(en cas de plantage-blocage....il est du ressort du SGBD de fermer par
Rollback...
Mais pour te donner exactement la syntaxe a utiliser,
je ne me suis pas encore penché sur le problème en Access/VB pour te
repondre comme cela!
Déjà, en VB6, mais lequel : en DAO ou en ADO ?
JET natif ou SQL Serveur / MSDE ?
@+
Y
PS : comme le blocage (ici tu veux le faire au niveau du Form_Load() peut
durer "longtemps"
les vieilles techniques de SGBD traditionnelles consistaient à faire
une copie-buffer sans blocage,
puis, au moment de la mise a jour-écriture, a enchainer dans une
opération "transaction" :
- BEGIN TRANSACTION
- relire les enreg. déjà mémorisés en buffer,
- comparer avec le buffer copié,
- si pas de modif, modifier TOUS les enregistrements en mémoire
avec ré-écriture sous controle du SGBD,
- si pas d'erreur END TRANSACTION = COMMIT de validation
sinon ROLLBACK = on n'a pas enregistré les modifications
car un autre user est venu entre-temps modifier les données
(alternative selon l'application ! appliquer les modifs,
sur la version relue juste avant !
Le tout bien sur dans une seule procedure non-interruptible
par un queconque evenement utilisateur bien sur !
Un peu lourd, oui, surout que je n'ai pas vue de belles instructions
sachant gérer tout un enregistrement en Stream (comme une zone binaire)
Mais c'est le principe garanti !!!!!!!
"Pascal B." <Pascbr@hotmail_ANTISPASM_.com> a écrit dans le message de
news:eHjgGrzwEHA.1192@tk2msftngp13.phx.gbl...
Ne te vexe pas ...
Je cherche *simplement* une METHODE SURE qui me permet
d'empêcher un utilisateur de modifier quelque chose qui
est DEJA EN TRAIN d'être modifié par un autre utilisateur.
Exemple:
L'utilisateur "A" double-clique sur un nom de client dans une liste pour
modifier ses données. Une Form s'ouvrira donc avec toutes ses coordonées.
Tant que l'utilisateur "A" n'a pas fermé cette Form, la fiche de ce client
doit être bloqué de telle sorte que l'utilisateur "B" (sur un autre poste)
ne puisse aussi modifié cette même fiche.
Cordialement,
Pascal B.
"YannX" <ydx_nospam@yahoo.fr> wrote in message
news:O0VwhYzwEHA.3292@TK2MSFTNGP15.phx.gbl...
Désolé, je n'ai donc pas compris l'objectif précis !
Je viens pourtant de relire tout le fil !
???????
Non, je n'etais absolument pas sur de la vexation .......no problemo,
juste que je cherchais a etre sur de bien comprendre !
Alors, au-dela du blocage implicite automatique de Jet (au niveau page,
dis-tu ? cf.Oracle ;-)
je maintiens que la bonne technique de tout SGBD qui se respecte,
pour bloquer un-des enregistrments inter-liés en modification,
est d'encapsuler l'ensemble des opérations SELECT.......... jusqu'aux UPDATE
dans un BEGIN TRANSACTION ............ COMMIT .......or ROLLBACK
(sous-entendu, l'enregistrement maitre, et tous les enregistrements reliés).
(en cas de plantage-blocage....il est du ressort du SGBD de fermer par
Rollback...
Mais pour te donner exactement la syntaxe a utiliser,
je ne me suis pas encore penché sur le problème en Access/VB pour te
repondre comme cela!
Déjà, en VB6, mais lequel : en DAO ou en ADO ?
JET natif ou SQL Serveur / MSDE ?
@+
Y
PS : comme le blocage (ici tu veux le faire au niveau du Form_Load() peut
durer "longtemps"
les vieilles techniques de SGBD traditionnelles consistaient à faire
une copie-buffer sans blocage,
puis, au moment de la mise a jour-écriture, a enchainer dans une
opération "transaction" :
- BEGIN TRANSACTION
- relire les enreg. déjà mémorisés en buffer,
- comparer avec le buffer copié,
- si pas de modif, modifier TOUS les enregistrements en mémoire
avec ré-écriture sous controle du SGBD,
- si pas d'erreur END TRANSACTION = COMMIT de validation
sinon ROLLBACK = on n'a pas enregistré les modifications
car un autre user est venu entre-temps modifier les données
(alternative selon l'application ! appliquer les modifs,
sur la version relue juste avant !
Le tout bien sur dans une seule procedure non-interruptible
par un queconque evenement utilisateur bien sur !
Un peu lourd, oui, surout que je n'ai pas vue de belles instructions
sachant gérer tout un enregistrement en Stream (comme une zone binaire)
Mais c'est le principe garanti !!!!!!!
"Pascal B." a écrit dans le message de
news:Ne te vexe pas ...
Je cherche *simplement* une METHODE SURE qui me permet
d'empêcher un utilisateur de modifier quelque chose qui
est DEJA EN TRAIN d'être modifié par un autre utilisateur.
Exemple:
L'utilisateur "A" double-clique sur un nom de client dans une liste pour
modifier ses données. Une Form s'ouvrira donc avec toutes ses coordonées.
Tant que l'utilisateur "A" n'a pas fermé cette Form, la fiche de ce client
doit être bloqué de telle sorte que l'utilisateur "B" (sur un autre poste)
ne puisse aussi modifié cette même fiche.
Cordialement,
Pascal B.
"YannX" wrote in message
news:Désolé, je n'ai donc pas compris l'objectif précis !
Je viens pourtant de relire tout le fil !
???????
