Le portail francophone de la géomatique

Et oui...MI ne tolère (et n'enregistre dans ses WOR) que des reqêtes de "premier niveau"
- soit on arrive à faire en une seule requête toutes les sélections dont on a besoin
- soit on enregistre et ouvre le résultat intermédiaire à exploiter
Mais quand les données sont dans Access, le mieux est de faire depuis Access une ou plusieurs requêtes (éventuellement "création de table") et d'en utiliser le résultat dans MI. Chacun son job: les SGBDR traitent la donnée alphanumérique et le logiciel SIG se spécialise dans la donnée graphique. C'est l'idéal théorique...

Premier niveau c'est l'obtention d'un premier résultat: select blabla from table1,table2 ...into resultat1
L'implication de ce résultat dans une seconde requête select blabla from tablex,resultat1...into resultat2 conduit second niveau
c'est à dire une requête qui implique une autre requête
D'où l'intérêt d'arriver direct à resultat2 en une seule requête
Je ne suis pas clair, je sais mais c'est tard

Bonjour,

Moi j'ai bien une requête de 1er niveau à formuler, toute simple en plus, et pourtant ça ne marche pas... je bosse sous MI 7.0 et  j'ai le même message d'erreur !

Je m'explique :

Je veux faire une requête spatiale du type "sélectionne moi les objets de la table A qui intersectent les objets de la table B".   
Je tape la formule dans selection SQL, soit : SELECT* FROM TableA, TableB WHERE TableA.Obj Intersect TableB.Obj

Et le programme me dit : "vous pouvez seulement établir des liens dynamiques de jointure sur des tables".
J'ai essayé 36 fois, en changeant l'ordre tes tables, en variant les opérateurs, en bricolant le contrôle des couches (pensant avoir oublié de rendre une table sélectionnable)..... Rien n'y fait !

Je ne travaille pas sur des requêtes spatiales d'habitude, en plus je ne suis pas hyper à l'aise avec les requêtes SQL, mais enfin là quand même... c'est pourtant pas compliqué ce que je veux faire !

Alors qu'est ce que j'ai oublié ?

Merci infiniment pour vos réponses... parce qu'en plus je suis pressé ! Je fais ça pour un collègue qui doit rendre un rapport  de toute urgence, alors si vous passez par là et que vous avez une solution, merci de nous aider  ;-)

Cordialement,

Merci pour cette astuce ; j'ai appliqué la requête en ces termes mais ça ne marche pas non plus.
Là encore j'ai essayé plusieurs combinaisons, sans succès...
Vous y comprenez quelque chose vous ?

Oui, ma TableA est effectivement issue d'une requête mais je ne pensais pas que le problème pouvait venir de là ?!?

Ok, j'ai extrait les zones cultivées de la table d'occupation du sol de 1999, ainsi que certaines communes à partir de Geofla, etc.

Mais puisque j'ai bien des objets graphiques associés à une table de données tout ce qu'il y a de plus simple, où est le problème ? Qu'est ce qui lui interdit de me faire un recoupement tout bête ?

Merci beaucoup !

Lorsque j'ai effectué mes requêtes, je les ai enregistrées sous forme de table histoire d'être tranquille dès le début. C'est pour ça que je n'imaginais pas qu'il puisse y avoir le moindre rapport avec mon message d'erreur...

Pour tout vous dire, et pour être définitivement clair, j'ai principalement 3 éléments :

- 1 table "SMAEMV" (issue de la BD Geofla et qui correspond aux communes appartenant au syndicat mixte du coin)
- 1 table "sup_diversagri" (extraite de la BD occupation du sol et qui ne fait apparaître que les zones cultivées)
- 3 tables "classe_xyz" (extraites d'une BD sur les aptitudes agronomiques du sol")

Bien qu'issues de requêtes de 1er niveau, il s'agit bien de couches "indépendantes" désormais. Aussi je ne comprend pas votre dernier conseil au sujet de la dénomination "Table", même "sous la forme TableA"...

Merci !

Tout simple...une fois reçu les tables "fautives" par mail !!
Votre table "sup_diversagri" n'est pas une vraie table: c'est une table requête....!!
C'est une table constituée d'un sup_diversagri.TAB et d'un sup_diversagri.QRY qui, pour s'ouvrir et "exister", nécessite la présence d'une table référence (occsol) qu'elle questionne (au fait, changez les noms: des mif dans un nom de table ou de mif/mid...lourd!)
En fait vous avez fait "Enregistrer requête" alors qu'il faut faire "Enregistrer table sous..." et choisir selection ou Queryn pour avoir réellement un résultat de requête enregistré en dur en tant que table normale

Il suffit maintenant de faire "Enregistrer table sous..." et de choisir votre table requête pour obtenir une vraie table...que vous pourrez, elle, facilement intégrer à votre "fameuse" requête
Désolé de ne pas y avoir pensé plus tôt

Bonjour à toutes et tous

Pour apporter ma petite pierre au pb des requetes sous MI (et ce quelque soit la version).

Effectivement la jointure entre deux tables dont une au moins est déjà une table requete n'est pas possible. C'est le probleme soulevé dans ce post. Dans la terminologie MI une jointure se traduit par un select * from TableA,Table2 where.... .

En revanche la requete proposée par Maurice : SELECT * FROM TableA WHERE obj intersects any (select obj from TableB)
fonctionne quelque soit la nature des tables A et B donc TableA et TableB peuvent être des tables requetes issues d'une première sélection.

Attention toutefois lorsque l'on fait des requetes sur des tables requetes pour obtenir un nouvelle table requete MapInfo est incapable de sauvegarder dans un document WOR ce second ou nième niveau de requete.  Donc ce travail ne peut être sauvegardé directement sous Mapinfo.

Pour ma part j'ai "solutionné" le pb en créant des documents MI (xxx.wor) que je complète avec un éditeur de textes en associant la fenêtre MapBasic dans la session MI. Ainsi pour chaque requete faite, je la copie de ma fenêtre MapBasic pour la coller dans mon Wor.
Lorsque je réouvre mon document ainsi modifié à la mano tout s'ouvre correctement. Attention alors de ne pas enregistrer de nouveau ce document sous MI car toutes les requetes de deuxieme niveau et plus seront perdues. Et alors plantage si vous voulez ouvrir plus tard votre document car la table issue d'une selection de second niveau est perdue et la lecture du WOR plante.

Pour Prévenir ce genre de pb j'ai complété mon WOR de ces quelques lignes.

note "cette partie est ajouté sous editeur de texte"
run program "uedit32 etude_dia_BAYCA_par_section_20080408.wor"
Add Column "SECTIONS_BAY" (Nb_DIA Integer)From DIA_util Set To Count(*) Where within Dynamic
Add Column "SECTIONS_BAY" (Nb_DIA_Habitation_nonexclue Integer)From DIA_Habitation_nonexclue Set To Count(*) Where within Dynamic
Add Column "SECTIONS_BAY" (Nb_DIA_Habitation Integer)From DIA_Habitation Set To Count(*) Where within Dynamic
Add Column "SECTIONS_BAY" (Nb_DIA_commerce Integer)From DIA_commerce Set To Count(*) Where within Dynamic
Add Column "SECTIONS_BAY" (Nb_DIA_mixte Integer)From DIA_mixte Set To Count(*) Where within Dynamic
Add Column "SECTIONS_BAY" (Nb_DIA_terrain Integer)From DIA_terrain Set To Count(*) Where within Dynamic
note "ne pas enregistrer le WOR avec Mapinfo avec le meme nom sinon ces six lignes sont perdues"

J'ai alors un Warning (note) sur le WOR puis le lancement de mon editeur de texte préféré avec le WOR en question puis un second Warning (note) qui m'averti de ne pas enregistrer sans précaution ce document.

Les Add Column sont un exemple de ce que l'on peut faire (Sections_BAY est le résultat d'une requète et les DIA_*** aussi).

Bon traitement et bonnes requètes.

JP LARTIGAU