Modifier le type de donné d'une table liée

[ZoomBox]

Bonjour,

Je recontre un problème dans le projet que j'ai pour mon stage:
Je travaille avec une table liée qui vient de ODBC je crois, et j'utilise un des champs qui est de type Mémo pour une requête imbriqué. Seulement, Access me refuse les opération complexe sur ce champs (je peux comprendre, ils ne sont pas fait pour ça).

Le truc c'est que aucun des mes enregistrements ne contient de donnée > 255 caractères donc une jointure/requête imbriqué devrait être parfaitement faisable.

Pour l'instant, j'utilise une copie de la table que je fait au lancement du programme et dans laquelle je modifie les types de Mémo vers Text. Ca marche mais c'est TRÈS TRÈS long étant donné que la table lié comporte énormément de lignes.

Ma question: Est-il possible de trouver une alternative plus rapide que la copie de la table puis aleration pour pouvoir modifier le type d'un champ et ainsi pouvoir faire ma requête ?

Plusieurs piste:
-Modifier le type du champs pendant la liaison (une sorte de "ALTER ... Text" à mettre dans les propriété de la liaison.
-Modifier le type de donné APRÈS chaque envoie de donnée de la liaison (apparemment infaisable)
-Pouvoir dire à ma requête que je ne souhaite garder que les 255 premier caractère de mon champ et le convertir en Text (ou tout autre format compatible). Un peut comme le fait le CDate() pour les dates ou le FORMAT()

Merci d'avance pour les réponses, je ne vois vraiment pas comment faire, c'est très génant.

[dumas.blr]

Bonjour Zoombox,

En général, il n'est pas possible de modifier directement la structure d'une table liée. Ne t'aventure donc pas sur cette voie.

La recopie en local de la table est intéressante car elle laisse plus le latitude pour forcer la structure d'une colonne. Inconvénient : il y a un risque de déphasage entre les données sources et les données répliquée, car tu dois gérer toi-même la synchronisation des données.

Te te propose une solution alternative : utiliser les requêtes Access, qui fonctionnent un peu comme des vues, mais en plus performant, car tu peu ensuite utiliser ces requêtes conne source d'un nouvelle requête, et chaîner ainsi les traitements.

La première requête à développer effectuera la mise au format de ta table liée.
Pour cela, tu peux utiliser les fonctions de conversion comme Cstr
Ensuite, tu crée une seconde requête pour faire ta jointure.
ex :
requête1 :

Code :

select Cstr(<mon champ mémo>) as mon_champ_string from <ma_table_liee> where ...

requête2

Code :

1
2
select requête1.mon_champ_string, ... table1.champ1, ... 
from requête1, table1 where requête1.mon_champ_string = table1.champx AND ...

[ZoomBox]

OK, merci bien pour ces infos. Pour le déphasages, y'a pas vraiment de soucis, mon appli se base sur des select et n'envoie aucune donnée donc, au pire, l'utilisateur aura des donné par forcément à jour ce qui n'est pas tellement un soucis.
Le problème vient vraiment du fait que ma table est très lourdre à importer et ça aura été très beau de pouvoir convertir les données dans la liaison sans intervention directe de ma part.

Ta solution me semble très correcte, je vais essayer pour voir les performances qu'elle donne.

Edit: Petit problème tout de même, les colonnes sont renommées en "Exp***" et je ne peut pas leur donner l'alias de leur nom original ce qui risque de modifier pas mal de mes requêtes

[ZoomBox]

Bon en fait, niveau perf', c'est du pareil au même... mais l'idée est bonne (si on a l'intention d'avoir constamment les données les plus fraiches en contrepartie des performance.
L'avantage c'est aussi le poids du programme, qui devrait se voir réduit sans table temporaire contenant les données (quoi que, si ce n'était que ça, il suffirait que je vide ma table tempo à chaque fermeture du formulaire).

J'aurais bien aimer quand même pouvoir modifier directement le format de reception des données, ça aurait été très pratique.

Bon, pas vraiment résolu mon problème mais merci !
Bonne journée.

[dumas.blr]

Dans une requête, tu peux tout à fait redonner le nom original de ta colonne

ex :

Code :

select chr$(ma_colonne) as ma_colonne ...

Marche très bien

[ZoomBox]

Etrange que ça marche chez toi, moi Access (2003) me crie qu'il y a une référence circulaire !

[dumas.blr]

Atention tout de même concernant la taille de la base. Elle risque d'augmenter dans le mêmes proportions que si tu avait créé une table. En effet, les requêtes crééent des tables temporaires qui ne sont pas forcément purgées physiquement.
La base risquant de se désorganiser rapidement, il faudra penser à effectuer une opération de compactage au moment de la fermeture.

Access n'étant pas forcément adaptée à de gros volumes de données, y a t'il une possibilité d'intervenir sur la base source avant connexion ODBC ?

Quelle est la volumétrie de la table incriminée ?

[ZoomBox]

Oui c'est exact. Mais de toute façon j'utilise ma première solution avec les tables temporaires.
Ceci dit jen e comprend pas pourquoi les bases risque de se désorganisé, mon application est uniquement une application "liseuse", càd que je ne modifie absolument jamais les données qui s'y trouvent, je ne fais que les recevoir et afficher telle ou telle chose.

Et je ne comprend pas vraiment ta dernière question, je sais qu'il y a une 15ène de champs pour à peu près 15.000 enregistrement si c'est ce que tu veux savoir!

Le top serait de pouvoir faire une conversion invisible, directement en changeant un paramètre dans la liaison pour dire "Attention, ce champ là, je le veux en Text !" mais si tu dis que c'est impossible...

Merci de ton aide en tout cas, c'est fort aimable, bonne journée !

[dumas.blr]

15000 enregistrements, c'est tout à fait gérable !

Bon en fait, niveau perf', c'est du pareil au même...

As-tu fait uniquement la requête de conversion, sans clause WHERE ?
Quel durée as-tu obtenu ?

[Chtulus]

Bonjour,

Une petite remarque entre parenthèse, si vous ne faites que consulter, pourquoi ne pas attaquer directement la source ?

[ZoomBox]

@dumas: Si je ne fais que SELECT cstr(ChampA), cstr(Champ2) etc... ça ne prend pas bien longtemps, mais je crois qu'Access me farce et calcule les enregistrements affichés quand je scroll la page donc ce n'est pas représentatif étant donné que mon opération se fait dans une clause WHERE Champs1 =(SELECT...) et qu'il faut donc tout parcourir d'un coup.

@Chtulus: Je n'ai pas vraiment compris le "attaquer", mais je n'ai pas de droit d'alteration de la table, je ne peux que la lire.

Merci de votre attention à tous les deux.

Edit: Au fait, j'ai fait un count pour vérifié, c'est 30.000 enreistrement qu'il y a en réalité dans la table.

[dumas.blr]

Peux tu nous communiquer le SQL de ta requête d'import ?

[ZoomBox]

Il n'y a pas d'Import de table, j'ai une table liée (automatiquement, via les menu Access) et je la copie dans une table temporaire via un select *.
La table temporaire à la même structure que la table lié, les mêmes données, sauf que j'ai remplacé le format des champs qui sont normalement Memo par Text...

[dumas.blr]

Alors je te propose la solution que je t'avais recommandée au début :
1er passage : tu construit une requête à partir de ta table liée (requête création de table)

Code :

 SELECT cstr(ChampA), cstr(Champ2) from <ma_table_liee>  INTO <ma_table_temporaire>

ET C'EST TOUT

2ème passage, requête à partir de ta table temporaire :

Code :

select .... from <ma_table_temporaire> where ...

[ZoomBox]

Oui je ne change rien donc

Comme je l'ai dit j'aurais aimé pouvoir faire ça pendant la liaison au lieu de passer par une selection de la quasi-totalité de ma table liée dans une table "locale" car cela prend un certain temps.

Bon bah merci quand même, bon appétit