J'ai un problème de tri dans une combo sous access 97.
Ma requete est simple, avec 2 tables et une jointure.
je fais apparaître 3 champs de le 1ere table et un champ de la 2eme.
Le tri doit se faire sur le 1er champ de la 1ere table.
Actuellement mon appli est sous NT4 et l'ordre de tri est le bon.
Mais je suis obligé de passer l'appli sous Windows 2000 et c'est là
que les problèmes commencent.
De façon totalement aléatoire, ma combo est triée sur le 1er champ de
la deuxième table alors que le tri dans le requêteur est le 1er champ
de la première table.
Avez-vous vérifié si la requête comporte bien une clause "ORDER BY" ?
Si la requête ne contient pas de clause "ORDER BY", l'ordre dans lequel apparaissent les enregistrements n'est pas déterminé dans la documentation d'Access. C'est peut-être pour cette raison que l'ordre apparaît aléatoire.
Cela dit cet ordre aléatoire ne dépend probablement pas de la version de la version de Windows (NT 4.0 ou 2000), mais plutôt de la version du moteur Jet (MSJET35.DLL), de la version de MSACCESS.EXE et du plan d'exécution de la requête.
Benoît Compoint.
"Steph" wrote in message news:
Bonjour,
J'ai un problème de tri dans une combo sous access 97. Ma requete est simple, avec 2 tables et une jointure. je fais apparaître 3 champs de le 1ere table et un champ de la 2eme. Le tri doit se faire sur le 1er champ de la 1ere table.
Actuellement mon appli est sous NT4 et l'ordre de tri est le bon. Mais je suis obligé de passer l'appli sous Windows 2000 et c'est là que les problèmes commencent.
De façon totalement aléatoire, ma combo est triée sur le 1er champ de la deuxième table alors que le tri dans le requêteur est le 1er champ de la première table.
Merci de votre aide.
Bonjour,
Avez-vous vérifié si la requête comporte bien une clause "ORDER BY" ?
Si la requête ne contient pas de clause "ORDER BY", l'ordre dans lequel
apparaissent les enregistrements n'est pas déterminé dans la documentation
d'Access.
C'est peut-être pour cette raison que l'ordre apparaît aléatoire.
Cela dit cet ordre aléatoire ne dépend probablement pas de la version de la
version de Windows (NT 4.0 ou 2000), mais plutôt de la version du moteur Jet
(MSJET35.DLL), de la version de MSACCESS.EXE et du plan d'exécution de la
requête.
Benoît Compoint.
"Steph" <stephanie.jaffre@cg56.fr> wrote in message
news:d1af49a8.0311170215.3013f7bc@posting.google.com...
Bonjour,
J'ai un problème de tri dans une combo sous access 97.
Ma requete est simple, avec 2 tables et une jointure.
je fais apparaître 3 champs de le 1ere table et un champ de la 2eme.
Le tri doit se faire sur le 1er champ de la 1ere table.
Actuellement mon appli est sous NT4 et l'ordre de tri est le bon.
Mais je suis obligé de passer l'appli sous Windows 2000 et c'est là
que les problèmes commencent.
De façon totalement aléatoire, ma combo est triée sur le 1er champ de
la deuxième table alors que le tri dans le requêteur est le 1er champ
de la première table.
Avez-vous vérifié si la requête comporte bien une clause "ORDER BY" ?
Si la requête ne contient pas de clause "ORDER BY", l'ordre dans lequel apparaissent les enregistrements n'est pas déterminé dans la documentation d'Access. C'est peut-être pour cette raison que l'ordre apparaît aléatoire.
Cela dit cet ordre aléatoire ne dépend probablement pas de la version de la version de Windows (NT 4.0 ou 2000), mais plutôt de la version du moteur Jet (MSJET35.DLL), de la version de MSACCESS.EXE et du plan d'exécution de la requête.
Benoît Compoint.
"Steph" wrote in message news:
Bonjour,
J'ai un problème de tri dans une combo sous access 97. Ma requete est simple, avec 2 tables et une jointure. je fais apparaître 3 champs de le 1ere table et un champ de la 2eme. Le tri doit se faire sur le 1er champ de la 1ere table.
Actuellement mon appli est sous NT4 et l'ordre de tri est le bon. Mais je suis obligé de passer l'appli sous Windows 2000 et c'est là que les problèmes commencent.
De façon totalement aléatoire, ma combo est triée sur le 1er champ de la deuxième table alors que le tri dans le requêteur est le 1er champ de la première table.
Merci de votre aide.
J-Pierre
Peux-tu publier le code, camarade ?
"Steph" a écrit dans le message de news:
Bonjour,
J'ai un problème de tri dans une combo sous access 97. Ma requete est simple, avec 2 tables et une jointure. je fais apparaître 3 champs de le 1ere table et un champ de la 2eme. Le tri doit se faire sur le 1er champ de la 1ere table.
Actuellement mon appli est sous NT4 et l'ordre de tri est le bon. Mais je suis obligé de passer l'appli sous Windows 2000 et c'est là que les problèmes commencent.
De façon totalement aléatoire, ma combo est triée sur le 1er champ de la deuxième table alors que le tri dans le requêteur est le 1er champ de la première table.
Merci de votre aide.
Peux-tu publier le code, camarade ?
"Steph" <stephanie.jaffre@cg56.fr> a écrit dans le message de news:d1af49a8.0311170215.3013f7bc@posting.google.com...
Bonjour,
J'ai un problème de tri dans une combo sous access 97.
Ma requete est simple, avec 2 tables et une jointure.
je fais apparaître 3 champs de le 1ere table et un champ de la 2eme.
Le tri doit se faire sur le 1er champ de la 1ere table.
Actuellement mon appli est sous NT4 et l'ordre de tri est le bon.
Mais je suis obligé de passer l'appli sous Windows 2000 et c'est là
que les problèmes commencent.
De façon totalement aléatoire, ma combo est triée sur le 1er champ de
la deuxième table alors que le tri dans le requêteur est le 1er champ
de la première table.
J'ai un problème de tri dans une combo sous access 97. Ma requete est simple, avec 2 tables et une jointure. je fais apparaître 3 champs de le 1ere table et un champ de la 2eme. Le tri doit se faire sur le 1er champ de la 1ere table.
Actuellement mon appli est sous NT4 et l'ordre de tri est le bon. Mais je suis obligé de passer l'appli sous Windows 2000 et c'est là que les problèmes commencent.
De façon totalement aléatoire, ma combo est triée sur le 1er champ de la deuxième table alors que le tri dans le requêteur est le 1er champ de la première table.
Merci de votre aide.
stephanie.jaffre
Voici la requête source de ma combo :
SELECT [T9-PLANS_ANALYSE].CODEPLANANALYSET9, [T9-PLANS_ANALYSE].NOMPLAN, [T9-PLANS_ANALYSE].CATEGORIEREGLEMENTAIRE, [T9-PLANS_ANALYSE].PRIXPLAN, TL_MATRICES.NOMMATRICE FROM [T9-PLANS_ANALYSE] LEFT JOIN TL_MATRICES ON [T9-PLANS_ANALYSE].CLEMATRICE = TL_MATRICES.IDMATRICE WHERE ((([T9-PLANS_ANALYSE].CODEPLANANALYSET9)>0) AND (([T9-PLANS_ANALYSE].ARCHIVAGE)=0)) ORDER BY [T9-PLANS_ANALYSE].NOMPLAN;
j'ai verifié au niveau des DLL, il y a bien MSJET35.DLL sous les serveurs aussi bien pour NT4 que pour Windows 2000.
Petite précision : je passe par Metaframe pour NT4 et par Metaframe XP pour Windows 2000.
Voici la requête source de ma combo :
SELECT [T9-PLANS_ANALYSE].CODEPLANANALYSET9,
[T9-PLANS_ANALYSE].NOMPLAN,
[T9-PLANS_ANALYSE].CATEGORIEREGLEMENTAIRE,
[T9-PLANS_ANALYSE].PRIXPLAN,
TL_MATRICES.NOMMATRICE
FROM [T9-PLANS_ANALYSE] LEFT JOIN TL_MATRICES ON
[T9-PLANS_ANALYSE].CLEMATRICE = TL_MATRICES.IDMATRICE
WHERE ((([T9-PLANS_ANALYSE].CODEPLANANALYSET9)>0) AND
(([T9-PLANS_ANALYSE].ARCHIVAGE)=0)) ORDER BY
[T9-PLANS_ANALYSE].NOMPLAN;
j'ai verifié au niveau des DLL, il y a bien MSJET35.DLL sous les
serveurs aussi bien pour NT4 que pour Windows 2000.
Petite précision : je passe par Metaframe pour NT4 et
par Metaframe XP pour Windows 2000.
SELECT [T9-PLANS_ANALYSE].CODEPLANANALYSET9, [T9-PLANS_ANALYSE].NOMPLAN, [T9-PLANS_ANALYSE].CATEGORIEREGLEMENTAIRE, [T9-PLANS_ANALYSE].PRIXPLAN, TL_MATRICES.NOMMATRICE FROM [T9-PLANS_ANALYSE] LEFT JOIN TL_MATRICES ON [T9-PLANS_ANALYSE].CLEMATRICE = TL_MATRICES.IDMATRICE WHERE ((([T9-PLANS_ANALYSE].CODEPLANANALYSET9)>0) AND (([T9-PLANS_ANALYSE].ARCHIVAGE)=0)) ORDER BY [T9-PLANS_ANALYSE].NOMPLAN;
j'ai verifié au niveau des DLL, il y a bien MSJET35.DLL sous les serveurs aussi bien pour NT4 que pour Windows 2000.
Petite précision : je passe par Metaframe pour NT4 et par Metaframe XP pour Windows 2000.
J-Pierre
Je répèterai ce que j'ai dit à MadMix au sujet de metaframe, c'est l'environnement qui change, pas Access, ce n'est sans doute pas un problème access. A moins qu'il n'y ait une incompatibilité, les ingénieurs MS vont nous dire ça....
Ta requête me semble juste.
J-Pierre
"Steph" a écrit dans le message de news:
Voici la requête source de ma combo :
SELECT [T9-PLANS_ANALYSE].CODEPLANANALYSET9, [T9-PLANS_ANALYSE].NOMPLAN, [T9-PLANS_ANALYSE].CATEGORIEREGLEMENTAIRE, [T9-PLANS_ANALYSE].PRIXPLAN, TL_MATRICES.NOMMATRICE FROM [T9-PLANS_ANALYSE] LEFT JOIN TL_MATRICES ON [T9-PLANS_ANALYSE].CLEMATRICE = TL_MATRICES.IDMATRICE WHERE ((([T9-PLANS_ANALYSE].CODEPLANANALYSET9)>0) AND (([T9-PLANS_ANALYSE].ARCHIVAGE)=0)) ORDER BY [T9-PLANS_ANALYSE].NOMPLAN;
j'ai verifié au niveau des DLL, il y a bien MSJET35.DLL sous les serveurs aussi bien pour NT4 que pour Windows 2000.
Petite précision : je passe par Metaframe pour NT4 et par Metaframe XP pour Windows 2000.
Je répèterai ce que j'ai dit à MadMix au sujet de metaframe, c'est l'environnement qui change, pas Access, ce n'est sans doute pas
un problème access. A moins qu'il n'y ait une incompatibilité, les ingénieurs MS vont nous dire ça....
Ta requête me semble juste.
J-Pierre
"Steph" <stephanie.jaffre@cg56.fr> a écrit dans le message de news:d1af49a8.0311180054.26bb5f28@posting.google.com...
Voici la requête source de ma combo :
SELECT [T9-PLANS_ANALYSE].CODEPLANANALYSET9,
[T9-PLANS_ANALYSE].NOMPLAN,
[T9-PLANS_ANALYSE].CATEGORIEREGLEMENTAIRE,
[T9-PLANS_ANALYSE].PRIXPLAN,
TL_MATRICES.NOMMATRICE
FROM [T9-PLANS_ANALYSE] LEFT JOIN TL_MATRICES ON
[T9-PLANS_ANALYSE].CLEMATRICE = TL_MATRICES.IDMATRICE
WHERE ((([T9-PLANS_ANALYSE].CODEPLANANALYSET9)>0) AND
(([T9-PLANS_ANALYSE].ARCHIVAGE)=0)) ORDER BY
[T9-PLANS_ANALYSE].NOMPLAN;
j'ai verifié au niveau des DLL, il y a bien MSJET35.DLL sous les
serveurs aussi bien pour NT4 que pour Windows 2000.
Petite précision : je passe par Metaframe pour NT4 et
par Metaframe XP pour Windows 2000.
Je répèterai ce que j'ai dit à MadMix au sujet de metaframe, c'est l'environnement qui change, pas Access, ce n'est sans doute pas un problème access. A moins qu'il n'y ait une incompatibilité, les ingénieurs MS vont nous dire ça....
Ta requête me semble juste.
J-Pierre
"Steph" a écrit dans le message de news:
Voici la requête source de ma combo :
SELECT [T9-PLANS_ANALYSE].CODEPLANANALYSET9, [T9-PLANS_ANALYSE].NOMPLAN, [T9-PLANS_ANALYSE].CATEGORIEREGLEMENTAIRE, [T9-PLANS_ANALYSE].PRIXPLAN, TL_MATRICES.NOMMATRICE FROM [T9-PLANS_ANALYSE] LEFT JOIN TL_MATRICES ON [T9-PLANS_ANALYSE].CLEMATRICE = TL_MATRICES.IDMATRICE WHERE ((([T9-PLANS_ANALYSE].CODEPLANANALYSET9)>0) AND (([T9-PLANS_ANALYSE].ARCHIVAGE)=0)) ORDER BY [T9-PLANS_ANALYSE].NOMPLAN;
j'ai verifié au niveau des DLL, il y a bien MSJET35.DLL sous les serveurs aussi bien pour NT4 que pour Windows 2000.
Petite précision : je passe par Metaframe pour NT4 et par Metaframe XP pour Windows 2000.
Benoit Compoint [MS]
Bonjour,
Il serait intéressant de connaître la version exacte d'Access 97 et du moteur Jet 3.5 (MSJET35.DLL).
En effet il existe 3 versions d'Access 97 : 1. la version publiée début 1997 dite version "gold". 2. la version SR-1 (Service Release 1) publiée en novembre 1997 3. la version SR-2 (Service Release 2) publiée en novembre 1998
Pour vérifier la version d'Access 97, vous pouvez choisir la commande "A propos de Microsoft Access" dans le menu "?" qui est situé à l'extrême droite de la barre de menus.
Il existe près d'une dizaine de versions de MSJET35.DLL. La version la plus récente (Service Pack 3 de Jet 3.5) est conseillée, mais elle a été prévue pour Access 97 SR-2 uniquement. Pour vérifier la version de MSJET35.DLL, vous pouvez cliquer sur ce fichier avec le bouton droit de la souris et choisir "Propriétés".
Benoît Compoint.
"Steph" wrote in message news:
Voici la requête source de ma combo :
SELECT [T9-PLANS_ANALYSE].CODEPLANANALYSET9, [T9-PLANS_ANALYSE].NOMPLAN, [T9-PLANS_ANALYSE].CATEGORIEREGLEMENTAIRE, [T9-PLANS_ANALYSE].PRIXPLAN, TL_MATRICES.NOMMATRICE FROM [T9-PLANS_ANALYSE] LEFT JOIN TL_MATRICES ON [T9-PLANS_ANALYSE].CLEMATRICE = TL_MATRICES.IDMATRICE WHERE ((([T9-PLANS_ANALYSE].CODEPLANANALYSET9)>0) AND (([T9-PLANS_ANALYSE].ARCHIVAGE)=0)) ORDER BY [T9-PLANS_ANALYSE].NOMPLAN;
j'ai verifié au niveau des DLL, il y a bien MSJET35.DLL sous les serveurs aussi bien pour NT4 que pour Windows 2000.
Petite précision : je passe par Metaframe pour NT4 et par Metaframe XP pour Windows 2000.
Bonjour,
Il serait intéressant de connaître la version exacte d'Access 97 et du
moteur Jet 3.5 (MSJET35.DLL).
En effet il existe 3 versions d'Access 97 :
1. la version publiée début 1997 dite version "gold".
2. la version SR-1 (Service Release 1) publiée en novembre 1997
3. la version SR-2 (Service Release 2) publiée en novembre 1998
Pour vérifier la version d'Access 97, vous pouvez choisir la commande "A
propos de Microsoft Access" dans le menu "?" qui est situé à l'extrême
droite de la barre de menus.
Il existe près d'une dizaine de versions de MSJET35.DLL.
La version la plus récente (Service Pack 3 de Jet 3.5) est conseillée, mais
elle a été prévue pour Access 97 SR-2 uniquement.
Pour vérifier la version de MSJET35.DLL, vous pouvez cliquer sur ce fichier
avec le bouton droit de la souris et choisir "Propriétés".
Benoît Compoint.
"Steph" <stephanie.jaffre@cg56.fr> wrote in message
news:d1af49a8.0311180054.26bb5f28@posting.google.com...
Voici la requête source de ma combo :
SELECT [T9-PLANS_ANALYSE].CODEPLANANALYSET9,
[T9-PLANS_ANALYSE].NOMPLAN,
[T9-PLANS_ANALYSE].CATEGORIEREGLEMENTAIRE,
[T9-PLANS_ANALYSE].PRIXPLAN,
TL_MATRICES.NOMMATRICE
FROM [T9-PLANS_ANALYSE] LEFT JOIN TL_MATRICES ON
[T9-PLANS_ANALYSE].CLEMATRICE = TL_MATRICES.IDMATRICE
WHERE ((([T9-PLANS_ANALYSE].CODEPLANANALYSET9)>0) AND
(([T9-PLANS_ANALYSE].ARCHIVAGE)=0)) ORDER BY
[T9-PLANS_ANALYSE].NOMPLAN;
j'ai verifié au niveau des DLL, il y a bien MSJET35.DLL sous les
serveurs aussi bien pour NT4 que pour Windows 2000.
Petite précision : je passe par Metaframe pour NT4 et
par Metaframe XP pour Windows 2000.
Il serait intéressant de connaître la version exacte d'Access 97 et du moteur Jet 3.5 (MSJET35.DLL).
En effet il existe 3 versions d'Access 97 : 1. la version publiée début 1997 dite version "gold". 2. la version SR-1 (Service Release 1) publiée en novembre 1997 3. la version SR-2 (Service Release 2) publiée en novembre 1998
Pour vérifier la version d'Access 97, vous pouvez choisir la commande "A propos de Microsoft Access" dans le menu "?" qui est situé à l'extrême droite de la barre de menus.
Il existe près d'une dizaine de versions de MSJET35.DLL. La version la plus récente (Service Pack 3 de Jet 3.5) est conseillée, mais elle a été prévue pour Access 97 SR-2 uniquement. Pour vérifier la version de MSJET35.DLL, vous pouvez cliquer sur ce fichier avec le bouton droit de la souris et choisir "Propriétés".
Benoît Compoint.
"Steph" wrote in message news:
Voici la requête source de ma combo :
SELECT [T9-PLANS_ANALYSE].CODEPLANANALYSET9, [T9-PLANS_ANALYSE].NOMPLAN, [T9-PLANS_ANALYSE].CATEGORIEREGLEMENTAIRE, [T9-PLANS_ANALYSE].PRIXPLAN, TL_MATRICES.NOMMATRICE FROM [T9-PLANS_ANALYSE] LEFT JOIN TL_MATRICES ON [T9-PLANS_ANALYSE].CLEMATRICE = TL_MATRICES.IDMATRICE WHERE ((([T9-PLANS_ANALYSE].CODEPLANANALYSET9)>0) AND (([T9-PLANS_ANALYSE].ARCHIVAGE)=0)) ORDER BY [T9-PLANS_ANALYSE].NOMPLAN;
j'ai verifié au niveau des DLL, il y a bien MSJET35.DLL sous les serveurs aussi bien pour NT4 que pour Windows 2000.
Petite précision : je passe par Metaframe pour NT4 et par Metaframe XP pour Windows 2000.
stephanie.jaffre
Bonjour,
Les versions installées sur les serveurs Metaframe et Metaframe XP sont :
Pour le moteur jet 3.5 (MSJET35 .DLL) : 3.51.2723.0 Et pour Access 97 : SR-2 b
Donc logiquement, les mises à jour d'access 97 ont été faites.
Steph.
Bonjour,
Les versions installées sur les serveurs Metaframe et Metaframe XP sont :
Pour le moteur jet 3.5 (MSJET35 .DLL) : 3.51.2723.0
Et pour Access 97 : SR-2 b
Donc logiquement, les mises à jour d'access 97 ont été faites.
Les versions installées sur les serveurs Metaframe et Metaframe XP sont :
Pour le moteur jet 3.5 (MSJET35 .DLL) : 3.51.2723.0 Et pour Access 97 : SR-2 b
Donc logiquement, les mises à jour d'access 97 ont été faites.
Steph.
Benoit Compoint [MS]
Bonjour,
Si j'ai bien compris, vous avez vérifié qu'il s'agissait bien des mêmes versions de Jet et d'Access sur Windows Terminal Server 4.0 (avec Metaframe) et sur Windows 2000 Terminal Services (avec Metaframe).
Il reste à vérifier qu'il s'agit bien de la même base MDB (exactement le même fichier MDB).
Cela dit la version 3.51.2723.0 de Jet 3.5 n'est pas la dernière version disponible : 3.51.3328.0. La version 3.51.3328.0 est incluse dans le Service Pack 3 de Jet 3.5 : http://download.microsoft.com/download/office97pro/sp/1/win98/EN-US/Jet35sp3.exe
Le contrôle ComboBox est-il un contrôle intégré à Access, ou est-ce un contrôle ActiveX ?
Benoît Compoint.
"Steph" wrote in message news:
Bonjour,
Les versions installées sur les serveurs Metaframe et Metaframe XP sont :
Pour le moteur jet 3.5 (MSJET35 .DLL) : 3.51.2723.0 Et pour Access 97 : SR-2 b
Donc logiquement, les mises à jour d'access 97 ont été faites.
Steph.
Bonjour,
Si j'ai bien compris, vous avez vérifié qu'il s'agissait bien des mêmes
versions de Jet et d'Access sur Windows Terminal Server 4.0 (avec Metaframe)
et sur Windows 2000 Terminal Services (avec Metaframe).
Il reste à vérifier qu'il s'agit bien de la même base MDB (exactement le
même fichier MDB).
Cela dit la version 3.51.2723.0 de Jet 3.5 n'est pas la dernière version
disponible : 3.51.3328.0.
La version 3.51.3328.0 est incluse dans le Service Pack 3 de Jet 3.5 :
http://download.microsoft.com/download/office97pro/sp/1/win98/EN-US/Jet35sp3.exe
Le contrôle ComboBox est-il un contrôle intégré à Access, ou est-ce un
contrôle ActiveX ?
Benoît Compoint.
"Steph" <stephanie.jaffre@cg56.fr> wrote in message
news:d1af49a8.0311190115.425fa89f@posting.google.com...
Bonjour,
Les versions installées sur les serveurs Metaframe et Metaframe XP sont :
Pour le moteur jet 3.5 (MSJET35 .DLL) : 3.51.2723.0
Et pour Access 97 : SR-2 b
Donc logiquement, les mises à jour d'access 97 ont été faites.
Si j'ai bien compris, vous avez vérifié qu'il s'agissait bien des mêmes versions de Jet et d'Access sur Windows Terminal Server 4.0 (avec Metaframe) et sur Windows 2000 Terminal Services (avec Metaframe).
Il reste à vérifier qu'il s'agit bien de la même base MDB (exactement le même fichier MDB).
Cela dit la version 3.51.2723.0 de Jet 3.5 n'est pas la dernière version disponible : 3.51.3328.0. La version 3.51.3328.0 est incluse dans le Service Pack 3 de Jet 3.5 : http://download.microsoft.com/download/office97pro/sp/1/win98/EN-US/Jet35sp3.exe
Le contrôle ComboBox est-il un contrôle intégré à Access, ou est-ce un contrôle ActiveX ?
Benoît Compoint.
"Steph" wrote in message news:
Bonjour,
Les versions installées sur les serveurs Metaframe et Metaframe XP sont :
Pour le moteur jet 3.5 (MSJET35 .DLL) : 3.51.2723.0 Et pour Access 97 : SR-2 b
Donc logiquement, les mises à jour d'access 97 ont été faites.
Steph.
stephanie.jaffre
J'ai mis en place la version du moteur jet 3.5 : 3.51.3328.0
Pour l'instant, le problème de tri ne se produit plus mais puisqu'il est aléatoire, je préfère ne pas crier victoire trop vite. Donc j'attends de voir.
Concernant le contrôle ComboBox, c'est un contrôle intégré à ACCESS. On le trouve sur un MDB que l'on vient de créer sans rajouter d'OCX. ou d'autre référence.
Je vous remercie de votre aide.
J'ai mis en place la version du moteur jet 3.5 : 3.51.3328.0
Pour l'instant, le problème de tri ne se produit plus mais puisqu'il
est aléatoire, je préfère ne pas crier victoire trop vite.
Donc j'attends de voir.
Concernant le contrôle ComboBox, c'est un contrôle intégré à ACCESS.
On le trouve sur un MDB que l'on vient de créer sans rajouter d'OCX.
ou d'autre référence.
J'ai mis en place la version du moteur jet 3.5 : 3.51.3328.0
Pour l'instant, le problème de tri ne se produit plus mais puisqu'il est aléatoire, je préfère ne pas crier victoire trop vite. Donc j'attends de voir.
Concernant le contrôle ComboBox, c'est un contrôle intégré à ACCESS. On le trouve sur un MDB que l'on vient de créer sans rajouter d'OCX. ou d'autre référence.
Je vous remercie de votre aide.
stephanie.jaffre
Malgrès la mise en place de la version du moteur jet 3.5 : 3.51.3328.0 , mon problème de tri se produit toujours.
Y aurait-il autre chose à mettre à jour ??
J'utilise le driver ODBC d'oracle 8.01.07.00 pour attaquer ma base de données. Y a t-il une mise à jour à faire de ce coté là ?
Ou est-ce que Access97 atteind ses limites en étant sur Windows 2000 ?
Malgrès la mise en place de la version du moteur jet 3.5 : 3.51.3328.0 ,
mon problème de tri se produit toujours.
Y aurait-il autre chose à mettre à jour ??
J'utilise le driver ODBC d'oracle 8.01.07.00 pour attaquer ma base de données.
Y a t-il une mise à jour à faire de ce coté là ?
Ou est-ce que Access97 atteind ses limites en étant sur Windows 2000 ?
Malgrès la mise en place de la version du moteur jet 3.5 : 3.51.3328.0 , mon problème de tri se produit toujours.
Y aurait-il autre chose à mettre à jour ??
J'utilise le driver ODBC d'oracle 8.01.07.00 pour attaquer ma base de données. Y a t-il une mise à jour à faire de ce coté là ?
Ou est-ce que Access97 atteind ses limites en étant sur Windows 2000 ?
J-Pierre
Salut Steph,
Sauf erreur de ma part, tu n'avais pas dit que tu avais une base Oracle....C'est sans doute de ce côté là qu'il faut chercher.
En attendant, est-ce que la requête source de ta combo est définie directement dans le formulaire ? Si oui, fais-en une "vraie" requête, et pour ta combo, tu spécifies comme source cette nouvelle requête en la retriant. Ca risque de te faire un double tri, côté serveur + Access, mais avec un peu de chance, quand access retriera le résultat de ta requête, ça marchera.
J-Pierre
"Steph" a écrit dans le message de news:
Malgrès la mise en place de la version du moteur jet 3.5 : 3.51.3328.0 , mon problème de tri se produit toujours.
Y aurait-il autre chose à mettre à jour ??
J'utilise le driver ODBC d'oracle 8.01.07.00 pour attaquer ma base de données. Y a t-il une mise à jour à faire de ce coté là ?
Ou est-ce que Access97 atteind ses limites en étant sur Windows 2000 ?
Salut Steph,
Sauf erreur de ma part, tu n'avais pas dit que tu avais une base Oracle....C'est sans doute de ce côté là qu'il faut chercher.
En attendant, est-ce que la requête source de ta combo est définie directement dans le formulaire ? Si oui, fais-en une "vraie"
requête, et pour ta combo, tu spécifies comme source cette nouvelle requête en la retriant. Ca risque de te faire un double tri,
côté serveur + Access, mais avec un peu de chance, quand access retriera le résultat de ta requête, ça marchera.
J-Pierre
"Steph" <stephanie.jaffre@cg56.fr> a écrit dans le message de news:d1af49a8.0311270344.1d01cd3a@posting.google.com...
Malgrès la mise en place de la version du moteur jet 3.5 : 3.51.3328.0 ,
mon problème de tri se produit toujours.
Y aurait-il autre chose à mettre à jour ??
J'utilise le driver ODBC d'oracle 8.01.07.00 pour attaquer ma base de données.
Y a t-il une mise à jour à faire de ce coté là ?
Ou est-ce que Access97 atteind ses limites en étant sur Windows 2000 ?
Sauf erreur de ma part, tu n'avais pas dit que tu avais une base Oracle....C'est sans doute de ce côté là qu'il faut chercher.
En attendant, est-ce que la requête source de ta combo est définie directement dans le formulaire ? Si oui, fais-en une "vraie" requête, et pour ta combo, tu spécifies comme source cette nouvelle requête en la retriant. Ca risque de te faire un double tri, côté serveur + Access, mais avec un peu de chance, quand access retriera le résultat de ta requête, ça marchera.
J-Pierre
"Steph" a écrit dans le message de news:
Malgrès la mise en place de la version du moteur jet 3.5 : 3.51.3328.0 , mon problème de tri se produit toujours.
Y aurait-il autre chose à mettre à jour ??
J'utilise le driver ODBC d'oracle 8.01.07.00 pour attaquer ma base de données. Y a t-il une mise à jour à faire de ce coté là ?
Ou est-ce que Access97 atteind ses limites en étant sur Windows 2000 ?
