-----Message d'origine-----
Salut,
La solution envisagée est pire que le problème
initial. Utiliser 1+Dmax
est certainement la chose la plus sage, si les données
sont nécessairement
saisies depuis un formulaire. Moi, je l'utilise dans la
procédure Current:
If Me.NewRecord Then
Me.ControleApproprié = 1+ DMax( ... )
End If
En design the table, je mais un index ne permettant pas
de doublons sur ce
champ.
En design the table, je capture l'erreur passée comme
argument de la
procédure onError et si elle correspond à un échec de
sauvegarde car il y
aurait génération de doublon, je recalcule, simplement
réexécute:
Me.ControleApproprié = 1+ DMax( ... )
et resoumet la sauvegarde (ce problème ne peut survenir
qu'en environnement
impliquant plusieurs utilisateurs). Bien sûr, cela
implique que pour un
nouvel enregistrement, la valeur affichée par 1+Dmax( )
est plutôt une
tentative. Seulement après la sauvegarde devient elle
confirmée... tout
comme le reste des autres valeurs de l'enregistrement, en
fait... mais cette
méchanique, même si elle est tout à fait logique, peut
surprendre le
non-inítié.
Si le 1+Dmax ne convient pas, on peut
toujours "remettre à jour" sans
compacter. Il suffit d'ajouter un enregistrement "bidon"
où on fournit la
valeur n-1 pour le champ autonum. Exemple:
CurrentDb.Execute "INSERT INTO table(
champAutonum) VALUES ( 1567)
", dbFailOnError
(Technique: Il faut fournir une valeur à tous les champs
ne pouvant accepter
un NULL tout en n'ayant pas de valeurs par défaut, si il
y en a, en plus du
champ à numérotation automatique).
Ceci fait, effacer tout de suite après.
CurrentDb.Execute "DELETE FROM table WHERE
champAutonum67"
Le prochain enregistrement aura 1568 comme valeur
générée
automatiquement (c'est à dire, si on ne spécifie pas de
valeurs pour le
champ autogénéré). Noter qu'un champ généré
automatiquement N'IMPLIQUE PAS
qu'il ne produit pas de DOUBLONS. On peut, ainsi, avec
cette technique,
ajouter plusieurs enregistrements avec la valeur 1568, ou
1567 (avec le
INSERT INTO plus haut). Si on ne veut pas de doublons,
faut le préciser! en
plus!
Mais je maintiens que 1+Dmax est le chemin à suivre.
Espérant être utile,
Vanderghast, Access MVP
"Stach" wrote in
message
news:079e01c39939$edf35a40$
Bonjour,
en fait, cette manoeuvre a pour but d'exécuter un module
dans la base dorsale qui permet automatiquement d'importer
une table de la base dorsale contenant un champ NumeroAuto
que je veux incrémenter (et ne perdre aucun numéro dans ce
champ si par malheur je dois supprimer le dernier
enregistrement)puis exporter cette copie vers la base
dorsale afin qu'elle remplace l'ancienne table
J'ai bien essayé de faire tout ça à partir de la base
frontale en faisant un "import-export" de cette table,
puis en rétablissant les liens entre la dorsale et la
frontale, mais le problème est que lorsque je veux
supprimer l'ancienne table, access me crée des misère car
elle dépend de une ou plusieure relation.
si je savais exactement comment à partir de la base
Frontale:
1°) supprimmer les relations de la table "tblTEST" (champs
de relation "plusieur": [txt]) avec celle de la
table "tblTXT" (champs de relation "un": [txt] aussi)
(???)
2°) Importer "tblTEST" dans ma base frontale (OK)
3°) Exporter la copie de "tblTEST" vers la base Dorsale
(OK)
4°) Rétablir les relations dans la base Dorsale (???)
5°) Rétablir les liens entre Frontale et Dorsale (OK)
Cela me permettrai de ne plus jamais perdre de NumeroAuto
qui me servent de clé primaire dans la table.
On m'a bien conseiller d'utiliser "DMax()+1" mais ça ne
s'applique pas vu que ce genre de formule ne peux être
stocquée dans une table.
Grand merci de m'aider.
Stach ;-)
.
-----Message d'origine-----
Salut,
La solution envisagée est pire que le problème
initial. Utiliser 1+Dmax
est certainement la chose la plus sage, si les données
sont nécessairement
saisies depuis un formulaire. Moi, je l'utilise dans la
procédure Current:
If Me.NewRecord Then
Me.ControleApproprié = 1+ DMax( ... )
End If
En design the table, je mais un index ne permettant pas
de doublons sur ce
champ.
En design the table, je capture l'erreur passée comme
argument de la
procédure onError et si elle correspond à un échec de
sauvegarde car il y
aurait génération de doublon, je recalcule, simplement
réexécute:
Me.ControleApproprié = 1+ DMax( ... )
et resoumet la sauvegarde (ce problème ne peut survenir
qu'en environnement
impliquant plusieurs utilisateurs). Bien sûr, cela
implique que pour un
nouvel enregistrement, la valeur affichée par 1+Dmax( )
est plutôt une
tentative. Seulement après la sauvegarde devient elle
confirmée... tout
comme le reste des autres valeurs de l'enregistrement, en
fait... mais cette
méchanique, même si elle est tout à fait logique, peut
surprendre le
non-inítié.
Si le 1+Dmax ne convient pas, on peut
toujours "remettre à jour" sans
compacter. Il suffit d'ajouter un enregistrement "bidon"
où on fournit la
valeur n-1 pour le champ autonum. Exemple:
CurrentDb.Execute "INSERT INTO table(
champAutonum) VALUES ( 1567)
", dbFailOnError
(Technique: Il faut fournir une valeur à tous les champs
ne pouvant accepter
un NULL tout en n'ayant pas de valeurs par défaut, si il
y en a, en plus du
champ à numérotation automatique).
Ceci fait, effacer tout de suite après.
CurrentDb.Execute "DELETE FROM table WHERE
champAutonum=1567"
Le prochain enregistrement aura 1568 comme valeur
générée
automatiquement (c'est à dire, si on ne spécifie pas de
valeurs pour le
champ autogénéré). Noter qu'un champ généré
automatiquement N'IMPLIQUE PAS
qu'il ne produit pas de DOUBLONS. On peut, ainsi, avec
cette technique,
ajouter plusieurs enregistrements avec la valeur 1568, ou
1567 (avec le
INSERT INTO plus haut). Si on ne veut pas de doublons,
faut le préciser! en
plus!
Mais je maintiens que 1+Dmax est le chemin à suivre.
Espérant être utile,
Vanderghast, Access MVP
"Stach" <anonymous@discussions.microsoft.com> wrote in
message
news:079e01c39939$edf35a40$a401280a@phx.gbl...
Bonjour,
en fait, cette manoeuvre a pour but d'exécuter un module
dans la base dorsale qui permet automatiquement d'importer
une table de la base dorsale contenant un champ NumeroAuto
que je veux incrémenter (et ne perdre aucun numéro dans ce
champ si par malheur je dois supprimer le dernier
enregistrement)puis exporter cette copie vers la base
dorsale afin qu'elle remplace l'ancienne table
J'ai bien essayé de faire tout ça à partir de la base
frontale en faisant un "import-export" de cette table,
puis en rétablissant les liens entre la dorsale et la
frontale, mais le problème est que lorsque je veux
supprimer l'ancienne table, access me crée des misère car
elle dépend de une ou plusieure relation.
si je savais exactement comment à partir de la base
Frontale:
1°) supprimmer les relations de la table "tblTEST" (champs
de relation "plusieur": [txt]) avec celle de la
table "tblTXT" (champs de relation "un": [txt] aussi)
(???)
2°) Importer "tblTEST" dans ma base frontale (OK)
3°) Exporter la copie de "tblTEST" vers la base Dorsale
(OK)
4°) Rétablir les relations dans la base Dorsale (???)
5°) Rétablir les liens entre Frontale et Dorsale (OK)
Cela me permettrai de ne plus jamais perdre de NumeroAuto
qui me servent de clé primaire dans la table.
On m'a bien conseiller d'utiliser "DMax()+1" mais ça ne
s'applique pas vu que ce genre de formule ne peux être
stocquée dans une table.
Grand merci de m'aider.
Stach ;-)
.
-----Message d'origine-----
Salut,
La solution envisagée est pire que le problème
initial. Utiliser 1+Dmax
est certainement la chose la plus sage, si les données
sont nécessairement
saisies depuis un formulaire. Moi, je l'utilise dans la
procédure Current:
If Me.NewRecord Then
Me.ControleApproprié = 1+ DMax( ... )
End If
En design the table, je mais un index ne permettant pas
de doublons sur ce
champ.
En design the table, je capture l'erreur passée comme
argument de la
procédure onError et si elle correspond à un échec de
sauvegarde car il y
aurait génération de doublon, je recalcule, simplement
réexécute:
Me.ControleApproprié = 1+ DMax( ... )
et resoumet la sauvegarde (ce problème ne peut survenir
qu'en environnement
impliquant plusieurs utilisateurs). Bien sûr, cela
implique que pour un
nouvel enregistrement, la valeur affichée par 1+Dmax( )
est plutôt une
tentative. Seulement après la sauvegarde devient elle
confirmée... tout
comme le reste des autres valeurs de l'enregistrement, en
fait... mais cette
méchanique, même si elle est tout à fait logique, peut
surprendre le
non-inítié.
Si le 1+Dmax ne convient pas, on peut
toujours "remettre à jour" sans
compacter. Il suffit d'ajouter un enregistrement "bidon"
où on fournit la
valeur n-1 pour le champ autonum. Exemple:
CurrentDb.Execute "INSERT INTO table(
champAutonum) VALUES ( 1567)
", dbFailOnError
(Technique: Il faut fournir une valeur à tous les champs
ne pouvant accepter
un NULL tout en n'ayant pas de valeurs par défaut, si il
y en a, en plus du
champ à numérotation automatique).
Ceci fait, effacer tout de suite après.
CurrentDb.Execute "DELETE FROM table WHERE
champAutonum67"
Le prochain enregistrement aura 1568 comme valeur
générée
automatiquement (c'est à dire, si on ne spécifie pas de
valeurs pour le
champ autogénéré). Noter qu'un champ généré
automatiquement N'IMPLIQUE PAS
qu'il ne produit pas de DOUBLONS. On peut, ainsi, avec
cette technique,
ajouter plusieurs enregistrements avec la valeur 1568, ou
1567 (avec le
INSERT INTO plus haut). Si on ne veut pas de doublons,
faut le préciser! en
plus!
Mais je maintiens que 1+Dmax est le chemin à suivre.
Espérant être utile,
Vanderghast, Access MVP
"Stach" wrote in
message
news:079e01c39939$edf35a40$
Bonjour,
en fait, cette manoeuvre a pour but d'exécuter un module
dans la base dorsale qui permet automatiquement d'importer
une table de la base dorsale contenant un champ NumeroAuto
que je veux incrémenter (et ne perdre aucun numéro dans ce
champ si par malheur je dois supprimer le dernier
enregistrement)puis exporter cette copie vers la base
dorsale afin qu'elle remplace l'ancienne table
J'ai bien essayé de faire tout ça à partir de la base
frontale en faisant un "import-export" de cette table,
puis en rétablissant les liens entre la dorsale et la
frontale, mais le problème est que lorsque je veux
supprimer l'ancienne table, access me crée des misère car
elle dépend de une ou plusieure relation.
si je savais exactement comment à partir de la base
Frontale:
1°) supprimmer les relations de la table "tblTEST" (champs
de relation "plusieur": [txt]) avec celle de la
table "tblTXT" (champs de relation "un": [txt] aussi)
(???)
2°) Importer "tblTEST" dans ma base frontale (OK)
3°) Exporter la copie de "tblTEST" vers la base Dorsale
(OK)
4°) Rétablir les relations dans la base Dorsale (???)
5°) Rétablir les liens entre Frontale et Dorsale (OK)
Cela me permettrai de ne plus jamais perdre de NumeroAuto
qui me servent de clé primaire dans la table.
On m'a bien conseiller d'utiliser "DMax()+1" mais ça ne
s'applique pas vu que ce genre de formule ne peux être
stocquée dans une table.
Grand merci de m'aider.
Stach ;-)
.
-----Message d'origine-----
Salut,
La solution envisagée est pire que le problème
initial. Utiliser 1+Dmax
est certainement la chose la plus sage, si les données
sont nécessairement
saisies depuis un formulaire. Moi, je l'utilise dans la
procédure Current:
If Me.NewRecord Then
Me.ControleApproprié = 1+ DMax( ... )
End If
En design the table, je mais un index ne permettant pas
de doublons sur ce
champ.
En design the table, je capture l'erreur passée comme
argument de la
procédure onError et si elle correspond à un échec de
sauvegarde car il y
aurait génération de doublon, je recalcule, simplement
réexécute:
Me.ControleApproprié = 1+ DMax( ... )
et resoumet la sauvegarde (ce problème ne peut survenir
qu'en environnement
impliquant plusieurs utilisateurs). Bien sûr, cela
implique que pour un
nouvel enregistrement, la valeur affichée par 1+Dmax( )
est plutôt une
tentative. Seulement après la sauvegarde devient elle
confirmée... tout
comme le reste des autres valeurs de l'enregistrement, en
fait... mais cette
méchanique, même si elle est tout à fait logique, peut
surprendre le
non-inítié.
Si le 1+Dmax ne convient pas, on peut
toujours "remettre à jour" sans
compacter. Il suffit d'ajouter un enregistrement "bidon"
où on fournit la
valeur n-1 pour le champ autonum. Exemple:
CurrentDb.Execute "INSERT INTO table(
champAutonum) VALUES ( 1567)
", dbFailOnError
(Technique: Il faut fournir une valeur à tous les champs
ne pouvant accepter
un NULL tout en n'ayant pas de valeurs par défaut, si il
y en a, en plus du
champ à numérotation automatique).
Ceci fait, effacer tout de suite après.
CurrentDb.Execute "DELETE FROM table WHERE
champAutonum67"
Le prochain enregistrement aura 1568 comme valeur
générée
automatiquement (c'est à dire, si on ne spécifie pas de
valeurs pour le
champ autogénéré). Noter qu'un champ généré
automatiquement N'IMPLIQUE PAS
qu'il ne produit pas de DOUBLONS. On peut, ainsi, avec
cette technique,
ajouter plusieurs enregistrements avec la valeur 1568, ou
1567 (avec le
INSERT INTO plus haut). Si on ne veut pas de doublons,
faut le préciser! en
plus!
Mais je maintiens que 1+Dmax est le chemin à suivre.
Espérant être utile,
Vanderghast, Access MVP
"Stach" wrote in
message
news:079e01c39939$edf35a40$
Bonjour,
en fait, cette manoeuvre a pour but d'exécuter un module
dans la base dorsale qui permet automatiquement d'importer
une table de la base dorsale contenant un champ NumeroAuto
que je veux incrémenter (et ne perdre aucun numéro dans ce
champ si par malheur je dois supprimer le dernier
enregistrement)puis exporter cette copie vers la base
dorsale afin qu'elle remplace l'ancienne table
J'ai bien essayé de faire tout ça à partir de la base
frontale en faisant un "import-export" de cette table,
puis en rétablissant les liens entre la dorsale et la
frontale, mais le problème est que lorsque je veux
supprimer l'ancienne table, access me crée des misère car
elle dépend de une ou plusieure relation.
si je savais exactement comment à partir de la base
Frontale:
1°) supprimmer les relations de la table "tblTEST" (champs
de relation "plusieur": [txt]) avec celle de la
table "tblTXT" (champs de relation "un": [txt] aussi)
(???)
2°) Importer "tblTEST" dans ma base frontale (OK)
3°) Exporter la copie de "tblTEST" vers la base Dorsale
(OK)
4°) Rétablir les relations dans la base Dorsale (???)
5°) Rétablir les liens entre Frontale et Dorsale (OK)
Cela me permettrai de ne plus jamais perdre de NumeroAuto
qui me servent de clé primaire dans la table.
On m'a bien conseiller d'utiliser "DMax()+1" mais ça ne
s'applique pas vu que ce genre de formule ne peux être
stocquée dans une table.
Grand merci de m'aider.
Stach ;-)
.
-----Message d'origine-----
Salut,
La solution envisagée est pire que le problème
initial. Utiliser 1+Dmax
est certainement la chose la plus sage, si les données
sont nécessairement
saisies depuis un formulaire. Moi, je l'utilise dans la
procédure Current:
If Me.NewRecord Then
Me.ControleApproprié = 1+ DMax( ... )
End If
En design the table, je mais un index ne permettant pas
de doublons sur ce
champ.
En design the table, je capture l'erreur passée comme
argument de la
procédure onError et si elle correspond à un échec de
sauvegarde car il y
aurait génération de doublon, je recalcule, simplement
réexécute:
Me.ControleApproprié = 1+ DMax( ... )
et resoumet la sauvegarde (ce problème ne peut survenir
qu'en environnement
impliquant plusieurs utilisateurs). Bien sûr, cela
implique que pour un
nouvel enregistrement, la valeur affichée par 1+Dmax( )
est plutôt une
tentative. Seulement après la sauvegarde devient elle
confirmée... tout
comme le reste des autres valeurs de l'enregistrement, en
fait... mais cette
méchanique, même si elle est tout à fait logique, peut
surprendre le
non-inítié.
Si le 1+Dmax ne convient pas, on peut
toujours "remettre à jour" sans
compacter. Il suffit d'ajouter un enregistrement "bidon"
où on fournit la
valeur n-1 pour le champ autonum. Exemple:
CurrentDb.Execute "INSERT INTO table(
champAutonum) VALUES ( 1567)
", dbFailOnError
(Technique: Il faut fournir une valeur à tous les champs
ne pouvant accepter
un NULL tout en n'ayant pas de valeurs par défaut, si il
y en a, en plus du
champ à numérotation automatique).
Ceci fait, effacer tout de suite après.
CurrentDb.Execute "DELETE FROM table WHERE
champAutonum67"
Le prochain enregistrement aura 1568 comme valeur
générée
automatiquement (c'est à dire, si on ne spécifie pas de
valeurs pour le
champ autogénéré). Noter qu'un champ généré
automatiquement N'IMPLIQUE PAS
qu'il ne produit pas de DOUBLONS. On peut, ainsi, avec
cette technique,
ajouter plusieurs enregistrements avec la valeur 1568, ou
1567 (avec le
INSERT INTO plus haut). Si on ne veut pas de doublons,
faut le préciser! en
plus!
Mais je maintiens que 1+Dmax est le chemin à suivre.
Espérant être utile,
Vanderghast, Access MVP
"Stach" <anonymous@discussions.microsoft.com> wrote in
message
news:079e01c39939$edf35a40$a401280a@phx.gbl...
Bonjour,
en fait, cette manoeuvre a pour but d'exécuter un module
dans la base dorsale qui permet automatiquement d'importer
une table de la base dorsale contenant un champ NumeroAuto
que je veux incrémenter (et ne perdre aucun numéro dans ce
champ si par malheur je dois supprimer le dernier
enregistrement)puis exporter cette copie vers la base
dorsale afin qu'elle remplace l'ancienne table
J'ai bien essayé de faire tout ça à partir de la base
frontale en faisant un "import-export" de cette table,
puis en rétablissant les liens entre la dorsale et la
frontale, mais le problème est que lorsque je veux
supprimer l'ancienne table, access me crée des misère car
elle dépend de une ou plusieure relation.
si je savais exactement comment à partir de la base
Frontale:
1°) supprimmer les relations de la table "tblTEST" (champs
de relation "plusieur": [txt]) avec celle de la
table "tblTXT" (champs de relation "un": [txt] aussi)
(???)
2°) Importer "tblTEST" dans ma base frontale (OK)
3°) Exporter la copie de "tblTEST" vers la base Dorsale
(OK)
4°) Rétablir les relations dans la base Dorsale (???)
5°) Rétablir les liens entre Frontale et Dorsale (OK)
Cela me permettrai de ne plus jamais perdre de NumeroAuto
qui me servent de clé primaire dans la table.
On m'a bien conseiller d'utiliser "DMax()+1" mais ça ne
s'applique pas vu que ce genre de formule ne peux être
stocquée dans une table.
Grand merci de m'aider.
Stach ;-)
.
-----Message d'origine-----
Salut,
La solution envisagée est pire que le problème
initial. Utiliser 1+Dmax
est certainement la chose la plus sage, si les données
sont nécessairement
saisies depuis un formulaire. Moi, je l'utilise dans la
procédure Current:
If Me.NewRecord Then
Me.ControleApproprié = 1+ DMax( ... )
End If
En design the table, je mais un index ne permettant pas
de doublons sur ce
champ.
En design the table, je capture l'erreur passée comme
argument de la
procédure onError et si elle correspond à un échec de
sauvegarde car il y
aurait génération de doublon, je recalcule, simplement
réexécute:
Me.ControleApproprié = 1+ DMax( ... )
et resoumet la sauvegarde (ce problème ne peut survenir
qu'en environnement
impliquant plusieurs utilisateurs). Bien sûr, cela
implique que pour un
nouvel enregistrement, la valeur affichée par 1+Dmax( )
est plutôt une
tentative. Seulement après la sauvegarde devient elle
confirmée... tout
comme le reste des autres valeurs de l'enregistrement, en
fait... mais cette
méchanique, même si elle est tout à fait logique, peut
surprendre le
non-inítié.
Si le 1+Dmax ne convient pas, on peut
toujours "remettre à jour" sans
compacter. Il suffit d'ajouter un enregistrement "bidon"
où on fournit la
valeur n-1 pour le champ autonum. Exemple:
CurrentDb.Execute "INSERT INTO table(
champAutonum) VALUES ( 1567)
", dbFailOnError
(Technique: Il faut fournir une valeur à tous les champs
ne pouvant accepter
un NULL tout en n'ayant pas de valeurs par défaut, si il
y en a, en plus du
champ à numérotation automatique).
Ceci fait, effacer tout de suite après.
CurrentDb.Execute "DELETE FROM table WHERE
champAutonum67"
Le prochain enregistrement aura 1568 comme valeur
générée
automatiquement (c'est à dire, si on ne spécifie pas de
valeurs pour le
champ autogénéré). Noter qu'un champ généré
automatiquement N'IMPLIQUE PAS
qu'il ne produit pas de DOUBLONS. On peut, ainsi, avec
cette technique,
ajouter plusieurs enregistrements avec la valeur 1568, ou
1567 (avec le
INSERT INTO plus haut). Si on ne veut pas de doublons,
faut le préciser! en
plus!
Mais je maintiens que 1+Dmax est le chemin à suivre.
Espérant être utile,
Vanderghast, Access MVP
"Stach" wrote in
message
news:079e01c39939$edf35a40$
Bonjour,
en fait, cette manoeuvre a pour but d'exécuter un module
dans la base dorsale qui permet automatiquement d'importer
une table de la base dorsale contenant un champ NumeroAuto
que je veux incrémenter (et ne perdre aucun numéro dans ce
champ si par malheur je dois supprimer le dernier
enregistrement)puis exporter cette copie vers la base
dorsale afin qu'elle remplace l'ancienne table
J'ai bien essayé de faire tout ça à partir de la base
frontale en faisant un "import-export" de cette table,
puis en rétablissant les liens entre la dorsale et la
frontale, mais le problème est que lorsque je veux
supprimer l'ancienne table, access me crée des misère car
elle dépend de une ou plusieure relation.
si je savais exactement comment à partir de la base
Frontale:
1°) supprimmer les relations de la table "tblTEST" (champs
de relation "plusieur": [txt]) avec celle de la
table "tblTXT" (champs de relation "un": [txt] aussi)
(???)
2°) Importer "tblTEST" dans ma base frontale (OK)
3°) Exporter la copie de "tblTEST" vers la base Dorsale
(OK)
4°) Rétablir les relations dans la base Dorsale (???)
5°) Rétablir les liens entre Frontale et Dorsale (OK)
Cela me permettrai de ne plus jamais perdre de NumeroAuto
qui me servent de clé primaire dans la table.
On m'a bien conseiller d'utiliser "DMax()+1" mais ça ne
s'applique pas vu que ce genre de formule ne peux être
stocquée dans une table.
Grand merci de m'aider.
Stach ;-)
.
