Discussion :

[Access_ible]

Bonjour.

Ce dont j'ai besoin :
Enregistrer une fois, lors de la première utilisation de la base, en "dur", des valeurs pour pouvoir m'en resservir lors des utilisations suivantes de la base.

J'ai parcourus les réponses de ce forum proposées à ce sujet.
J'ai un temps utilisé une table pour stocker des paramètres.
Pour une bonne partie des autres, j'utilise Public Const.
J'ai retenu la possibilité de créer et de lire un fichier.ini que je range dans le même dossier que la base.

Ça fonctionne très bien.

Lors de l'ouverture de la base, le premier formulaire vérifie deux chose :
- L'existence du fichier.ini qu'il retrouve avec la fonction CurrentProject.Path,
- Le fait que ce fichier.ini comporte les informations propres à l'usager de la base

S'il existe, la base utilise les données qu'il contient
Sinon, Access le crée, toujours à l'endroit spécifié grâce à la fonction CurrentProject.Path.
Pour le créer, Access utilise une chaine de texte qui est recopiée dans un fichier.txt renommé en .ini, le tout, automatiquement.

Un des paramètres contenus dans le fichier.ini est le fait que les paramètres ont été renseignés, ou sont ceux de base issus de la chaine de texte : Ini_Is_Ok=OK, ou Ini_Is_Ok=KO
Une fois les paramètres renseignés, le paramètre Ini_Is_Ok est basculé à OK.
A la prochaine lecture, la base saura que les paramètres ont étés renseignés et que ce n'est pas la peine de les redemander.

Ensuite le formulaire passe une variable publique "Fichier_Ini_Path" à la valeur CurrentProject.Path & "\Fichier.ini".
Du coup, toute la base peut ensuite consulter le fichier.ini.

Le problème :
Au moindre plantage, la variable est vidée et le reste de la base ne retrouve plus le chemin du fichier.ini.

Ce que j'arrive à faire :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
Public FichierIniPath As String	'Variable publique stockée dans un module
FichierIniPath = CurrentProject.Path & "\ Fichier.ini"	'Attribution du chemin d'accès lors de l'ouverture de la base, et qui se vide en cas de plantage

Ce que je n'arrive pas à faire :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

Public Const FichierIniPath As String = CurrentProject.Path & "\Fichier.ini"

En toile de fond : utiliser un fichier externe à la base pour stocker des paramètres, c'est bien, mais il faut que la base puisse le retrouver…

Est-ce que j'ai loupé quelque chose ?

D'avance merci.

[marot_r]

Bonjour.

Quelle version d'Access utilises-tu ?

A+

[marot_r]

Une solution qui va marcher quelle que soit ta version :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
public function FichierIniPath() as string
   FichierIniPath = CurrentProject.Path & "\ Fichier.ini"
end function

A mettre dans un module.

A+

[Access_ible]

Mais c'est génial !!!!!

Pardon.

Bonjour.

C'est génial !!!!!

C'est super simple, super fin et ça marche nickel (bien entendu) et je n'ai même pas eu à modifier le code que j'avais déjà mis en place et qui faisait appel à cette constante.

en plus l'idée d'en faire une fonction permet potentiellement de passer des choses ultra alambiquées en constante...

Trop bien !

A oui, au fait, Access 2016.

Un immense Merci.

[marot_r]

Bonjour.

Avec Access 2016, tu peux utiliser la collection VarTemp qui sont des variables globales "statiques".
C-a-d qu'elles resistent aux plantages et autres aleas qui ne te font pas quitter l'application.
Une fois la valeur definie, elle reste la jusqu'a la sortie de l'application.
Attention il s'agit de variables pas de constantes donc leur valeur peut-etre modifiee par le code mais ca peut etre pratique.

Pour les fonctions utilisees comme des constantes, je m'en sers souvant dans mes requetes pour eviter les valeurs mysterieuses telle que =123.
Au lieu de cela je preferes avoir un truc du genre =CodeVenteSpeciale() et une function :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
public function CodeVenteSpeciale() as long
   CodeVenteSpeciale=123
End function

Ca rend les requetes plus comprenhensible moins sujet au erreur du type =132 au lieu de =123.

Attention, l'usage de function VBA dans une requete empeche Access de l'optimiser.
Cela peut avoir des consequences sur la performance mais a date cela ne m'a jamais poser de probleme.

A+

[Access_ible]

Bonjour.

Cette nouvelle donnée me permet de comprendre pourquoi on ne fait pas appel systématiquement à une fonction pour les constantes.

Je n'ai pas une énorme base et je n'ai qu'une constante problématique.

Je vais donc garder l'option de la fonction qui me plait bien.

Encore merci pour vos contributions.