Bonjour,
J'ai développé une application sous Acces sous Jet. Je suis en train de la
migrer sous SQL. Je rencontre un comportement étrange. Les champs de la base
n'ont aucune valeur par défaut, sauf l'ID. En ayant un champ de type unique
identifier, Acces initialise le control lié avec une valeur alors que le
controle n'a pas de valeur par defaut ... c'est génant pour faire des tests
avant l'enregistrement du formulaire car le controle a toujours une valeur!
Dans le meme registre, en ayant un formulaire en mode continu, qui ne
presente que les lignes et dans le pied de formulaire le detail. Si les
controles dans les lignes possedent comme source le controle du pied de page,
alors lorsqu'un nouvel enregistrement est selectionné et que l'on fait une
entrée dans un controle, alors l'evenement du formulaire "AfterUpdate" est
déclenché.
Quelqu'un a-t-il rencontré ces problèmes ... que je n'ai pas réussi à
contourner sans une usine a gaz.
Merci
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire
Veuillez sélectionner un problème
Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
Charles ERNST
Faut se méfier, si on dédouble un champ de table dans un formulaire access en mode ADP on peut avoir des problèmes. Dans les états c'est flagrant, si on veut faire plusieurs fois un regroupement sur un même champ. Il faut alors dédoubler le champ dans la vue ou la procédure sous-jacente. Bref, 1 champ = 1 contrôle. Si vous le voulez plusieurs fois, il faut le dédoubler dans la vue sous-jacente et lui donner un autre nom
"Belu33fr" a écrit dans le message de news:
Bonjour, J'ai développé une application sous Acces sous Jet. Je suis en train de la migrer sous SQL. Je rencontre un comportement étrange. Les champs de la base n'ont aucune valeur par défaut, sauf l'ID. En ayant un champ de type unique identifier, Acces initialise le control lié avec une valeur alors que le controle n'a pas de valeur par defaut ... c'est génant pour faire des tests avant l'enregistrement du formulaire car le controle a toujours une valeur! Dans le meme registre, en ayant un formulaire en mode continu, qui ne presente que les lignes et dans le pied de formulaire le detail. Si les controles dans les lignes possedent comme source le controle du pied de page, alors lorsqu'un nouvel enregistrement est selectionné et que l'on fait une entrée dans un controle, alors l'evenement du formulaire "AfterUpdate" est déclenché. Quelqu'un a-t-il rencontré ces problèmes ... que je n'ai pas réussi à contourner sans une usine a gaz. Merci
Faut se méfier, si on dédouble un champ de table dans un formulaire access
en mode ADP on peut avoir des problèmes. Dans les états c'est flagrant, si
on veut faire plusieurs fois un regroupement sur un même champ. Il faut
alors dédoubler le champ dans la vue ou la procédure sous-jacente.
Bref, 1 champ = 1 contrôle. Si vous le voulez plusieurs fois, il faut le
dédoubler dans la vue sous-jacente et lui donner un autre nom
"Belu33fr" <Belu33fr@discussions.microsoft.com> a écrit dans le message de
news: 765ED367-7763-4F11-9F00-CEEB73F686B0@microsoft.com...
Bonjour,
J'ai développé une application sous Acces sous Jet. Je suis en train de la
migrer sous SQL. Je rencontre un comportement étrange. Les champs de la
base
n'ont aucune valeur par défaut, sauf l'ID. En ayant un champ de type
unique
identifier, Acces initialise le control lié avec une valeur alors que le
controle n'a pas de valeur par defaut ... c'est génant pour faire des
tests
avant l'enregistrement du formulaire car le controle a toujours une
valeur!
Dans le meme registre, en ayant un formulaire en mode continu, qui ne
presente que les lignes et dans le pied de formulaire le detail. Si les
controles dans les lignes possedent comme source le controle du pied de
page,
alors lorsqu'un nouvel enregistrement est selectionné et que l'on fait une
entrée dans un controle, alors l'evenement du formulaire "AfterUpdate" est
déclenché.
Quelqu'un a-t-il rencontré ces problèmes ... que je n'ai pas réussi à
contourner sans une usine a gaz.
Merci
Faut se méfier, si on dédouble un champ de table dans un formulaire access en mode ADP on peut avoir des problèmes. Dans les états c'est flagrant, si on veut faire plusieurs fois un regroupement sur un même champ. Il faut alors dédoubler le champ dans la vue ou la procédure sous-jacente. Bref, 1 champ = 1 contrôle. Si vous le voulez plusieurs fois, il faut le dédoubler dans la vue sous-jacente et lui donner un autre nom
"Belu33fr" a écrit dans le message de news:
Bonjour, J'ai développé une application sous Acces sous Jet. Je suis en train de la migrer sous SQL. Je rencontre un comportement étrange. Les champs de la base n'ont aucune valeur par défaut, sauf l'ID. En ayant un champ de type unique identifier, Acces initialise le control lié avec une valeur alors que le controle n'a pas de valeur par defaut ... c'est génant pour faire des tests avant l'enregistrement du formulaire car le controle a toujours une valeur! Dans le meme registre, en ayant un formulaire en mode continu, qui ne presente que les lignes et dans le pied de formulaire le detail. Si les controles dans les lignes possedent comme source le controle du pied de page, alors lorsqu'un nouvel enregistrement est selectionné et que l'on fait une entrée dans un controle, alors l'evenement du formulaire "AfterUpdate" est déclenché. Quelqu'un a-t-il rencontré ces problèmes ... que je n'ai pas réussi à contourner sans une usine a gaz. Merci
Lucky Luke Skywalker
Merci pour l'info ... je vais aborder le problème avec cette précision
--
Lucky Luke Skywalker
-------------------------------------------------------------------------- La cloche est celle qui raisone: ne me tapez pas trop fort dessus -------------------------------------------------------------------------- Association Des Utilisateurs Cable Adsl Bordelais : http://www.aducab.org Le forum de Bordeaux : news:alt.cable.wanadoo.bordeaux Email: luckyluke at aducab.org
"Charles ERNST" a écrit dans le message de news:
Faut se méfier, si on dédouble un champ de table dans un formulaire access en mode ADP on peut avoir des problèmes. Dans les états c'est flagrant, si on veut faire plusieurs fois un regroupement sur un même champ. Il faut alors dédoubler le champ dans la vue ou la procédure sous-jacente. Bref, 1 champ = 1 contrôle. Si vous le voulez plusieurs fois, il faut le dédoubler dans la vue sous-jacente et lui donner un autre nom
"Belu33fr" a écrit dans le message de news:
Bonjour, J'ai développé une application sous Acces sous Jet. Je suis en train de la migrer sous SQL. Je rencontre un comportement étrange. Les champs de la base n'ont aucune valeur par défaut, sauf l'ID. En ayant un champ de type unique identifier, Acces initialise le control lié avec une valeur alors que le controle n'a pas de valeur par defaut ... c'est génant pour faire des tests avant l'enregistrement du formulaire car le controle a toujours une valeur! Dans le meme registre, en ayant un formulaire en mode continu, qui ne presente que les lignes et dans le pied de formulaire le detail. Si les controles dans les lignes possedent comme source le controle du pied de page, alors lorsqu'un nouvel enregistrement est selectionné et que l'on fait une entrée dans un controle, alors l'evenement du formulaire "AfterUpdate" est déclenché. Quelqu'un a-t-il rencontré ces problèmes ... que je n'ai pas réussi à contourner sans une usine a gaz. Merci
Merci pour l'info ... je vais aborder le problème avec cette précision
--
Lucky Luke Skywalker
--------------------------------------------------------------------------
La cloche est celle qui raisone: ne me tapez pas trop fort dessus
--------------------------------------------------------------------------
Association Des Utilisateurs Cable Adsl Bordelais : http://www.aducab.org
Le forum de Bordeaux : news:alt.cable.wanadoo.bordeaux
Email: luckyluke at aducab.org
"Charles ERNST" <contact@micro-gestion.fr> a écrit dans le message de news:
u8DKRFuuFHA.2880@TK2MSFTNGP12.phx.gbl...
Faut se méfier, si on dédouble un champ de table dans un formulaire access
en mode ADP on peut avoir des problèmes. Dans les états c'est flagrant, si
on veut faire plusieurs fois un regroupement sur un même champ. Il faut
alors dédoubler le champ dans la vue ou la procédure sous-jacente.
Bref, 1 champ = 1 contrôle. Si vous le voulez plusieurs fois, il faut le
dédoubler dans la vue sous-jacente et lui donner un autre nom
"Belu33fr" <Belu33fr@discussions.microsoft.com> a écrit dans le message de
news: 765ED367-7763-4F11-9F00-CEEB73F686B0@microsoft.com...
Bonjour,
J'ai développé une application sous Acces sous Jet. Je suis en train de
la
migrer sous SQL. Je rencontre un comportement étrange. Les champs de la
base
n'ont aucune valeur par défaut, sauf l'ID. En ayant un champ de type
unique
identifier, Acces initialise le control lié avec une valeur alors que le
controle n'a pas de valeur par defaut ... c'est génant pour faire des
tests
avant l'enregistrement du formulaire car le controle a toujours une
valeur!
Dans le meme registre, en ayant un formulaire en mode continu, qui ne
presente que les lignes et dans le pied de formulaire le detail. Si les
controles dans les lignes possedent comme source le controle du pied de
page,
alors lorsqu'un nouvel enregistrement est selectionné et que l'on fait
une
entrée dans un controle, alors l'evenement du formulaire "AfterUpdate"
est
déclenché.
Quelqu'un a-t-il rencontré ces problèmes ... que je n'ai pas réussi à
contourner sans une usine a gaz.
Merci
Merci pour l'info ... je vais aborder le problème avec cette précision
--
Lucky Luke Skywalker
-------------------------------------------------------------------------- La cloche est celle qui raisone: ne me tapez pas trop fort dessus -------------------------------------------------------------------------- Association Des Utilisateurs Cable Adsl Bordelais : http://www.aducab.org Le forum de Bordeaux : news:alt.cable.wanadoo.bordeaux Email: luckyluke at aducab.org
"Charles ERNST" a écrit dans le message de news:
Faut se méfier, si on dédouble un champ de table dans un formulaire access en mode ADP on peut avoir des problèmes. Dans les états c'est flagrant, si on veut faire plusieurs fois un regroupement sur un même champ. Il faut alors dédoubler le champ dans la vue ou la procédure sous-jacente. Bref, 1 champ = 1 contrôle. Si vous le voulez plusieurs fois, il faut le dédoubler dans la vue sous-jacente et lui donner un autre nom
"Belu33fr" a écrit dans le message de news:
Bonjour, J'ai développé une application sous Acces sous Jet. Je suis en train de la migrer sous SQL. Je rencontre un comportement étrange. Les champs de la base n'ont aucune valeur par défaut, sauf l'ID. En ayant un champ de type unique identifier, Acces initialise le control lié avec une valeur alors que le controle n'a pas de valeur par defaut ... c'est génant pour faire des tests avant l'enregistrement du formulaire car le controle a toujours une valeur! Dans le meme registre, en ayant un formulaire en mode continu, qui ne presente que les lignes et dans le pied de formulaire le detail. Si les controles dans les lignes possedent comme source le controle du pied de page, alors lorsqu'un nouvel enregistrement est selectionné et que l'on fait une entrée dans un controle, alors l'evenement du formulaire "AfterUpdate" est déclenché. Quelqu'un a-t-il rencontré ces problèmes ... que je n'ai pas réussi à contourner sans une usine a gaz. Merci
Belu33fr
Bonjour, Désolé, mais la piste n'est pas la bonne ... les problèmes persistent. Il semble que la présence des GUID sont à l'origine du comportement ... car en leur présence, le simple fait de frapper une touche au clavier déclenche un "AfterUpdate" au niveau du formulaire, avec ou sans valeur par défaut. Ce qui est étonnant (oui et non d'ailleurs) c'est que le "BeforeUpdate" et le "AfterUpdate" du controle ne sont pas déclenchés. Ce n'est pas étonnant car le focus est toujours sur le contrôle.
Merci pour l'info ... je vais aborder le problème avec cette précision
--
Lucky Luke Skywalker
-------------------------------------------------------------------------- La cloche est celle qui raisone: ne me tapez pas trop fort dessus -------------------------------------------------------------------------- Association Des Utilisateurs Cable Adsl Bordelais : http://www.aducab.org Le forum de Bordeaux : news:alt.cable.wanadoo.bordeaux Email: luckyluke at aducab.org
"Charles ERNST" a écrit dans le message de news:
Faut se méfier, si on dédouble un champ de table dans un formulaire access en mode ADP on peut avoir des problèmes. Dans les états c'est flagrant, si on veut faire plusieurs fois un regroupement sur un même champ. Il faut alors dédoubler le champ dans la vue ou la procédure sous-jacente. Bref, 1 champ = 1 contrôle. Si vous le voulez plusieurs fois, il faut le dédoubler dans la vue sous-jacente et lui donner un autre nom
"Belu33fr" a écrit dans le message de news:
Bonjour, J'ai développé une application sous Acces sous Jet. Je suis en train de la migrer sous SQL. Je rencontre un comportement étrange. Les champs de la base n'ont aucune valeur par défaut, sauf l'ID. En ayant un champ de type unique identifier, Acces initialise le control lié avec une valeur alors que le controle n'a pas de valeur par defaut ... c'est génant pour faire des tests avant l'enregistrement du formulaire car le controle a toujours une valeur! Dans le meme registre, en ayant un formulaire en mode continu, qui ne presente que les lignes et dans le pied de formulaire le detail. Si les controles dans les lignes possedent comme source le controle du pied de page, alors lorsqu'un nouvel enregistrement est selectionné et que l'on fait une entrée dans un controle, alors l'evenement du formulaire "AfterUpdate" est déclenché. Quelqu'un a-t-il rencontré ces problèmes ... que je n'ai pas réussi à contourner sans une usine a gaz. Merci
Bonjour,
Désolé, mais la piste n'est pas la bonne ... les problèmes persistent. Il
semble que la présence des GUID sont à l'origine du comportement ... car en
leur présence, le simple fait de frapper une touche au clavier déclenche un
"AfterUpdate" au niveau du formulaire, avec ou sans valeur par défaut. Ce qui
est étonnant (oui et non d'ailleurs) c'est que le "BeforeUpdate" et le
"AfterUpdate" du controle ne sont pas déclenchés. Ce n'est pas étonnant car
le focus est toujours sur le contrôle.
Merci pour l'info ... je vais aborder le problème avec cette précision
--
Lucky Luke Skywalker
--------------------------------------------------------------------------
La cloche est celle qui raisone: ne me tapez pas trop fort dessus
--------------------------------------------------------------------------
Association Des Utilisateurs Cable Adsl Bordelais : http://www.aducab.org
Le forum de Bordeaux : news:alt.cable.wanadoo.bordeaux
Email: luckyluke at aducab.org
"Charles ERNST" <contact@micro-gestion.fr> a écrit dans le message de news:
u8DKRFuuFHA.2880@TK2MSFTNGP12.phx.gbl...
Faut se méfier, si on dédouble un champ de table dans un formulaire access
en mode ADP on peut avoir des problèmes. Dans les états c'est flagrant, si
on veut faire plusieurs fois un regroupement sur un même champ. Il faut
alors dédoubler le champ dans la vue ou la procédure sous-jacente.
Bref, 1 champ = 1 contrôle. Si vous le voulez plusieurs fois, il faut le
dédoubler dans la vue sous-jacente et lui donner un autre nom
"Belu33fr" <Belu33fr@discussions.microsoft.com> a écrit dans le message de
news: 765ED367-7763-4F11-9F00-CEEB73F686B0@microsoft.com...
Bonjour,
J'ai développé une application sous Acces sous Jet. Je suis en train de
la
migrer sous SQL. Je rencontre un comportement étrange. Les champs de la
base
n'ont aucune valeur par défaut, sauf l'ID. En ayant un champ de type
unique
identifier, Acces initialise le control lié avec une valeur alors que le
controle n'a pas de valeur par defaut ... c'est génant pour faire des
tests
avant l'enregistrement du formulaire car le controle a toujours une
valeur!
Dans le meme registre, en ayant un formulaire en mode continu, qui ne
presente que les lignes et dans le pied de formulaire le detail. Si les
controles dans les lignes possedent comme source le controle du pied de
page,
alors lorsqu'un nouvel enregistrement est selectionné et que l'on fait
une
entrée dans un controle, alors l'evenement du formulaire "AfterUpdate"
est
déclenché.
Quelqu'un a-t-il rencontré ces problèmes ... que je n'ai pas réussi à
contourner sans une usine a gaz.
Merci
Bonjour, Désolé, mais la piste n'est pas la bonne ... les problèmes persistent. Il semble que la présence des GUID sont à l'origine du comportement ... car en leur présence, le simple fait de frapper une touche au clavier déclenche un "AfterUpdate" au niveau du formulaire, avec ou sans valeur par défaut. Ce qui est étonnant (oui et non d'ailleurs) c'est que le "BeforeUpdate" et le "AfterUpdate" du controle ne sont pas déclenchés. Ce n'est pas étonnant car le focus est toujours sur le contrôle.
Merci pour l'info ... je vais aborder le problème avec cette précision
--
Lucky Luke Skywalker
-------------------------------------------------------------------------- La cloche est celle qui raisone: ne me tapez pas trop fort dessus -------------------------------------------------------------------------- Association Des Utilisateurs Cable Adsl Bordelais : http://www.aducab.org Le forum de Bordeaux : news:alt.cable.wanadoo.bordeaux Email: luckyluke at aducab.org
"Charles ERNST" a écrit dans le message de news:
Faut se méfier, si on dédouble un champ de table dans un formulaire access en mode ADP on peut avoir des problèmes. Dans les états c'est flagrant, si on veut faire plusieurs fois un regroupement sur un même champ. Il faut alors dédoubler le champ dans la vue ou la procédure sous-jacente. Bref, 1 champ = 1 contrôle. Si vous le voulez plusieurs fois, il faut le dédoubler dans la vue sous-jacente et lui donner un autre nom
"Belu33fr" a écrit dans le message de news:
Bonjour, J'ai développé une application sous Acces sous Jet. Je suis en train de la migrer sous SQL. Je rencontre un comportement étrange. Les champs de la base n'ont aucune valeur par défaut, sauf l'ID. En ayant un champ de type unique identifier, Acces initialise le control lié avec une valeur alors que le controle n'a pas de valeur par defaut ... c'est génant pour faire des tests avant l'enregistrement du formulaire car le controle a toujours une valeur! Dans le meme registre, en ayant un formulaire en mode continu, qui ne presente que les lignes et dans le pied de formulaire le detail. Si les controles dans les lignes possedent comme source le controle du pied de page, alors lorsqu'un nouvel enregistrement est selectionné et que l'on fait une entrée dans un controle, alors l'evenement du formulaire "AfterUpdate" est déclenché. Quelqu'un a-t-il rencontré ces problèmes ... que je n'ai pas réussi à contourner sans une usine a gaz. Merci
