Discussion :

[tibjedi]

Non justement je suis toujours bloqué... mais c'est lorsque je fais ça que le message s'en va.

Après, si je relance la base, ça replante ....

Ce que j'ai du mal à comprendre, c'est que la base (et donc ces requêtes pour remmetre à 0 l'ID) fonctionne parfaitement sur mon PC, mais sur les Pc des collègues ça sort la même erreur lors du second lancement.

Merci Access

[loufab]

Tu lances ce process sur une base partagée ?

[tibjedi]

Disons que je copie ma base (l'originale) sur un répertoire partagé que chacun pose sur son C: .

Dans les options je l'ai mise en exclusive

[loufab]

En effet tu peux remercier ACCESS d'être aussi indulgent.

[tibjedi]

Oui mais il pourrait l'être jusqu'au bout !

finalement j'ai réussi à contourner mon problème... (via le compactage)

[loufab]

Oui mais il pourrait l'être jusqu'au bout !

En effet il pourrait même créer l'application à ta place.

finalement j'ai réussi à contourner mon problème... (via le compactage)

Tu lis les docs des fois ? F1 sur NumeroAuto par exemple.

J'espère qu'elle est compatible ShiftSuppr ton appli. Il me semble que c'est la première chose qu'on va lui demander.

[Pierre Fauconnier]

Salut.

Perso, j'attends toujours que l'on m'explique l'utilité de ne pas commencer un numauto à 1...

Pour ce qui est de modifier "à chaud" sur des tables "partagées", je n'ai même pas de mots...

[tibjedi]

J'ai du mal m'exprimer : les tables concernés ne sont pas partagées puisqu'elle sont directement dans la base Access, et qu'un seul utilisateur à la fois utilise la base.


Pour en revenir à l'utilité, je travail dans la logistique où j'ai des pièces dans différents type de palette, de différentes morphologie et de différentes "classes".
J'ai crée un outil permettant de simuler l'entrepot "parfait", et pour cela je dois effectuer des calcul basé sur des sélection d'articles qui ont les meilleures activités, les meilleures ventes. Une vingtaine de fois dans le traitement, je dois récupéré les 40 premiers articles parmis 1000 articles. Sans requêtes de remise à zero, j'ai rapidement un numeroAuto qui grimpe à 20000 lors d'un seul traitement. La solution que j'avais trouvé était de lancer après chaque traitement d'article une requete pour remettre le compteur à zero.


Loufab : euh yavais de l'humour dans ma dernière phrase...
Le traitement ne pouvant s'effectuer qu'une fois dans la journée, lors de la fermeture de la base tout se remet à zero. Enfin tu me demande de lire l'aide microsoft, oui je l'avais vu, mais je cherchais dans un premier temps à ne pas passer par la méthode du compactage. Je te rassure quand je pose des questions je regarde toujours les aides/numero d'erreurs....

[Pierre Fauconnier]

Si tu utilises une table temporaire, ton NumAuto va effectivement monter. Mais tu peux aller jusqu'à +/- 2.000.000.000 avec un entier long, donc, tu as de la marge.

Si sur un seul traitement, tu montes jusqu'à 20.000 lignes dans une table temporaire, alors, l'option de compacter la base en fermant me semble la seule solution pour que ta base Access ne prenne pas très vite du poids "pour rien" puisque lors d'une suppression d'enregistrement, Access ne fait que supprimer "logiquement" l'information, et non physiquement. Autrement dit, ta base ressemble vite à du gruyère, et seul le compactage va résoudre le problème...

[tibjedi]

Oui, à vrai dire moi je craignais pas trop la taille de l'ID, mais plutôt mes chefs...

Du coup le compactage réponds à mon besoin et permet de garder une taille raisonnable
Merci

[loufab]

Bonjour,

Par définition un ID doit rester une donnée interne à l'application, donc l'utilisateur n'est pas censé le voir et encore moins tes 'chefs'.

Maintenant si ça te plait de d'utiliser cette pure hérésie, libre à toi.

Cordialement,