Discussion :

[Access_ible]

Bonjour et bonne année à tous.

Alors voilà la petite histoire.

Comme je débute sous Access, j'ai tendance à créer des requêtes "en dur" avec l'assistant requête et ensuite à utiliser l'assistant création de formulaire pour créer un formulaire à partir de cette requête.

Alors pour l'exemple, prenons deux-trois tables : table 1, table 2, table 3.

Je crée une requête 1 en incluant les tables 1, 2 et 3.

Ensuite je crée un formulaire 1 basé sur la requête 1

A la fin, j'ai donc en dur trois tables, un requête et un formulaire.

Ce matin, dans un souci d'amélioration, j'ai essayé de supprimer la requête, et de recopier le contenu SQL de cette requête dans le champ Source de la feuille de propriété du formulaire, en lieu et place du nom de la requête 1 en l'occurrence.

ça marche. Je sais pas si c'est la bonne méthode, mais ça marche. Je n'ai plus que les tables d'origine et le formulaire.

Mais la méthode a ses limites. Quand j'ai essayé de recopier un gros bloc de texte SQL, dans ce champ Source, il m'a indiqué que le texte était trop long pour être modifié.

Je précise que j'ai essayé de recopier ce bloc de texte partout où j'ai pu voir Source dans le formulaire, dans les propriétés, dans les générateurs de code ou de requête.

A chaque fois, même problème. Des fois le texte est bien recopié, on peut enregistrer le formulaire, mais à la ré-ouverture, le texte SQL est tronqué et donc cause un erreur.

Je ne sais pas si ma façon de faire est la bonne, mais mes requêtes sont en général particulièrement complexes (champs renommés, valeurs en fonction d'un argument…) longue et le code SQL qui en découle est trop long pour rentrer dans la propriété Source.

La question est donc quel le nombre de caractères max. pour ce type de propriété ?

J'ai lu 16000 quelque part, mais moi ça coince à partir de 1000 et quelques. (1900, ce qui correspond au minimum de mes besoins, c'est trop long). Il ne semble pas avoir de limites dans la longuer du code SQL de la requête "en dur".

J'ai déjà réduit les nom des champs et de certaines tables, ce qui n'a pas été sans conséquence.

Si le nombre limite est inférieur à 1500 quel est la solution ?

Sinon, pourquoi cela ne fonctionne pas ?

D'avance merci.

[pier.antoine]

Bonjour.

Pourquoi vouloir absolument passer outre la requête?

Pierre

[Access_ible]

Bonjour.

Ben je sais pas, je pensais que c'était comme ça qu'il fallait faire.

