Bonjour,
J'aurais dû y penser, il est logique d'écrire "VOI/TUR/E /ROU/GE", et puis, ça a une autre gueule que "VOITURE ROUGE"
Je taquine :-)
Content que ton problème soit réglé.
Pour ton autre problème, je l'ai retrouvé sur Google. Si j'ai bien compris, tu veux exporter des données d'une table contenue dans
une base Access vers une table contenue dans une base ORACLE.
Le problème, c'est que le pilote ODBC est fourni par ORACLE, et que les fonctionnalités supportées ne sont pas nécessairement les
mêmes que celles supportées, par exemple, par un pilote SQLServer, et que la syntaxe peut parfois être différente, en particulier
pour ce qui concerne la définition des données. Et je ne connais pas Oracle...
L'autre problème, c'est que tu parles de macros, je ne les utilise plus depuis des années, le code VBA les remplace avantageusement.
Enfin, ce genre de choses se fait avec ADO.
Ma première remarque, si j'ai bien compris, c'est qu'il n'est pas nécessaire de supprimer la table et de la recréer, il suffit de
supprimer toutes les lignes et de les recharger dans ta table, soit une requête DELETE suivie d'une requête INSERT. Plus de DROP qui
implique de redéfinir la table. Avantages, meilleure performance, et la garantie que pour ce genre d'opérations, les fonctionnalités
et la syntaxe sont les mêmes.
Le plus simple serait peut-être d'ouvrir un nouveau fil, en réexpliquant ce que tu veux faire et en publiant ton code, je suis sans
doute le seul à suivre encore ce fil, un nouveau fil sera lu par d'autres personnes, ce qui augmentera tes chances de réponses.
J-Pierre
Bonjour,
J'aurais dû y penser, il est logique d'écrire "VOI/TUR/E /ROU/GE", et puis, ça a une autre gueule que "VOITURE ROUGE"
Je taquine :-)
Content que ton problème soit réglé.
Pour ton autre problème, je l'ai retrouvé sur Google. Si j'ai bien compris, tu veux exporter des données d'une table contenue dans
une base Access vers une table contenue dans une base ORACLE.
Le problème, c'est que le pilote ODBC est fourni par ORACLE, et que les fonctionnalités supportées ne sont pas nécessairement les
mêmes que celles supportées, par exemple, par un pilote SQLServer, et que la syntaxe peut parfois être différente, en particulier
pour ce qui concerne la définition des données. Et je ne connais pas Oracle...
L'autre problème, c'est que tu parles de macros, je ne les utilise plus depuis des années, le code VBA les remplace avantageusement.
Enfin, ce genre de choses se fait avec ADO.
Ma première remarque, si j'ai bien compris, c'est qu'il n'est pas nécessaire de supprimer la table et de la recréer, il suffit de
supprimer toutes les lignes et de les recharger dans ta table, soit une requête DELETE suivie d'une requête INSERT. Plus de DROP qui
implique de redéfinir la table. Avantages, meilleure performance, et la garantie que pour ce genre d'opérations, les fonctionnalités
et la syntaxe sont les mêmes.
Le plus simple serait peut-être d'ouvrir un nouveau fil, en réexpliquant ce que tu veux faire et en publiant ton code, je suis sans
doute le seul à suivre encore ce fil, un nouveau fil sera lu par d'autres personnes, ce qui augmentera tes chances de réponses.
J-Pierre
Bonjour,
J'aurais dû y penser, il est logique d'écrire "VOI/TUR/E /ROU/GE", et puis, ça a une autre gueule que "VOITURE ROUGE"
Je taquine :-)
Content que ton problème soit réglé.
Pour ton autre problème, je l'ai retrouvé sur Google. Si j'ai bien compris, tu veux exporter des données d'une table contenue dans
une base Access vers une table contenue dans une base ORACLE.
Le problème, c'est que le pilote ODBC est fourni par ORACLE, et que les fonctionnalités supportées ne sont pas nécessairement les
mêmes que celles supportées, par exemple, par un pilote SQLServer, et que la syntaxe peut parfois être différente, en particulier
pour ce qui concerne la définition des données. Et je ne connais pas Oracle...
L'autre problème, c'est que tu parles de macros, je ne les utilise plus depuis des années, le code VBA les remplace avantageusement.
Enfin, ce genre de choses se fait avec ADO.
Ma première remarque, si j'ai bien compris, c'est qu'il n'est pas nécessaire de supprimer la table et de la recréer, il suffit de
supprimer toutes les lignes et de les recharger dans ta table, soit une requête DELETE suivie d'une requête INSERT. Plus de DROP qui
implique de redéfinir la table. Avantages, meilleure performance, et la garantie que pour ce genre d'opérations, les fonctionnalités
et la syntaxe sont les mêmes.
Le plus simple serait peut-être d'ouvrir un nouveau fil, en réexpliquant ce que tu veux faire et en publiant ton code, je suis sans
doute le seul à suivre encore ce fil, un nouveau fil sera lu par d'autres personnes, ce qui augmentera tes chances de réponses.
J-Pierre
Je viens de finaliser l'ensemble des requètes pour mettre à jour toutes mes
tables en droite ligne de tes conseils et de ce que nous avons arreté
Mais une déconvenue non négligeable apparait
Alors que pour l'ancienne procédure avec saucissonnage au niveau de l'import
mes tables sont alimentés en 45 secondes là un délais de 3 minutes est
nécessaire pour obtenir l'équivalent
En disséquant le processus l'implantation des nouvelles données en utilisant
la fonction intégrée "ExtracChaîne" pour certaine table comprenant 7 champs
est particulièrement couteuse en délais
Pour ton info lorque je consulte les instruction en affichage SQL la
fonction est retranscrit "Mid([Fichier ancien]![Données],1,8)
Ce qui est surpprenant c'est qu'alors que l'affichage des données obtenues
de la requètes Ajout est trés rapide l'intégration dans la table de
destination est trés longue
Que peut on faire pour raccourcir le temps de traitement car
à ce stade la réalisation de l'opération par les 14 imports est plus
intérressante
Je suis désolé mais je fondais tant d'espoire sur cette solution trouvée
Merci de ta réponse sur mes problèmes ODBC
Je verrais la question ultètieurement, la difficulté n'étant pas
rhédibitoire mais handicapante ma vigilance restant ma seule arme contreBonjour,
J'aurais dû y penser, il est logique d'écrire "VOI/TUR/E /ROU/GE", et puis, ça a une autre gueule que "VOITURE ROUGE"
Je taquine :-)
Content que ton problème soit réglé.
Pour ton autre problème, je l'ai retrouvé sur Google. Si j'ai bien compris, tu veux exporter des données d'une table contenue
dans
une base Access vers une table contenue dans une base ORACLE.
Le problème, c'est que le pilote ODBC est fourni par ORACLE, et que les fonctionnalités supportées ne sont pas nécessairement les
mêmes que celles supportées, par exemple, par un pilote SQLServer, et que la syntaxe peut parfois être différente, en particulier
pour ce qui concerne la définition des données. Et je ne connais pas Oracle...
L'autre problème, c'est que tu parles de macros, je ne les utilise plus depuis des années, le code VBA les remplace
avantageusement.
Enfin, ce genre de choses se fait avec ADO.
Ma première remarque, si j'ai bien compris, c'est qu'il n'est pas nécessaire de supprimer la table et de la recréer, il suffit de
supprimer toutes les lignes et de les recharger dans ta table, soit une requête DELETE suivie d'une requête INSERT. Plus de DROP
qui
implique de redéfinir la table. Avantages, meilleure performance, et la garantie que pour ce genre d'opérations, les
fonctionnalités
et la syntaxe sont les mêmes.
Le plus simple serait peut-être d'ouvrir un nouveau fil, en réexpliquant ce que tu veux faire et en publiant ton code, je suis
sans
doute le seul à suivre encore ce fil, un nouveau fil sera lu par d'autres personnes, ce qui augmentera tes chances de réponses.
J-Pierre
Je viens de finaliser l'ensemble des requètes pour mettre à jour toutes mes
tables en droite ligne de tes conseils et de ce que nous avons arreté
Mais une déconvenue non négligeable apparait
Alors que pour l'ancienne procédure avec saucissonnage au niveau de l'import
mes tables sont alimentés en 45 secondes là un délais de 3 minutes est
nécessaire pour obtenir l'équivalent
En disséquant le processus l'implantation des nouvelles données en utilisant
la fonction intégrée "ExtracChaîne" pour certaine table comprenant 7 champs
est particulièrement couteuse en délais
Pour ton info lorque je consulte les instruction en affichage SQL la
fonction est retranscrit "Mid([Fichier ancien]![Données],1,8)
Ce qui est surpprenant c'est qu'alors que l'affichage des données obtenues
de la requètes Ajout est trés rapide l'intégration dans la table de
destination est trés longue
Que peut on faire pour raccourcir le temps de traitement car
à ce stade la réalisation de l'opération par les 14 imports est plus
intérressante
Je suis désolé mais je fondais tant d'espoire sur cette solution trouvée
Merci de ta réponse sur mes problèmes ODBC
Je verrais la question ultètieurement, la difficulté n'étant pas
rhédibitoire mais handicapante ma vigilance restant ma seule arme contre
Bonjour,
J'aurais dû y penser, il est logique d'écrire "VOI/TUR/E /ROU/GE", et puis, ça a une autre gueule que "VOITURE ROUGE"
Je taquine :-)
Content que ton problème soit réglé.
Pour ton autre problème, je l'ai retrouvé sur Google. Si j'ai bien compris, tu veux exporter des données d'une table contenue
dans
une base Access vers une table contenue dans une base ORACLE.
Le problème, c'est que le pilote ODBC est fourni par ORACLE, et que les fonctionnalités supportées ne sont pas nécessairement les
mêmes que celles supportées, par exemple, par un pilote SQLServer, et que la syntaxe peut parfois être différente, en particulier
pour ce qui concerne la définition des données. Et je ne connais pas Oracle...
L'autre problème, c'est que tu parles de macros, je ne les utilise plus depuis des années, le code VBA les remplace
avantageusement.
Enfin, ce genre de choses se fait avec ADO.
Ma première remarque, si j'ai bien compris, c'est qu'il n'est pas nécessaire de supprimer la table et de la recréer, il suffit de
supprimer toutes les lignes et de les recharger dans ta table, soit une requête DELETE suivie d'une requête INSERT. Plus de DROP
qui
implique de redéfinir la table. Avantages, meilleure performance, et la garantie que pour ce genre d'opérations, les
fonctionnalités
et la syntaxe sont les mêmes.
Le plus simple serait peut-être d'ouvrir un nouveau fil, en réexpliquant ce que tu veux faire et en publiant ton code, je suis
sans
doute le seul à suivre encore ce fil, un nouveau fil sera lu par d'autres personnes, ce qui augmentera tes chances de réponses.
J-Pierre
Je viens de finaliser l'ensemble des requètes pour mettre à jour toutes mes
tables en droite ligne de tes conseils et de ce que nous avons arreté
Mais une déconvenue non négligeable apparait
Alors que pour l'ancienne procédure avec saucissonnage au niveau de l'import
mes tables sont alimentés en 45 secondes là un délais de 3 minutes est
nécessaire pour obtenir l'équivalent
En disséquant le processus l'implantation des nouvelles données en utilisant
la fonction intégrée "ExtracChaîne" pour certaine table comprenant 7 champs
est particulièrement couteuse en délais
Pour ton info lorque je consulte les instruction en affichage SQL la
fonction est retranscrit "Mid([Fichier ancien]![Données],1,8)
Ce qui est surpprenant c'est qu'alors que l'affichage des données obtenues
de la requètes Ajout est trés rapide l'intégration dans la table de
destination est trés longue
Que peut on faire pour raccourcir le temps de traitement car
à ce stade la réalisation de l'opération par les 14 imports est plus
intérressante
Je suis désolé mais je fondais tant d'espoire sur cette solution trouvée
Merci de ta réponse sur mes problèmes ODBC
Je verrais la question ultètieurement, la difficulté n'étant pas
rhédibitoire mais handicapante ma vigilance restant ma seule arme contreBonjour,
J'aurais dû y penser, il est logique d'écrire "VOI/TUR/E /ROU/GE", et puis, ça a une autre gueule que "VOITURE ROUGE"
Je taquine :-)
Content que ton problème soit réglé.
Pour ton autre problème, je l'ai retrouvé sur Google. Si j'ai bien compris, tu veux exporter des données d'une table contenue
dans
une base Access vers une table contenue dans une base ORACLE.
Le problème, c'est que le pilote ODBC est fourni par ORACLE, et que les fonctionnalités supportées ne sont pas nécessairement les
mêmes que celles supportées, par exemple, par un pilote SQLServer, et que la syntaxe peut parfois être différente, en particulier
pour ce qui concerne la définition des données. Et je ne connais pas Oracle...
L'autre problème, c'est que tu parles de macros, je ne les utilise plus depuis des années, le code VBA les remplace
avantageusement.
Enfin, ce genre de choses se fait avec ADO.
Ma première remarque, si j'ai bien compris, c'est qu'il n'est pas nécessaire de supprimer la table et de la recréer, il suffit de
supprimer toutes les lignes et de les recharger dans ta table, soit une requête DELETE suivie d'une requête INSERT. Plus de DROP
qui
implique de redéfinir la table. Avantages, meilleure performance, et la garantie que pour ce genre d'opérations, les
fonctionnalités
et la syntaxe sont les mêmes.
Le plus simple serait peut-être d'ouvrir un nouveau fil, en réexpliquant ce que tu veux faire et en publiant ton code, je suis
sans
doute le seul à suivre encore ce fil, un nouveau fil sera lu par d'autres personnes, ce qui augmentera tes chances de réponses.
J-Pierre
Je ne savais pas que l'instruction MID était si lente.... et je suis un peu surpris. Si tu veux, tu peux m'envoyer ta base avec le
fichier texte à importer, parce que comme ça, je n'ai pas d'idées.
J-Pierre
"FFO" a écrit dans le message de news:Je viens de finaliser l'ensemble des requètes pour mettre à jour toutes mes
tables en droite ligne de tes conseils et de ce que nous avons arreté
Mais une déconvenue non négligeable apparait
Alors que pour l'ancienne procédure avec saucissonnage au niveau de l'import
mes tables sont alimentés en 45 secondes là un délais de 3 minutes est
nécessaire pour obtenir l'équivalent
En disséquant le processus l'implantation des nouvelles données en utilisant
la fonction intégrée "ExtracChaîne" pour certaine table comprenant 7 champs
est particulièrement couteuse en délais
Pour ton info lorque je consulte les instruction en affichage SQL la
fonction est retranscrit "Mid([Fichier ancien]![Données],1,8)
Ce qui est surpprenant c'est qu'alors que l'affichage des données obtenues
de la requètes Ajout est trés rapide l'intégration dans la table de
destination est trés longue
Que peut on faire pour raccourcir le temps de traitement car
à ce stade la réalisation de l'opération par les 14 imports est plus
intérressante
Je suis désolé mais je fondais tant d'espoire sur cette solution trouvée
Merci de ta réponse sur mes problèmes ODBC
Je verrais la question ultètieurement, la difficulté n'étant pas
rhédibitoire mais handicapante ma vigilance restant ma seule arme contreBonjour,
J'aurais dû y penser, il est logique d'écrire "VOI/TUR/E /ROU/GE", et puis, ça a une autre gueule que "VOITURE ROUGE"
Je taquine :-)
Content que ton problème soit réglé.
Pour ton autre problème, je l'ai retrouvé sur Google. Si j'ai bien compris, tu veux exporter des données d'une table contenue
dans
une base Access vers une table contenue dans une base ORACLE.
Le problème, c'est que le pilote ODBC est fourni par ORACLE, et que les fonctionnalités supportées ne sont pas nécessairement les
mêmes que celles supportées, par exemple, par un pilote SQLServer, et que la syntaxe peut parfois être différente, en particulier
pour ce qui concerne la définition des données. Et je ne connais pas Oracle...
L'autre problème, c'est que tu parles de macros, je ne les utilise plus depuis des années, le code VBA les remplace
avantageusement.
Enfin, ce genre de choses se fait avec ADO.
Ma première remarque, si j'ai bien compris, c'est qu'il n'est pas nécessaire de supprimer la table et de la recréer, il suffit de
supprimer toutes les lignes et de les recharger dans ta table, soit une requête DELETE suivie d'une requête INSERT. Plus de DROP
qui
implique de redéfinir la table. Avantages, meilleure performance, et la garantie que pour ce genre d'opérations, les
fonctionnalités
et la syntaxe sont les mêmes.
Le plus simple serait peut-être d'ouvrir un nouveau fil, en réexpliquant ce que tu veux faire et en publiant ton code, je suis
sans
doute le seul à suivre encore ce fil, un nouveau fil sera lu par d'autres personnes, ce qui augmentera tes chances de réponses.
J-Pierre
Je ne savais pas que l'instruction MID était si lente.... et je suis un peu surpris. Si tu veux, tu peux m'envoyer ta base avec le
fichier texte à importer, parce que comme ça, je n'ai pas d'idées.
J-Pierre
"FFO" <FFO@discussions.microsoft.com> a écrit dans le message de news: 8892A1DD-4F0E-45BB-992F-DCF428AE65E6@microsoft.com...
Je viens de finaliser l'ensemble des requètes pour mettre à jour toutes mes
tables en droite ligne de tes conseils et de ce que nous avons arreté
Mais une déconvenue non négligeable apparait
Alors que pour l'ancienne procédure avec saucissonnage au niveau de l'import
mes tables sont alimentés en 45 secondes là un délais de 3 minutes est
nécessaire pour obtenir l'équivalent
En disséquant le processus l'implantation des nouvelles données en utilisant
la fonction intégrée "ExtracChaîne" pour certaine table comprenant 7 champs
est particulièrement couteuse en délais
Pour ton info lorque je consulte les instruction en affichage SQL la
fonction est retranscrit "Mid([Fichier ancien]![Données],1,8)
Ce qui est surpprenant c'est qu'alors que l'affichage des données obtenues
de la requètes Ajout est trés rapide l'intégration dans la table de
destination est trés longue
Que peut on faire pour raccourcir le temps de traitement car
à ce stade la réalisation de l'opération par les 14 imports est plus
intérressante
Je suis désolé mais je fondais tant d'espoire sur cette solution trouvée
Merci de ta réponse sur mes problèmes ODBC
Je verrais la question ultètieurement, la difficulté n'étant pas
rhédibitoire mais handicapante ma vigilance restant ma seule arme contre
Bonjour,
J'aurais dû y penser, il est logique d'écrire "VOI/TUR/E /ROU/GE", et puis, ça a une autre gueule que "VOITURE ROUGE"
Je taquine :-)
Content que ton problème soit réglé.
Pour ton autre problème, je l'ai retrouvé sur Google. Si j'ai bien compris, tu veux exporter des données d'une table contenue
dans
une base Access vers une table contenue dans une base ORACLE.
Le problème, c'est que le pilote ODBC est fourni par ORACLE, et que les fonctionnalités supportées ne sont pas nécessairement les
mêmes que celles supportées, par exemple, par un pilote SQLServer, et que la syntaxe peut parfois être différente, en particulier
pour ce qui concerne la définition des données. Et je ne connais pas Oracle...
L'autre problème, c'est que tu parles de macros, je ne les utilise plus depuis des années, le code VBA les remplace
avantageusement.
Enfin, ce genre de choses se fait avec ADO.
Ma première remarque, si j'ai bien compris, c'est qu'il n'est pas nécessaire de supprimer la table et de la recréer, il suffit de
supprimer toutes les lignes et de les recharger dans ta table, soit une requête DELETE suivie d'une requête INSERT. Plus de DROP
qui
implique de redéfinir la table. Avantages, meilleure performance, et la garantie que pour ce genre d'opérations, les
fonctionnalités
et la syntaxe sont les mêmes.
Le plus simple serait peut-être d'ouvrir un nouveau fil, en réexpliquant ce que tu veux faire et en publiant ton code, je suis
sans
doute le seul à suivre encore ce fil, un nouveau fil sera lu par d'autres personnes, ce qui augmentera tes chances de réponses.
J-Pierre
Je ne savais pas que l'instruction MID était si lente.... et je suis un peu surpris. Si tu veux, tu peux m'envoyer ta base avec le
fichier texte à importer, parce que comme ça, je n'ai pas d'idées.
J-Pierre
"FFO" a écrit dans le message de news:Je viens de finaliser l'ensemble des requètes pour mettre à jour toutes mes
tables en droite ligne de tes conseils et de ce que nous avons arreté
Mais une déconvenue non négligeable apparait
Alors que pour l'ancienne procédure avec saucissonnage au niveau de l'import
mes tables sont alimentés en 45 secondes là un délais de 3 minutes est
nécessaire pour obtenir l'équivalent
En disséquant le processus l'implantation des nouvelles données en utilisant
la fonction intégrée "ExtracChaîne" pour certaine table comprenant 7 champs
est particulièrement couteuse en délais
Pour ton info lorque je consulte les instruction en affichage SQL la
fonction est retranscrit "Mid([Fichier ancien]![Données],1,8)
Ce qui est surpprenant c'est qu'alors que l'affichage des données obtenues
de la requètes Ajout est trés rapide l'intégration dans la table de
destination est trés longue
Que peut on faire pour raccourcir le temps de traitement car
à ce stade la réalisation de l'opération par les 14 imports est plus
intérressante
Je suis désolé mais je fondais tant d'espoire sur cette solution trouvée
Merci de ta réponse sur mes problèmes ODBC
Je verrais la question ultètieurement, la difficulté n'étant pas
rhédibitoire mais handicapante ma vigilance restant ma seule arme contreBonjour,
J'aurais dû y penser, il est logique d'écrire "VOI/TUR/E /ROU/GE", et puis, ça a une autre gueule que "VOITURE ROUGE"
Je taquine :-)
Content que ton problème soit réglé.
Pour ton autre problème, je l'ai retrouvé sur Google. Si j'ai bien compris, tu veux exporter des données d'une table contenue
dans
une base Access vers une table contenue dans une base ORACLE.
Le problème, c'est que le pilote ODBC est fourni par ORACLE, et que les fonctionnalités supportées ne sont pas nécessairement les
mêmes que celles supportées, par exemple, par un pilote SQLServer, et que la syntaxe peut parfois être différente, en particulier
pour ce qui concerne la définition des données. Et je ne connais pas Oracle...
L'autre problème, c'est que tu parles de macros, je ne les utilise plus depuis des années, le code VBA les remplace
avantageusement.
Enfin, ce genre de choses se fait avec ADO.
Ma première remarque, si j'ai bien compris, c'est qu'il n'est pas nécessaire de supprimer la table et de la recréer, il suffit de
supprimer toutes les lignes et de les recharger dans ta table, soit une requête DELETE suivie d'une requête INSERT. Plus de DROP
qui
implique de redéfinir la table. Avantages, meilleure performance, et la garantie que pour ce genre d'opérations, les
fonctionnalités
et la syntaxe sont les mêmes.
Le plus simple serait peut-être d'ouvrir un nouveau fil, en réexpliquant ce que tu veux faire et en publiant ton code, je suis
sans
doute le seul à suivre encore ce fil, un nouveau fil sera lu par d'autres personnes, ce qui augmentera tes chances de réponses.
J-Pierre
Comment te faire parvenir la base sachant que réduite à son strict minimum à
savoir 2 fichiers d'import 2 tables à alimenter (les plus significatives en
terme d'importance et de délais) et 2 requètes pour inclure les données de
l'une à l'autre je reste malgré tout avec une taille de 11 Méga octets à te
transmettre
Merci pour tes suggestions
Comment te faire parvenir la base sachant que réduite à son strict minimum à
savoir 2 fichiers d'import 2 tables à alimenter (les plus significatives en
terme d'importance et de délais) et 2 requètes pour inclure les données de
l'une à l'autre je reste malgré tout avec une taille de 11 Méga octets à te
transmettre
Merci pour tes suggestions
Comment te faire parvenir la base sachant que réduite à son strict minimum à
savoir 2 fichiers d'import 2 tables à alimenter (les plus significatives en
terme d'importance et de délais) et 2 requètes pour inclure les données de
l'une à l'autre je reste malgré tout avec une taille de 11 Méga octets à te
transmettre
Merci pour tes suggestions
Comment te faire parvenir la base sachant que réduite à son strict minimum à
savoir 2 fichiers d'import 2 tables à alimenter (les plus significatives en
terme d'importance et de délais) et 2 requètes pour inclure les données de
l'une à l'autre je reste malgré tout avec une taille de 11 Méga octets à te
transmettre
Merci pour tes suggestions
Comment te faire parvenir la base sachant que réduite à son strict minimum à
savoir 2 fichiers d'import 2 tables à alimenter (les plus significatives en
terme d'importance et de délais) et 2 requètes pour inclure les données de
l'une à l'autre je reste malgré tout avec une taille de 11 Méga octets à te
transmettre
Merci pour tes suggestions
Comment te faire parvenir la base sachant que réduite à son strict minimum à
savoir 2 fichiers d'import 2 tables à alimenter (les plus significatives en
terme d'importance et de délais) et 2 requètes pour inclure les données de
l'une à l'autre je reste malgré tout avec une taille de 11 Méga octets à te
transmettre
Merci pour tes suggestions
11 megs après compression et zippage ? !!!!!!!!!!!
Si tu es chez Free, tu peux me passer des fichiers jusqu'à un Giga.
Sinon, coupe ta base en 2-3 bases et envoie-les moi une par une, je la reconstituerai.
J-Pierre
"FFO" a écrit dans le message de news:Comment te faire parvenir la base sachant que réduite à son strict minimum à
savoir 2 fichiers d'import 2 tables à alimenter (les plus significatives en
terme d'importance et de délais) et 2 requètes pour inclure les données de
l'une à l'autre je reste malgré tout avec une taille de 11 Méga octets à te
transmettre
Merci pour tes suggestions
11 megs après compression et zippage ? !!!!!!!!!!!
Si tu es chez Free, tu peux me passer des fichiers jusqu'à un Giga.
Sinon, coupe ta base en 2-3 bases et envoie-les moi une par une, je la reconstituerai.
J-Pierre
"FFO" <FFO@discussions.microsoft.com> a écrit dans le message de news: 6D614182-53B2-476A-A340-D665AE4EF7B9@microsoft.com...
Comment te faire parvenir la base sachant que réduite à son strict minimum à
savoir 2 fichiers d'import 2 tables à alimenter (les plus significatives en
terme d'importance et de délais) et 2 requètes pour inclure les données de
l'une à l'autre je reste malgré tout avec une taille de 11 Méga octets à te
transmettre
Merci pour tes suggestions
11 megs après compression et zippage ? !!!!!!!!!!!
Si tu es chez Free, tu peux me passer des fichiers jusqu'à un Giga.
Sinon, coupe ta base en 2-3 bases et envoie-les moi une par une, je la reconstituerai.
J-Pierre
"FFO" a écrit dans le message de news:Comment te faire parvenir la base sachant que réduite à son strict minimum à
savoir 2 fichiers d'import 2 tables à alimenter (les plus significatives en
terme d'importance et de délais) et 2 requètes pour inclure les données de
l'une à l'autre je reste malgré tout avec une taille de 11 Méga octets à te
transmettre
Merci pour tes suggestions
Je t'envoie juste la base access inutile d'y joindre les 2 fichiers à
importer le pb se situant au niveau de l'alimentation des tables à partir des
données importées présent dans cette base avec la fonction extractchaine (15
secondes de traitement par table avec la nouvelle procédure au lieu de 2
secondes avec l'ancienne sachant que 14 tables sont concernées par le même
traitement bonjour le délais)
Comment te le faire parvenir, à quelle adresse ???
J'ai réussi une petite cure d'amaigrissement en Zipant la base pour obtenir
un fichier de 783 Ko11 megs après compression et zippage ? !!!!!!!!!!!
Si tu es chez Free, tu peux me passer des fichiers jusqu'à un Giga.
Sinon, coupe ta base en 2-3 bases et envoie-les moi une par une, je la reconstituerai.
J-Pierre
"FFO" a écrit dans le message de news:Comment te faire parvenir la base sachant que réduite à son strict minimum à
savoir 2 fichiers d'import 2 tables à alimenter (les plus significatives en
terme d'importance et de délais) et 2 requètes pour inclure les données de
l'une à l'autre je reste malgré tout avec une taille de 11 Méga octets à te
transmettre
Merci pour tes suggestions
Je t'envoie juste la base access inutile d'y joindre les 2 fichiers à
importer le pb se situant au niveau de l'alimentation des tables à partir des
données importées présent dans cette base avec la fonction extractchaine (15
secondes de traitement par table avec la nouvelle procédure au lieu de 2
secondes avec l'ancienne sachant que 14 tables sont concernées par le même
traitement bonjour le délais)
Comment te le faire parvenir, à quelle adresse ???
J'ai réussi une petite cure d'amaigrissement en Zipant la base pour obtenir
un fichier de 783 Ko
11 megs après compression et zippage ? !!!!!!!!!!!
Si tu es chez Free, tu peux me passer des fichiers jusqu'à un Giga.
Sinon, coupe ta base en 2-3 bases et envoie-les moi une par une, je la reconstituerai.
J-Pierre
"FFO" <FFO@discussions.microsoft.com> a écrit dans le message de news: 6D614182-53B2-476A-A340-D665AE4EF7B9@microsoft.com...
Comment te faire parvenir la base sachant que réduite à son strict minimum à
savoir 2 fichiers d'import 2 tables à alimenter (les plus significatives en
terme d'importance et de délais) et 2 requètes pour inclure les données de
l'une à l'autre je reste malgré tout avec une taille de 11 Méga octets à te
transmettre
Merci pour tes suggestions
Je t'envoie juste la base access inutile d'y joindre les 2 fichiers à
importer le pb se situant au niveau de l'alimentation des tables à partir des
données importées présent dans cette base avec la fonction extractchaine (15
secondes de traitement par table avec la nouvelle procédure au lieu de 2
secondes avec l'ancienne sachant que 14 tables sont concernées par le même
traitement bonjour le délais)
Comment te le faire parvenir, à quelle adresse ???
J'ai réussi une petite cure d'amaigrissement en Zipant la base pour obtenir
un fichier de 783 Ko11 megs après compression et zippage ? !!!!!!!!!!!
Si tu es chez Free, tu peux me passer des fichiers jusqu'à un Giga.
Sinon, coupe ta base en 2-3 bases et envoie-les moi une par une, je la reconstituerai.
J-Pierre
"FFO" a écrit dans le message de news:Comment te faire parvenir la base sachant que réduite à son strict minimum à
savoir 2 fichiers d'import 2 tables à alimenter (les plus significatives en
terme d'importance et de délais) et 2 requètes pour inclure les données de
l'une à l'autre je reste malgré tout avec une taille de 11 Méga octets à te
transmettre
Merci pour tes suggestions
Bonjour,
Avec quelques mots d'explications sur les tables et les requêtes utilisées ? :-)
--
J-Pierre
----------------------------------------------------------
J'organise un grand concours de chèques à mon nom. Le plus gros a gagné.
(Coluche)
----------------------------------------------------------
"FFO" a écrit dans le message de news:Je t'envoie juste la base access inutile d'y joindre les 2 fichiers à
importer le pb se situant au niveau de l'alimentation des tables à partir des
données importées présent dans cette base avec la fonction extractchaine (15
secondes de traitement par table avec la nouvelle procédure au lieu de 2
secondes avec l'ancienne sachant que 14 tables sont concernées par le même
traitement bonjour le délais)
Comment te le faire parvenir, à quelle adresse ???
J'ai réussi une petite cure d'amaigrissement en Zipant la base pour obtenir
un fichier de 783 Ko11 megs après compression et zippage ? !!!!!!!!!!!
Si tu es chez Free, tu peux me passer des fichiers jusqu'à un Giga.
Sinon, coupe ta base en 2-3 bases et envoie-les moi une par une, je la reconstituerai.
J-Pierre
"FFO" a écrit dans le message de news:Comment te faire parvenir la base sachant que réduite à son strict minimum à
savoir 2 fichiers d'import 2 tables à alimenter (les plus significatives en
terme d'importance et de délais) et 2 requètes pour inclure les données de
l'une à l'autre je reste malgré tout avec une taille de 11 Méga octets à te
transmettre
Merci pour tes suggestions
Bonjour,
pas.de.pub.jpberchtold@hotmail.com
Avec quelques mots d'explications sur les tables et les requêtes utilisées ? :-)
--
J-Pierre
----------------------------------------------------------
J'organise un grand concours de chèques à mon nom. Le plus gros a gagné.
(Coluche)
----------------------------------------------------------
"FFO" <FFO@discussions.microsoft.com> a écrit dans le message de news: B31CA6EF-0238-46C8-9ECA-36059E1DAC61@microsoft.com...
Je t'envoie juste la base access inutile d'y joindre les 2 fichiers à
importer le pb se situant au niveau de l'alimentation des tables à partir des
données importées présent dans cette base avec la fonction extractchaine (15
secondes de traitement par table avec la nouvelle procédure au lieu de 2
secondes avec l'ancienne sachant que 14 tables sont concernées par le même
traitement bonjour le délais)
Comment te le faire parvenir, à quelle adresse ???
J'ai réussi une petite cure d'amaigrissement en Zipant la base pour obtenir
un fichier de 783 Ko
11 megs après compression et zippage ? !!!!!!!!!!!
Si tu es chez Free, tu peux me passer des fichiers jusqu'à un Giga.
Sinon, coupe ta base en 2-3 bases et envoie-les moi une par une, je la reconstituerai.
J-Pierre
"FFO" <FFO@discussions.microsoft.com> a écrit dans le message de news: 6D614182-53B2-476A-A340-D665AE4EF7B9@microsoft.com...
Comment te faire parvenir la base sachant que réduite à son strict minimum à
savoir 2 fichiers d'import 2 tables à alimenter (les plus significatives en
terme d'importance et de délais) et 2 requètes pour inclure les données de
l'une à l'autre je reste malgré tout avec une taille de 11 Méga octets à te
transmettre
Merci pour tes suggestions
Bonjour,
Avec quelques mots d'explications sur les tables et les requêtes utilisées ? :-)
--
J-Pierre
----------------------------------------------------------
J'organise un grand concours de chèques à mon nom. Le plus gros a gagné.
(Coluche)
----------------------------------------------------------
"FFO" a écrit dans le message de news:Je t'envoie juste la base access inutile d'y joindre les 2 fichiers à
importer le pb se situant au niveau de l'alimentation des tables à partir des
données importées présent dans cette base avec la fonction extractchaine (15
secondes de traitement par table avec la nouvelle procédure au lieu de 2
secondes avec l'ancienne sachant que 14 tables sont concernées par le même
traitement bonjour le délais)
Comment te le faire parvenir, à quelle adresse ???
J'ai réussi une petite cure d'amaigrissement en Zipant la base pour obtenir
un fichier de 783 Ko11 megs après compression et zippage ? !!!!!!!!!!!
Si tu es chez Free, tu peux me passer des fichiers jusqu'à un Giga.
Sinon, coupe ta base en 2-3 bases et envoie-les moi une par une, je la reconstituerai.
J-Pierre
"FFO" a écrit dans le message de news:Comment te faire parvenir la base sachant que réduite à son strict minimum à
savoir 2 fichiers d'import 2 tables à alimenter (les plus significatives en
terme d'importance et de délais) et 2 requètes pour inclure les données de
l'une à l'autre je reste malgré tout avec une taille de 11 Méga octets à te
transmettre
Merci pour tes suggestions
Envoyé ce jour avec explications
Envoyé ce jour avec explications
Envoyé ce jour avec explications
