Tout d’abord je cerne l’application.
J’alimente de données les differents onglets d’un fichier Excel.
(Fichier_org.xls)
Les données de ces onglets sont copiées dans un fichier Excel portant le nom
de l’onglet d’où elles proviennent.
Dans mon cas, il en existe donc 7. (ong1.xls a ong7.xls)
Ces 7 fichiers Excel sont lié a une base Acces (on y arrive) et apparaissent
donc sous Acces sous forme de fichier Excel dont il est impossible de
modifier le format.
On importe les données de ces 7 fichier Excel liés dans des tables Acces du
meme format via une requete imbriquée (*7) dans Acces du type
Insert Into table1 (champ1......)(select champ1 ..... from ong1 ))
Je choisi de passer par une procedure VB pour un contrôle plus poussé du
contenu d’un fichier.
De ce fait, la procedure se compose en 3 morceaux : principaux
- Select champ1,…… from ong1
- ouverture du recordset
- lecture sequentielle du recordset
o verification des données
o Table1.Addnew
- et ceci jusque la fin du recordset.
Donc a la fin de la mise a jour de la base, on a 7 tables a l’image des 7
fichiers Excel liés, soit Table1 a Table7
Ceci fait, on exporte les données de ces tables dans un onglet d’un fichier
Excel. Donc on retrouve nos 7 tables dans 7 onglets d’un nouveau fichier
Excel (Fichier_global.xls). ces données sont inserées dans chacun des onglets
via une requetes ODBC attaché a chaque onglet. A chaque ouverture de
Fichier_global.xls, les requetes vont cherchée les enregistrement dans les 7
tables concernées.
Debut du pb :
Avant l’ajout de la procedure VB pour un fichier en particulier, Tous les
onglets avaient la meme disposition :
dans le Fichier_org.xls , pour tous les onglets, les données sont saisie
dans cet ordre :
Donnée 1
Donnée 2
Donnée 3
Donnée 4
Elles sont copiées dans le fichier excel ong1.xls dans cet ordre ( je ne
prends qu’un fchier en exple)
Elles sont insérée dans la table via la requete imbriqué dans cet ordre
Lorsque j’ouvre le Fichier_global.xls, les données se retrouvent dans cet
ordre dans chaque onglet, bien qu’il n’y ai aucun critere de tri dans la
requete ODBC.
Apres la procedure VB particuliere pour un fichier excel lié , les données
de ce fameux fichier
Arrivent dans le Fichier_global.xls dans le desordre.
Ma question est : comment se fait il que mes enregistrements arrivent tous
triés sans critere de tri dans les requetes ODBC pour 6 onglet et pas pour le
7eme.
La seule différence est cette procedure VB.
Qu’est ce qui determine l’ordre d’arrivé des enregistrement lors d’un SELECT ?
Je ne sais comment marche Acces en interne mais, y aurait il un index
incrementé dans le cas de ma requete imbriqué et pas dans le cas de la
procedure VB ? ( alors que le resultat final dans la table est le meme)
n'hesitez pas a me demander si quelque chose n'est pas clair.
bien a vous
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire
Veuillez sélectionner un problème
Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
Buddy
Salut, Je récapitule pour y voir plus clair
1. Fichier excel : 7 onglets 2. Transformation du 1 en 7 fichiers excel 3. Liaison des 7 fichiers à access via les tables attachées (7 tables attachées) 4. Remplissage de 7 tables access locales par code VB avec controle des données 5. A partir d'excel : requête ODBC vers les 7 tables access locales et rappatriement des données dans 7 onglets d'excel => Perte du tri
Si j'ai tout bon alors on continue
Ma question est : comment se fait il que mes enregistrements arrivent tous triés sans critere de tri dans les requetes ODBC pour 6 onglet et pas pour le 7eme. Ta requête ODBC pour la 7ème table est elle strictement identique aux 6 autres ?
Si oui, je contournerai le problème en rajoutant en 1ere position une colonne incrémentée dans Excel (cela devrait suffire sans avoir à modifier tes requêtes ODBC, le tri devrait être rspecté) (et en cas de problème je reparametrerai les requêtes ODBC en forçant le tri sur cette colonne)
Qu’est ce qui determine l’ordre d’arrivé des enregistrement lors d’un SELECT ? S'il n'y a pas de tri particulier, les enregistrements sont traitées dans l'ordre dans lequel ils
se présentent. Saches qu'access n'aime pas trop traviller sur des tables sans cle NumeroAuto, c'est pour cela qui si tu crée une table sans cle, il te propose de crée un champ NumeroAuto automatiquement. Donc je modifierai les tables access en local en y rajoutant ce champ NumeroAuto qui ne te seras d'aucune utilité directe mais te permettra de conserver le tri
Ouala Bye Buddy
Tout d’abord je cerne l’application. J’alimente de données les differents onglets d’un fichier Excel. (Fichier_org.xls) Les données de ces onglets sont copiées dans un fichier Excel portant le nom de l’onglet d’où elles proviennent. Dans mon cas, il en existe donc 7. (ong1.xls a ong7.xls) Ces 7 fichiers Excel sont lié a une base Acces (on y arrive) et apparaissent donc sous Acces sous forme de fichier Excel dont il est impossible de modifier le format. On importe les données de ces 7 fichier Excel liés dans des tables Acces du meme format via une requete imbriquée (*7) dans Acces du type Insert Into table1 (champ1......)(select champ1 ..... from ong1 ))
Je choisi de passer par une procedure VB pour un contrôle plus poussé du contenu d’un fichier. De ce fait, la procedure se compose en 3 morceaux : principaux - Select champ1,…… from ong1 - ouverture du recordset - lecture sequentielle du recordset o verification des données o Table1.Addnew - et ceci jusque la fin du recordset.
Donc a la fin de la mise a jour de la base, on a 7 tables a l’image des 7 fichiers Excel liés, soit Table1 a Table7
Ceci fait, on exporte les données de ces tables dans un onglet d’un fichier Excel. Donc on retrouve nos 7 tables dans 7 onglets d’un nouveau fichier Excel (Fichier_global.xls). ces données sont inserées dans chacun des onglets via une requetes ODBC attaché a chaque onglet. A chaque ouverture de Fichier_global.xls, les requetes vont cherchée les enregistrement dans les 7 tables concernées.
Debut du pb : Avant l’ajout de la procedure VB pour un fichier en particulier, Tous les onglets avaient la meme disposition :
dans le Fichier_org.xls , pour tous les onglets, les données sont saisie dans cet ordre : Donnée 1 Donnée 2 Donnée 3 Donnée 4 Elles sont copiées dans le fichier excel ong1.xls dans cet ordre ( je ne prends qu’un fchier en exple) Elles sont insérée dans la table via la requete imbriqué dans cet ordre Lorsque j’ouvre le Fichier_global.xls, les données se retrouvent dans cet ordre dans chaque onglet, bien qu’il n’y ai aucun critere de tri dans la requete ODBC.
Apres la procedure VB particuliere pour un fichier excel lié , les données de ce fameux fichier Arrivent dans le Fichier_global.xls dans le desordre. Ma question est : comment se fait il que mes enregistrements arrivent tous triés sans critere de tri dans les requetes ODBC pour 6 onglet et pas pour le 7eme. La seule différence est cette procedure VB. Qu’est ce qui determine l’ordre d’arrivé des enregistrement lors d’un SELECT ? Je ne sais comment marche Acces en interne mais, y aurait il un index incrementé dans le cas de ma requete imbriqué et pas dans le cas de la procedure VB ? ( alors que le resultat final dans la table est le meme)
n'hesitez pas a me demander si quelque chose n'est pas clair. bien a vous
Vincent
-- Ouala Bye Buddy
PS : retirer 123 pour m'envoyer un email.
Salut,
Je récapitule pour y voir plus clair
1. Fichier excel : 7 onglets
2. Transformation du 1 en 7 fichiers excel
3. Liaison des 7 fichiers à access via les tables attachées (7 tables attachées)
4. Remplissage de 7 tables access locales par code VB avec controle des données
5. A partir d'excel : requête ODBC vers les 7 tables access locales et rappatriement des données
dans 7 onglets d'excel => Perte du tri
Si j'ai tout bon alors on continue
Ma question est : comment se fait il que mes enregistrements arrivent tous
triés sans critere de tri dans les requetes ODBC pour 6 onglet et pas pour le
7eme.
Ta requête ODBC pour la 7ème table est elle strictement identique aux 6 autres ?
Si oui, je contournerai le problème en rajoutant en 1ere position une colonne incrémentée dans
Excel (cela devrait suffire sans avoir à modifier tes requêtes ODBC, le tri devrait être rspecté)
(et en cas de problème je reparametrerai les requêtes ODBC en forçant le tri sur cette colonne)
Qu’est ce qui determine l’ordre d’arrivé des enregistrement lors d’un SELECT ?
S'il n'y a pas de tri particulier, les enregistrements sont traitées dans l'ordre dans lequel ils
se présentent.
Saches qu'access n'aime pas trop traviller sur des tables sans cle NumeroAuto, c'est pour cela qui
si tu crée une table sans cle, il te propose de crée un champ NumeroAuto automatiquement.
Donc je modifierai les tables access en local en y rajoutant ce champ NumeroAuto qui ne te seras
d'aucune utilité directe mais te permettra de conserver le tri
Ouala
Bye
Buddy
Tout d’abord je cerne l’application.
J’alimente de données les differents onglets d’un fichier Excel.
(Fichier_org.xls)
Les données de ces onglets sont copiées dans un fichier Excel portant le nom
de l’onglet d’où elles proviennent.
Dans mon cas, il en existe donc 7. (ong1.xls a ong7.xls)
Ces 7 fichiers Excel sont lié a une base Acces (on y arrive) et apparaissent
donc sous Acces sous forme de fichier Excel dont il est impossible de
modifier le format.
On importe les données de ces 7 fichier Excel liés dans des tables Acces du
meme format via une requete imbriquée (*7) dans Acces du type
Insert Into table1 (champ1......)(select champ1 ..... from ong1 ))
Je choisi de passer par une procedure VB pour un contrôle plus poussé du
contenu d’un fichier.
De ce fait, la procedure se compose en 3 morceaux : principaux
- Select champ1,…… from ong1
- ouverture du recordset
- lecture sequentielle du recordset
o verification des données
o Table1.Addnew
- et ceci jusque la fin du recordset.
Donc a la fin de la mise a jour de la base, on a 7 tables a l’image des 7
fichiers Excel liés, soit Table1 a Table7
Ceci fait, on exporte les données de ces tables dans un onglet d’un fichier
Excel. Donc on retrouve nos 7 tables dans 7 onglets d’un nouveau fichier
Excel (Fichier_global.xls). ces données sont inserées dans chacun des onglets
via une requetes ODBC attaché a chaque onglet. A chaque ouverture de
Fichier_global.xls, les requetes vont cherchée les enregistrement dans les 7
tables concernées.
Debut du pb :
Avant l’ajout de la procedure VB pour un fichier en particulier, Tous les
onglets avaient la meme disposition :
dans le Fichier_org.xls , pour tous les onglets, les données sont saisie
dans cet ordre :
Donnée 1
Donnée 2
Donnée 3
Donnée 4
Elles sont copiées dans le fichier excel ong1.xls dans cet ordre ( je ne
prends qu’un fchier en exple)
Elles sont insérée dans la table via la requete imbriqué dans cet ordre
Lorsque j’ouvre le Fichier_global.xls, les données se retrouvent dans cet
ordre dans chaque onglet, bien qu’il n’y ai aucun critere de tri dans la
requete ODBC.
Apres la procedure VB particuliere pour un fichier excel lié , les données
de ce fameux fichier
Arrivent dans le Fichier_global.xls dans le desordre.
Ma question est : comment se fait il que mes enregistrements arrivent tous
triés sans critere de tri dans les requetes ODBC pour 6 onglet et pas pour le
7eme.
La seule différence est cette procedure VB.
Qu’est ce qui determine l’ordre d’arrivé des enregistrement lors d’un SELECT ?
Je ne sais comment marche Acces en interne mais, y aurait il un index
incrementé dans le cas de ma requete imbriqué et pas dans le cas de la
procedure VB ? ( alors que le resultat final dans la table est le meme)
n'hesitez pas a me demander si quelque chose n'est pas clair.
bien a vous
1. Fichier excel : 7 onglets 2. Transformation du 1 en 7 fichiers excel 3. Liaison des 7 fichiers à access via les tables attachées (7 tables attachées) 4. Remplissage de 7 tables access locales par code VB avec controle des données 5. A partir d'excel : requête ODBC vers les 7 tables access locales et rappatriement des données dans 7 onglets d'excel => Perte du tri
Si j'ai tout bon alors on continue
Ma question est : comment se fait il que mes enregistrements arrivent tous triés sans critere de tri dans les requetes ODBC pour 6 onglet et pas pour le 7eme. Ta requête ODBC pour la 7ème table est elle strictement identique aux 6 autres ?
Si oui, je contournerai le problème en rajoutant en 1ere position une colonne incrémentée dans Excel (cela devrait suffire sans avoir à modifier tes requêtes ODBC, le tri devrait être rspecté) (et en cas de problème je reparametrerai les requêtes ODBC en forçant le tri sur cette colonne)
Qu’est ce qui determine l’ordre d’arrivé des enregistrement lors d’un SELECT ? S'il n'y a pas de tri particulier, les enregistrements sont traitées dans l'ordre dans lequel ils
se présentent. Saches qu'access n'aime pas trop traviller sur des tables sans cle NumeroAuto, c'est pour cela qui si tu crée une table sans cle, il te propose de crée un champ NumeroAuto automatiquement. Donc je modifierai les tables access en local en y rajoutant ce champ NumeroAuto qui ne te seras d'aucune utilité directe mais te permettra de conserver le tri
Ouala Bye Buddy
Tout d’abord je cerne l’application. J’alimente de données les differents onglets d’un fichier Excel. (Fichier_org.xls) Les données de ces onglets sont copiées dans un fichier Excel portant le nom de l’onglet d’où elles proviennent. Dans mon cas, il en existe donc 7. (ong1.xls a ong7.xls) Ces 7 fichiers Excel sont lié a une base Acces (on y arrive) et apparaissent donc sous Acces sous forme de fichier Excel dont il est impossible de modifier le format. On importe les données de ces 7 fichier Excel liés dans des tables Acces du meme format via une requete imbriquée (*7) dans Acces du type Insert Into table1 (champ1......)(select champ1 ..... from ong1 ))
Je choisi de passer par une procedure VB pour un contrôle plus poussé du contenu d’un fichier. De ce fait, la procedure se compose en 3 morceaux : principaux - Select champ1,…… from ong1 - ouverture du recordset - lecture sequentielle du recordset o verification des données o Table1.Addnew - et ceci jusque la fin du recordset.
Donc a la fin de la mise a jour de la base, on a 7 tables a l’image des 7 fichiers Excel liés, soit Table1 a Table7
Ceci fait, on exporte les données de ces tables dans un onglet d’un fichier Excel. Donc on retrouve nos 7 tables dans 7 onglets d’un nouveau fichier Excel (Fichier_global.xls). ces données sont inserées dans chacun des onglets via une requetes ODBC attaché a chaque onglet. A chaque ouverture de Fichier_global.xls, les requetes vont cherchée les enregistrement dans les 7 tables concernées.
Debut du pb : Avant l’ajout de la procedure VB pour un fichier en particulier, Tous les onglets avaient la meme disposition :
dans le Fichier_org.xls , pour tous les onglets, les données sont saisie dans cet ordre : Donnée 1 Donnée 2 Donnée 3 Donnée 4 Elles sont copiées dans le fichier excel ong1.xls dans cet ordre ( je ne prends qu’un fchier en exple) Elles sont insérée dans la table via la requete imbriqué dans cet ordre Lorsque j’ouvre le Fichier_global.xls, les données se retrouvent dans cet ordre dans chaque onglet, bien qu’il n’y ai aucun critere de tri dans la requete ODBC.
Apres la procedure VB particuliere pour un fichier excel lié , les données de ce fameux fichier Arrivent dans le Fichier_global.xls dans le desordre. Ma question est : comment se fait il que mes enregistrements arrivent tous triés sans critere de tri dans les requetes ODBC pour 6 onglet et pas pour le 7eme. La seule différence est cette procedure VB. Qu’est ce qui determine l’ordre d’arrivé des enregistrement lors d’un SELECT ? Je ne sais comment marche Acces en interne mais, y aurait il un index incrementé dans le cas de ma requete imbriqué et pas dans le cas de la procedure VB ? ( alors que le resultat final dans la table est le meme)
n'hesitez pas a me demander si quelque chose n'est pas clair. bien a vous
Vincent
-- Ouala Bye Buddy
PS : retirer 123 pour m'envoyer un email.
Vince
4 - remplissage de 6 tables par requetes imbriquées (comme decrite) et 1 par procedure VB (select d'abord et insert apres).
avant, les 7 table excel etaient renseignée avec des requetes imbriquées (Insert(...)(Select... ) ) puis pour une table, (celle de la proc VB), il demande un controle de données d'où la procedure. et maintenant, dans le fichier pour cette table, les enregistrements n'arrive plus dans l'ordre désiré. ces requetes ODBC ne possedent pas de critere de tri, donc elles arrivent trié je ne sais comment.
pour 4 des 7 tables-fichier-onglets des champs de données ont ete rajouté sans incidence sur un quelconque tri . une de ces 4 tables est LA table avec Proc VB. les 3 autres arrivent trié au final, la 4eme non. alors effectivement pour resoudre le probleme, j'ai rajouté un critere de tri dans ma requete ODBC. seulement voila le client a du mal a croire ce que je lui dit, a savoir qu' il a eu du bol de les avoirs trié jusqu'a present car leur requete d'origine ne trient pas les enreg. cela ne me donne pas pour autant la raison pour laquelle ils l'etaient avant et, apres ma modif sur l'alimentation de la table , ils ne le sont plus. c'est une explication sur le fonctionnement interne des table qui me manquent pour comprehension.
et oui, un numéro auto aurait ete sympa mais je ne suis pas le concepteur de l'appli et on me demande juste des modifs. merci pour ta premiere reponse buddy
vincent
Salut, Je récapitule pour y voir plus clair
1. Fichier excel : 7 onglets 2. Transformation du 1 en 7 fichiers excel 3. Liaison des 7 fichiers à access via les tables attachées (7 tables attachées) 4. Remplissage de 7 tables access locales par code VB avec controle des données 5. A partir d'excel : requête ODBC vers les 7 tables access locales et rappatriement des données dans 7 onglets d'excel => Perte du tri
Si j'ai tout bon alors on continue
Ma question est : comment se fait il que mes enregistrements arrivent tous triés sans critere de tri dans les requetes ODBC pour 6 onglet et pas pour le 7eme. Ta requête ODBC pour la 7ème table est elle strictement identique aux 6 autres ?
Si oui, je contournerai le problème en rajoutant en 1ere position une colonne incrémentée dans Excel (cela devrait suffire sans avoir à modifier tes requêtes ODBC, le tri devrait être rspecté) (et en cas de problème je reparametrerai les requêtes ODBC en forçant le tri sur cette colonne)
Qu’est ce qui determine l’ordre d’arrivé des enregistrement lors d’un SELECT ? S'il n'y a pas de tri particulier, les enregistrements sont traitées dans l'ordre dans lequel ils
se présentent. Saches qu'access n'aime pas trop traviller sur des tables sans cle NumeroAuto, c'est pour cela qui si tu crée une table sans cle, il te propose de crée un champ NumeroAuto automatiquement. Donc je modifierai les tables access en local en y rajoutant ce champ NumeroAuto qui ne te seras d'aucune utilité directe mais te permettra de conserver le tri
Ouala Bye Buddy
Tout d’abord je cerne l’application. J’alimente de données les differents onglets d’un fichier Excel. (Fichier_org.xls) Les données de ces onglets sont copiées dans un fichier Excel portant le nom de l’onglet d’où elles proviennent. Dans mon cas, il en existe donc 7. (ong1.xls a ong7.xls) Ces 7 fichiers Excel sont lié a une base Acces (on y arrive) et apparaissent donc sous Acces sous forme de fichier Excel dont il est impossible de modifier le format. On importe les données de ces 7 fichier Excel liés dans des tables Acces du meme format via une requete imbriquée (*7) dans Acces du type Insert Into table1 (champ1......)(select champ1 ..... from ong1 ))
Je choisi de passer par une procedure VB pour un contrôle plus poussé du contenu d’un fichier. De ce fait, la procedure se compose en 3 morceaux : principaux - Select champ1,…… from ong1 - ouverture du recordset - lecture sequentielle du recordset o verification des données o Table1.Addnew - et ceci jusque la fin du recordset.
Donc a la fin de la mise a jour de la base, on a 7 tables a l’image des 7 fichiers Excel liés, soit Table1 a Table7
Ceci fait, on exporte les données de ces tables dans un onglet d’un fichier Excel. Donc on retrouve nos 7 tables dans 7 onglets d’un nouveau fichier Excel (Fichier_global.xls). ces données sont inserées dans chacun des onglets via une requetes ODBC attaché a chaque onglet. A chaque ouverture de Fichier_global.xls, les requetes vont cherchée les enregistrement dans les 7 tables concernées.
Debut du pb : Avant l’ajout de la procedure VB pour un fichier en particulier, Tous les onglets avaient la meme disposition :
dans le Fichier_org.xls , pour tous les onglets, les données sont saisie dans cet ordre : Donnée 1 Donnée 2 Donnée 3 Donnée 4 Elles sont copiées dans le fichier excel ong1.xls dans cet ordre ( je ne prends qu’un fchier en exple) Elles sont insérée dans la table via la requete imbriqué dans cet ordre Lorsque j’ouvre le Fichier_global.xls, les données se retrouvent dans cet ordre dans chaque onglet, bien qu’il n’y ai aucun critere de tri dans la requete ODBC.
Apres la procedure VB particuliere pour un fichier excel lié , les données de ce fameux fichier Arrivent dans le Fichier_global.xls dans le desordre. Ma question est : comment se fait il que mes enregistrements arrivent tous triés sans critere de tri dans les requetes ODBC pour 6 onglet et pas pour le 7eme. La seule différence est cette procedure VB. Qu’est ce qui determine l’ordre d’arrivé des enregistrement lors d’un SELECT ? Je ne sais comment marche Acces en interne mais, y aurait il un index incrementé dans le cas de ma requete imbriqué et pas dans le cas de la procedure VB ? ( alors que le resultat final dans la table est le meme)
n'hesitez pas a me demander si quelque chose n'est pas clair. bien a vous
Vincent
-- Ouala Bye Buddy
PS : retirer 123 pour m'envoyer un email.
4 - remplissage de 6 tables par requetes imbriquées (comme decrite) et 1
par procedure VB (select d'abord et insert apres).
avant, les 7 table excel etaient renseignée avec des requetes imbriquées
(Insert(...)(Select... ) )
puis pour une table, (celle de la proc VB), il demande un controle de
données d'où la procedure.
et maintenant, dans le fichier pour cette table, les enregistrements
n'arrive plus dans l'ordre désiré.
ces requetes ODBC ne possedent pas de critere de tri, donc elles arrivent
trié je ne sais comment.
pour 4 des 7 tables-fichier-onglets des champs de données ont ete rajouté
sans incidence sur un quelconque tri .
une de ces 4 tables est LA table avec Proc VB.
les 3 autres arrivent trié au final, la 4eme non.
alors effectivement pour resoudre le probleme, j'ai rajouté un critere de
tri dans ma requete ODBC.
seulement voila le client a du mal a croire ce que je lui dit, a savoir qu'
il a eu du bol de les avoirs trié jusqu'a present car leur requete d'origine
ne trient pas les enreg.
cela ne me donne pas pour autant la raison pour laquelle ils l'etaient avant
et, apres ma modif sur l'alimentation de la table , ils ne le sont plus.
c'est une explication sur le fonctionnement interne des table qui me
manquent pour comprehension.
et oui, un numéro auto aurait ete sympa mais je ne suis pas le concepteur de
l'appli et on me demande juste des modifs.
merci pour ta premiere reponse buddy
vincent
Salut,
Je récapitule pour y voir plus clair
1. Fichier excel : 7 onglets
2. Transformation du 1 en 7 fichiers excel
3. Liaison des 7 fichiers à access via les tables attachées (7 tables attachées)
4. Remplissage de 7 tables access locales par code VB avec controle des données
5. A partir d'excel : requête ODBC vers les 7 tables access locales et rappatriement des données
dans 7 onglets d'excel => Perte du tri
Si j'ai tout bon alors on continue
Ma question est : comment se fait il que mes enregistrements arrivent tous
triés sans critere de tri dans les requetes ODBC pour 6 onglet et pas pour le
7eme.
Ta requête ODBC pour la 7ème table est elle strictement identique aux 6 autres ?
Si oui, je contournerai le problème en rajoutant en 1ere position une colonne incrémentée dans
Excel (cela devrait suffire sans avoir à modifier tes requêtes ODBC, le tri devrait être rspecté)
(et en cas de problème je reparametrerai les requêtes ODBC en forçant le tri sur cette colonne)
Qu’est ce qui determine l’ordre d’arrivé des enregistrement lors d’un SELECT ?
S'il n'y a pas de tri particulier, les enregistrements sont traitées dans l'ordre dans lequel ils
se présentent.
Saches qu'access n'aime pas trop traviller sur des tables sans cle NumeroAuto, c'est pour cela qui
si tu crée une table sans cle, il te propose de crée un champ NumeroAuto automatiquement.
Donc je modifierai les tables access en local en y rajoutant ce champ NumeroAuto qui ne te seras
d'aucune utilité directe mais te permettra de conserver le tri
Ouala
Bye
Buddy
Tout d’abord je cerne l’application.
J’alimente de données les differents onglets d’un fichier Excel.
(Fichier_org.xls)
Les données de ces onglets sont copiées dans un fichier Excel portant le nom
de l’onglet d’où elles proviennent.
Dans mon cas, il en existe donc 7. (ong1.xls a ong7.xls)
Ces 7 fichiers Excel sont lié a une base Acces (on y arrive) et apparaissent
donc sous Acces sous forme de fichier Excel dont il est impossible de
modifier le format.
On importe les données de ces 7 fichier Excel liés dans des tables Acces du
meme format via une requete imbriquée (*7) dans Acces du type
Insert Into table1 (champ1......)(select champ1 ..... from ong1 ))
Je choisi de passer par une procedure VB pour un contrôle plus poussé du
contenu d’un fichier.
De ce fait, la procedure se compose en 3 morceaux : principaux
- Select champ1,…… from ong1
- ouverture du recordset
- lecture sequentielle du recordset
o verification des données
o Table1.Addnew
- et ceci jusque la fin du recordset.
Donc a la fin de la mise a jour de la base, on a 7 tables a l’image des 7
fichiers Excel liés, soit Table1 a Table7
Ceci fait, on exporte les données de ces tables dans un onglet d’un fichier
Excel. Donc on retrouve nos 7 tables dans 7 onglets d’un nouveau fichier
Excel (Fichier_global.xls). ces données sont inserées dans chacun des onglets
via une requetes ODBC attaché a chaque onglet. A chaque ouverture de
Fichier_global.xls, les requetes vont cherchée les enregistrement dans les 7
tables concernées.
Debut du pb :
Avant l’ajout de la procedure VB pour un fichier en particulier, Tous les
onglets avaient la meme disposition :
dans le Fichier_org.xls , pour tous les onglets, les données sont saisie
dans cet ordre :
Donnée 1
Donnée 2
Donnée 3
Donnée 4
Elles sont copiées dans le fichier excel ong1.xls dans cet ordre ( je ne
prends qu’un fchier en exple)
Elles sont insérée dans la table via la requete imbriqué dans cet ordre
Lorsque j’ouvre le Fichier_global.xls, les données se retrouvent dans cet
ordre dans chaque onglet, bien qu’il n’y ai aucun critere de tri dans la
requete ODBC.
Apres la procedure VB particuliere pour un fichier excel lié , les données
de ce fameux fichier
Arrivent dans le Fichier_global.xls dans le desordre.
Ma question est : comment se fait il que mes enregistrements arrivent tous
triés sans critere de tri dans les requetes ODBC pour 6 onglet et pas pour le
7eme.
La seule différence est cette procedure VB.
Qu’est ce qui determine l’ordre d’arrivé des enregistrement lors d’un SELECT ?
Je ne sais comment marche Acces en interne mais, y aurait il un index
incrementé dans le cas de ma requete imbriqué et pas dans le cas de la
procedure VB ? ( alors que le resultat final dans la table est le meme)
n'hesitez pas a me demander si quelque chose n'est pas clair.
bien a vous
4 - remplissage de 6 tables par requetes imbriquées (comme decrite) et 1 par procedure VB (select d'abord et insert apres).
avant, les 7 table excel etaient renseignée avec des requetes imbriquées (Insert(...)(Select... ) ) puis pour une table, (celle de la proc VB), il demande un controle de données d'où la procedure. et maintenant, dans le fichier pour cette table, les enregistrements n'arrive plus dans l'ordre désiré. ces requetes ODBC ne possedent pas de critere de tri, donc elles arrivent trié je ne sais comment.
pour 4 des 7 tables-fichier-onglets des champs de données ont ete rajouté sans incidence sur un quelconque tri . une de ces 4 tables est LA table avec Proc VB. les 3 autres arrivent trié au final, la 4eme non. alors effectivement pour resoudre le probleme, j'ai rajouté un critere de tri dans ma requete ODBC. seulement voila le client a du mal a croire ce que je lui dit, a savoir qu' il a eu du bol de les avoirs trié jusqu'a present car leur requete d'origine ne trient pas les enreg. cela ne me donne pas pour autant la raison pour laquelle ils l'etaient avant et, apres ma modif sur l'alimentation de la table , ils ne le sont plus. c'est une explication sur le fonctionnement interne des table qui me manquent pour comprehension.
et oui, un numéro auto aurait ete sympa mais je ne suis pas le concepteur de l'appli et on me demande juste des modifs. merci pour ta premiere reponse buddy
vincent
Salut, Je récapitule pour y voir plus clair
1. Fichier excel : 7 onglets 2. Transformation du 1 en 7 fichiers excel 3. Liaison des 7 fichiers à access via les tables attachées (7 tables attachées) 4. Remplissage de 7 tables access locales par code VB avec controle des données 5. A partir d'excel : requête ODBC vers les 7 tables access locales et rappatriement des données dans 7 onglets d'excel => Perte du tri
Si j'ai tout bon alors on continue
Ma question est : comment se fait il que mes enregistrements arrivent tous triés sans critere de tri dans les requetes ODBC pour 6 onglet et pas pour le 7eme. Ta requête ODBC pour la 7ème table est elle strictement identique aux 6 autres ?
Si oui, je contournerai le problème en rajoutant en 1ere position une colonne incrémentée dans Excel (cela devrait suffire sans avoir à modifier tes requêtes ODBC, le tri devrait être rspecté) (et en cas de problème je reparametrerai les requêtes ODBC en forçant le tri sur cette colonne)
Qu’est ce qui determine l’ordre d’arrivé des enregistrement lors d’un SELECT ? S'il n'y a pas de tri particulier, les enregistrements sont traitées dans l'ordre dans lequel ils
se présentent. Saches qu'access n'aime pas trop traviller sur des tables sans cle NumeroAuto, c'est pour cela qui si tu crée une table sans cle, il te propose de crée un champ NumeroAuto automatiquement. Donc je modifierai les tables access en local en y rajoutant ce champ NumeroAuto qui ne te seras d'aucune utilité directe mais te permettra de conserver le tri
Ouala Bye Buddy
Tout d’abord je cerne l’application. J’alimente de données les differents onglets d’un fichier Excel. (Fichier_org.xls) Les données de ces onglets sont copiées dans un fichier Excel portant le nom de l’onglet d’où elles proviennent. Dans mon cas, il en existe donc 7. (ong1.xls a ong7.xls) Ces 7 fichiers Excel sont lié a une base Acces (on y arrive) et apparaissent donc sous Acces sous forme de fichier Excel dont il est impossible de modifier le format. On importe les données de ces 7 fichier Excel liés dans des tables Acces du meme format via une requete imbriquée (*7) dans Acces du type Insert Into table1 (champ1......)(select champ1 ..... from ong1 ))
Je choisi de passer par une procedure VB pour un contrôle plus poussé du contenu d’un fichier. De ce fait, la procedure se compose en 3 morceaux : principaux - Select champ1,…… from ong1 - ouverture du recordset - lecture sequentielle du recordset o verification des données o Table1.Addnew - et ceci jusque la fin du recordset.
Donc a la fin de la mise a jour de la base, on a 7 tables a l’image des 7 fichiers Excel liés, soit Table1 a Table7
Ceci fait, on exporte les données de ces tables dans un onglet d’un fichier Excel. Donc on retrouve nos 7 tables dans 7 onglets d’un nouveau fichier Excel (Fichier_global.xls). ces données sont inserées dans chacun des onglets via une requetes ODBC attaché a chaque onglet. A chaque ouverture de Fichier_global.xls, les requetes vont cherchée les enregistrement dans les 7 tables concernées.
Debut du pb : Avant l’ajout de la procedure VB pour un fichier en particulier, Tous les onglets avaient la meme disposition :
dans le Fichier_org.xls , pour tous les onglets, les données sont saisie dans cet ordre : Donnée 1 Donnée 2 Donnée 3 Donnée 4 Elles sont copiées dans le fichier excel ong1.xls dans cet ordre ( je ne prends qu’un fchier en exple) Elles sont insérée dans la table via la requete imbriqué dans cet ordre Lorsque j’ouvre le Fichier_global.xls, les données se retrouvent dans cet ordre dans chaque onglet, bien qu’il n’y ai aucun critere de tri dans la requete ODBC.
Apres la procedure VB particuliere pour un fichier excel lié , les données de ce fameux fichier Arrivent dans le Fichier_global.xls dans le desordre. Ma question est : comment se fait il que mes enregistrements arrivent tous triés sans critere de tri dans les requetes ODBC pour 6 onglet et pas pour le 7eme. La seule différence est cette procedure VB. Qu’est ce qui determine l’ordre d’arrivé des enregistrement lors d’un SELECT ? Je ne sais comment marche Acces en interne mais, y aurait il un index incrementé dans le cas de ma requete imbriqué et pas dans le cas de la procedure VB ? ( alors que le resultat final dans la table est le meme)
n'hesitez pas a me demander si quelque chose n'est pas clair. bien a vous