La "jolie bases" (du moins celles qui m'apparessent comme des jolie bases) ne comportent que quelques requêtes en dur et quelques fonction.

Tout le reste est savament dissimulé dans le code et les propriété.

Par ailleurs, c'est le genre de truc sur lequel je peux passer des mois.

Pourquoi est ce que l'assitant requête semble ne pas avoir de limite de longueur de code SQL, tandis que l'assistant requête du formulaire est limité.

C'est la même présentation et tout et tout.

De plus, si on peut le faire avec un petit code SQL, on devrait pouvoir le faire avec un grand code...

Encore merci.

[Mr T 94]

Salut,
Le soucis,c'est qu'en faisant comme ça, si tu as la moindre chose à changer dans ta requête (tri ou condition ...) tu vas devoir tout modifier en SQL au lieu de te contenter d'ouvrir ta requête source et de cocher une simple case pour un tri , par exemple.

[Access_ible]

Bonjour.

C'est tout à fait vrai.

Comme en plus je modifie souvant les requêtes...

Cependant, auparavant quand je voulais créer une action à partir d'un bouton, je créait le bouton et je lui demandais de lancer soit une requête en dur, soit une macro lançant un certain nombre de requêtes en dur.

J'avis donc toutes les requêtes, toutes les macro etc...

Depuis, j'ai découvert VBA et la commande Run SQL et je n'utilise plus de requêtes en dur (sauf pour les requêtes imbriquées que je sais pas encore faire sous VBA (Dans ce denier cas, seule la dernière requête est en code, les autres sont en dur).

Je trouve que ça fait plus propre.

Bien sur, en cas de modif, il faut bourriner le code.

Mais il me semble bien que c'est la bonne façon de faire.

Alors je me disait que ça devait être pareil pour les Sources des formulaires.

De toutes façon, la propriété source d'un formulaire propose auddi un assistant requête identique à celui qui permet de créer des requêtes "en dur".

A l'exeption pres qu'elles ne peuvent pas êtres aussi longues.

D'où ma question, pourquoi, et comment résoudre le problème, évidement sans passer par une requête "en dur".

Encore merci.

[Mr T 94]

C'est toujours une bonne démarche (plus pro) de vouloir faire propre mais il ne faut pas que le remède soit pis que le mal.
S'il n'y a pas de nécessité absolue (problème de lenteur ou autre), il vaut mieux faire simple.
Moi, je fais carrément du quick and durty, c'est souvent très laid mais ça marche bien et avec la puissance des PC modernes, je n'ai pas de soucis (à moins d'avoir des millions d'enregistrements mais c'est plutôt rare).

[Arkham46]

Bjr,

La meilleur façon de faire (à mon goût) c'est :
1 - de bien nommer ses objets pour s'y retrouver
2 - d'écrire un dossier de spécifications techniques qui explique le rôle de chaque requête (et autres objets bien sûr)

Mettre des requêtes en dur dans le vba c'est très bien, mais il ne faut pas chercher à diminuer le nombre d'objets pour faire plus "propre", ce n'est qu'une illusion.

Si je dois créer une requête pour un formulaire FrmClient, j'appellerai ma requête ReqFrmClient.
Comme ça je sais que cette requête est dédiée au formulaire FrmClient.
En complément, on peut ajouter une description à la requête et afficher la fenêtre de base de données en mode "détail" avec la description au côté de chaque objet.

Et bien sûr ne pas négliger la documentation qui complète les cas où le nommage n'explique pas tout.

La qualité d'une base de données ne se mesure en aucun cas au nombre d'objets visibles dans la fenêtre de base de données.

[Access_ible]

Bonjour.

Et hahahaha

En fait l'ironie du sort, c'est que je vais peut être être amené à utiliser un même formulaire, mais présentant des données de sources très légèrement différentes.

Et l'une des solutions que j'ai envisagé, c'est de faire du VBA, pour indiquer comme source un ou une autre requête.

Mais du coup, je vais devoir les faires en dur.

Il n'empêche que si je devais renoncer à intégrer les requêtes dans les formulaires, j'aimerais quand même savoir, pour ma culture personnelle, comment intégrer des requêtes longues dans un fromulaire (ou savoir si c'est possible ou pas...)

Moi aussi, au début, je faisait des bases plutôt avancées, avec pas beaucoup de connaissances.
Du coup ça impressionnait les utilisateurs... Mais pas les concepteurs, parcequ'il y avait 30 requêtes, 15 tables et 15 macro.

C'est quand même super gratifiant de maitriser le code et d'avoir une présentation nickelle, jusque dans l'architecture.

PS : si en plus de savoir comment on peut baser un formulaire sur une longue requête, vous savez comment on peut demander au formulaire de s'ouvrir sur l'une ou sur l'autre (en code...) je suis preneur.

Merci.

[Arkham46]

Moi aussi, au début, je faisait des bases plutôt avancées, avec pas beaucoup de connaissances.
Du coup ça impressionnait les utilisateurs... Mais pas les concepteurs, parcequ'il y avait 30 requêtes, 15 tables et 15 macro.

Encore une fois le nombre d'objets n'est pas là pour impressionner.
Chaque objet à sa fonction, et ce n'est pas parce qu'une requête est cachée dans le code que c'est mieux.
Les concepteurs n'ont pas tous la même notion d'une application bien faite.

C'est quand même super gratifiant de maitriser le code et d'avoir une présentation nickelle, jusque dans l'architecture.

Je me répète mais qu'est ce qu'une bonne présentation? Tout caché dans le code, certainement pas.
N'oublions pas que les objets requêtes sont souvent plus rapides que le sql exécuté en vba (voir l'effet rushmore).

PS : si en plus de savoir comment on peut baser un formulaire sur une longue requête, vous savez comment on peut demander au formulaire de s'ouvrir sur l'une ou sur l'autre (en code...) je suis preneur.

Il faut abuser de la touche F1, par exemple sur la propriété "Source" du formulaire, on y trouve ce qu'il faut.

Chacun voit midi à sa porte, je ne fais que donner mon avis selon mon expérience.

[Access_ible]

Bonjour.

Je ne fais pas une course à la base parfaite.

C'est juste que depuis que j'utilise Access, et que je côtoies des personnes qui en créent et que je regarde l'organisation qu'ils adoptent, je suis admiratif devant la présentation des objets qu'ils arrivent à atteindre en intégrant au max le fonctionnement dans le code.

C'est vers ce résultat que je souhiater me diriger jusqu'à aujourd'hui.

Mais comme je l'ai indiqué plus haut, je vais peut-être être obligé de laisser les requête en dur pour faire un genre d'aiguillage.

Par ailleurs, toujours pour ma culture personnelle, et même si ce n'est pas obligatoirement la bonne façon de faire, j'aimerais quand même savoir quel est la limite de la propriété source d'un formulaire, et si elle peut être repoussée.

PS : j'avais déjà utilisé F1 pour l'idée du "commutateur" de sources. Mais ne sachant toujours pas quel politique adopter, je n'avais pas été convaincu. Je n'ai pas trouvé non plus d'infos sur le point principal de ma présente question, à savoir s'il existe une limite aux SQL utilisables dans les sources de formulaire.

Encore merci.

[Access_ible]

Bonjour.

Bon maintenant ce sont mes états qui sont ateinds par le mal de la limite SQL.

Personne ne voit comment augmenter la longueur tolérée ?

J'ai bien compris que le nombr d'objets, qu'il soit faible ou élevé, ne fait pas la qualité de la base.

Mais j'aimerais, soit dans le but de faire des modifs, soit dans un but d'enrichissement personnel, savoir quel est la limite de la ligne source dans un formulaire ou dans un état (nombre de caractères par exemple, si cette limite se quantifie en caractères...)

Et d'autre part savoir si cette limite se contourne, ou si c'est une limite absolue...

Encore merci.

[Access_ible]

Bonjour.

Je déleste ce message, ne sachant toujours pas quel est le nombre de caractères maximal de la propriété Source.

Merci de votre aide à tous.

[quarkup31]

J'ai rencontré la même difficulté. La création la requête en SQL se passe bien, avec sauvegarde dans la propriété source du form. J'ai pu faire des modifications avec le mode SQL. Puis je suis revenu plus tard (après fermeture et réouverture la BD l'apparence de la requete sql est tronquée, mais elle a fonctionné jusqu'à que je cherche à la modifier.!
Le contenu du champ source apparait tronqué au delà de 255 caractères.
Du coup j'ai créé une requete en "dur".