Insèrer dans une table un recordset [Résolu]

Messages postés
27
Date d'inscription
mercredi 15 mars 2006
Dernière intervention
3 avril 2006
- - Dernière réponse :  zorglube91 - 24 mars 2010 à 16:27
Bjr,
Comment remplir une table Access avec le contenu d'un recordset?
J'ai réussi avec l'aide d'un pro à faire une connexion ADODB, et de remplir un recordset.
Mon problème maintenant est de transférer ces info contenu dans le recordset dans une table access?
Merci
Afficher la suite 

20/32 réponses

Meilleure réponse
Messages postés
268
Date d'inscription
lundi 9 janvier 2006
Dernière intervention
19 janvier 2017
1
Merci
Pour remplir une table de bases de données, il ne faut pas créer un recordset, mais un objet Command.

Dim oConn As ADODB.Connection, oCmd As ADODB.Command
Set oConn=New ADODB.Connection
oConn.ConnectionString=chaîne de connexion
oConn.Open
Set oCmd=New ADODB.Command
oCmd.ActiveConnection=oConn
oCmd.CommandText="INSERT INTO NomTableCible(rien si tous les champs sont identiques sinon (Champ1Cible, Champ2Cible,...)) [IN 'CheminEtNomBaseCible'] SELECT Champ1Origine, Champ2Origine,...(ou * pour tous les champs) FROM TableOrigine [ WHERE Conditions ] [GROUP BY champs de regroupement] [ORDER BY Champs de classement]"
oCmd.Execute
Set oCmd=Nothing
oConn.Close
Le code SQL entre crochets correspond à des options facultatives. Bien sur, pour écrire le SQL, il est recommandé d'avoir un peu étudié la question, c'est même indispensable.
Bon courage!...

Dire « Merci » 1

Quelques mots de remerciements seront grandement appréciés. Ajouter un commentaire

Codes Sources 96 internautes nous ont dit merci ce mois-ci

Messages postés
27
Date d'inscription
mercredi 15 mars 2006
Dernière intervention
3 avril 2006
1
Merci
merci bien pour ta réponse, mais il y a un message d'erreur :

Erreur d'exécution '3001':
Les arguments sont de type incorrect, en dehors des limites autorisées ou en conflit les uns avec les autres.

Voici mon code :

Private Sub Essai()
Dim conBase As ADODB.Connection
Dim rsJeu As ADODB.Recordset
Dim strPath As String
Dim strDSN As String
strPath = "C:\BASE\DBF"
strDSN = "Driver={Microsoft Visual FoxPro Driver};SourceType=DBF;SourceDB=" & strPath
Set conBase = New ADODB.Connection
conBase.ConnectionString = strDSN
conBase.Open

Set oCmd = New ADODB.Command
oCmd.ActiveConnection = oConn ' message d'erreur
oCmd.CommandText = "INSERT INTO ARTICLE [IN c:\BASE\DBF\GPARTICL.DBF] SELECT * FROM GPARTICL "
oCmd.Execute
Set oCmd = Nothing
oConn.Close

conBase.Close
Set conBase = Nothing
End Sub

Dire « Merci » 1

Quelques mots de remerciements seront grandement appréciés. Ajouter un commentaire

Codes Sources 96 internautes nous ont dit merci ce mois-ci

Messages postés
794
Date d'inscription
vendredi 4 mars 2005
Dernière intervention
12 juin 2012
1
Merci
oui, toujours,

les opérateurs que tu cites sont implémentés dans le SQL FoxPro (d'après la documentation en tout cas).
essaies aussi "... MV_DMOU > {^01/01/2006}"

En SQL, Between sert à filtrer entre 2 dates. il existe aussi en FoxPro,

"... WHERE MV_DMOU Between #01/01/2006# AND #01/01/2012#"

ainsi que la fonction BETWEEN(valeur,basse,haute).

"... WHERE BETWEEN(MV_DMOU, #01/01/2006#", #01/01/2012#)=True"

on va trouver!


rvblogn<SUP>
</SUP><SUP>Je veux ton bien... et je l'aurais
</SUP>

Dire « Merci » 1

Quelques mots de remerciements seront grandement appréciés. Ajouter un commentaire

Codes Sources 96 internautes nous ont dit merci ce mois-ci

Messages postés
268
Date d'inscription
lundi 9 janvier 2006
Dernière intervention
19 janvier 2017
0
Merci
Dans la chaîne SQL, il y a une erreur :
Il y a :
"INSERT INTO ARTICLE [IN c:\BASE\DBF\GPARTICL.DBF] SELECT * FROM GPARTICL "
Il faut :
"INSERT INTO ARTICLE IN 'c:\BASE\DBF\GPARTICL.DBF' SELECT * FROM GPARTICL"
Messages postés
27
Date d'inscription
mercredi 15 mars 2006
Dernière intervention
3 avril 2006
0
Merci
j'obtient le meme message d'erreur,voila le code que j'utilise :

conBase.CommandText = "INSERT INTO ARTICLE IN 'c:\BASE\DBF\GPARTICL.DBF' SELECT * FROM GPARTICL"
Messages postés
268
Date d'inscription
lundi 9 janvier 2006
Dernière intervention
19 janvier 2017
0
Merci
Dans la chaîne de connexion, il manque le nom de la base de données.

Private Sub Essai()
Dim conBase As ADODB.Connection
Dim rsJeu As ADODB.Recordset
Dim strPath As String
Dim strDSN As String
strPath = "C:\BASE\DBF\GPARTICL.DBF"
strDSN = "Driver={Microsoft Visual FoxPro Driver};SourceType=DBF;SourceDB=" & strPath
Set conBase = New ADODB.Connection
conBase.ConnectionString = strDSN
conBase.Open
Set oCmd = New ADODB.Command
oCmd.ActiveConnection = ConBase ' message d'erreur
oCmd.CommandText = "INSERT INTO ARTICLE SELECT * FROM GPARTICL"
oCmd.Execute
Set oCmd = Nothing
conBase.Close
Set conBase = Nothing
End Sub
Messages postés
27
Date d'inscription
mercredi 15 mars 2006
Dernière intervention
3 avril 2006
0
Merci
Malheureusement il y a encore un message d'erreur :

N° de l'erreur : Erreur d'exécution '-2147217900(80040e14)':
Message d'erreur : "[Microsoft][ODBC Visual FoxPro Driver]Syntax error.

Au moment de l'exection : oCmd.Execute
Messages postés
268
Date d'inscription
lundi 9 janvier 2006
Dernière intervention
19 janvier 2017
0
Merci
Moi, je n'aurais pas mis de { et } dans la chaîne de connexion

strDSN = "Driver=Microsoft Visual FoxPro Driver;SourceType=DBF;SourceDB=" & strPath

Il faudrait essayer. Personnellement, je n'utilise pas FoxPro mais Access et SQL.
Messages postés
27
Date d'inscription
mercredi 15 mars 2006
Dernière intervention
3 avril 2006
0
Merci
Malheureusement cela ne marche ttjrs pas, j'ai vue sur un autre forum se genre de chose :


myrecordset.addnew
myrecordset!nomchamp=valeurmyrecordset.update<?xml:namespace prefix o ns "urn:schemas-microsoft-com:office:office" />


est ce que l’on pourrai adapter se genre de code pour remplacer l’INSER INTO ?
Messages postés
794
Date d'inscription
vendredi 4 mars 2005
Dernière intervention
12 juin 2012
0
Merci
Salut Fiston, salut jperre,

bon, allez, t'es en page 4.
Il y a un truc à comprendre jperre, c'est que la "Base" source est un fichier dbf, et que la "Base" cible est une base Access. En plus, le code est du VBA sous Access.

Donc, déjà, il va falloir une autre connection. En plus, vu de l'intérieur d'Access, ADO ne va pas être pratiquable (le code est dans la base, pas moyen de la ré-ouvrir). Il reste DAO, avec, si la table n'est pas déjà crée, une conversion de ADODB.Recordset en DAO.Recordset (types différents, attributs différents...), mais si la table est déjà crée, il faudra juste un mapping des noms de champs, et cela suffira.

toujours preneur?


rvblogn<SUP>
</SUP><SUP>Je veux ton bien... et je l'aurais
</SUP>
Messages postés
27
Date d'inscription
mercredi 15 mars 2006
Dernière intervention
3 avril 2006
0
Merci
Salut RV, merci d'avoir expliquer plus précisément mon problème à jpierre, je n'aurai pas peu être si précis.(perso je n'est pas tt compris)
En espèrent que jpierre est une solution qui me permettrai de mettre fin à se problème!!
Deux tête val mieux qu'une !!!
Messages postés
794
Date d'inscription
vendredi 4 mars 2005
Dernière intervention
12 juin 2012
0
Merci
Elle est faite ta table Access?
Les noms des champs sont les mêmes dans les 2? les types aussi?


rvblogn<SUP>
</SUP><SUP>Je veux ton bien... et je l'aurais
</SUP>
Messages postés
27
Date d'inscription
mercredi 15 mars 2006
Dernière intervention
3 avril 2006
0
Merci
Oui la table Access est déja créé, il y a exactement le meme nombre de champs, et les types doivent etre identique.
Je pense vider la table en VB puis ajouter dedans le nouveau recordset.
Messages postés
794
Date d'inscription
vendredi 4 mars 2005
Dernière intervention
12 juin 2012
0
Merci
Si tu veux, essayes cela.
Bon, il faut rajouter une référence à DAO (Microsoft DAO 3.6 Object Library).

Ensuite, dans la même procédure que celle où tu récupères le dbf , déclares :

Dim dbBaseCible As DAO.Database
Dim rsJeuCible As DAO.Recordset
Dim fldTempSource As ADODB.Field

Après avoir ouvert la connexion ADODB, mais avant le While Not :

'affecte une référence à la base courante
Set dbBaseCible = CurrentDb
'ouvre la nouvelle table Access, à adapter
Set rsJeuCible = dbBaseCible.OpenRecordset("TableCible")

Dans la boucle existante :

'tant qu'il y a des réponses
While Not rsJeu.EOF
'ajoute un enregistrement temporaire dans le jeu cible DAO
rsJeuCible.AddNew

'pour chaque champ du jeu source ADODB
'il faut impérativement qu'ils aient les mêmes nom, et types
For each fldTempSource In rsJeu.Fields
'affecte la valeur du champ source à la valeur du champ cible
rsJeuCible.Fields(fldTempSource.Name).Value = fldTempSource .Value
'champ suivant
Next fldTempSource

'valide l'enregistrement temporaire
rsJeuCible.Update
'avance d'une réponse
rsJeu.MoveNext
'continue
Wend

'ferme le jeu et libère la référence
rsJeuCible.Close
Set rsJeuCible = Nothing
'ferme la base et libère la référence
dbBaseCible.Close
Set dbBaseCible = Nothing

Qu'en penses-tu?


rvblogn<SUP>
</SUP><SUP>Je veux ton bien... et je l'aurais
</SUP>
Messages postés
794
Date d'inscription
vendredi 4 mars 2005
Dernière intervention
12 juin 2012
0
Merci
Ah oui, au fait, + de 65000 lignes, ça peut être long à dérouler!

à+


rvblogn<SUP>
</SUP><SUP>Je veux ton bien... et je l'aurais
</SUP>
Messages postés
27
Date d'inscription
mercredi 15 mars 2006
Dernière intervention
3 avril 2006
0
Merci
Ca marche à moitier, il me met encore un message d'erreur :
Erreur d'exécution '3163':
Le champ est trop petit pour accepter la quantité de données que vous voulez ajouter. Essayer d'insérer ou de coller moins de données.

Il a qd meme commencé à remplir la table (4500 lignes qd meme), c un peu long (ca se calcul en seconde donc pas encore trop grave, pour 4500 lignes, mais le plus important n'est pas le tps mais la fonctionnabilité)
Sinon ca commence à sentir très bon cette affaire, merci RV!!!
Messages postés
268
Date d'inscription
lundi 9 janvier 2006
Dernière intervention
19 janvier 2017
0
Merci
J'ai regardé un peu dans MSDN ce qui concerne le code SQL de Foxpro^. En effet, il est impossible de faire une requête ajout avec "INSERT INTO ... SELECT..., mais par contre, il faudrait essayer avec deux requêtes ajout successives :

oCmd.CommandText = "SELECT * FROM GPARTICL INTO ARRAY TabTemp"
oCmd.Execute
oCmd.CommandText = "INSERT INTO ARTICLE FROM ARRAY TabTemp"
oCmd.Execute
Set oCmd = Nothing

A tester, car je n'ai pas installé Visual FoxPro!...
Messages postés
794
Date d'inscription
vendredi 4 mars 2005
Dernière intervention
12 juin 2012
0
Merci
En tout cas, je remarque que jperre ne lache pas l'affaire, et c'est remarquable!
Et jperre, ne crois pas que je soit devin à comprendre aussi bien le problème de fiston, mais en fait, on a déjà travaillé ensemble :
http://www.vbfrance.com/forum.v2.aspx?ID=695287

Ce qui n'empêche en rien qu'on puisse travailler avec toi, bien au contraire (par contre, pour être sur la même longueur d'onde, regardes le post de 16:41:51, je sais que quand il y en a beaucoup, parfois on en rate, surtout à plusieurs).

Bon, fiston, tu sais quand je disais "conversion de ADODB.Recordset en DAO.Recordset (types différents, attributs différents...)" et "'il faut impérativement qu'ils aient les mêmes nom, et types", je pensais vraimment que c'était important. Mais bien sûr, je n'ai pas été assez précis (l'habitude que tu me comprennes) :

Les types doivent être les plus proches possibles, et comme je sais que ce ne sont pas les mêmes de chaque côté (ex : Numeric ne rentre pas dans db), il faut les mettre plus grands du côté de DAO, pour l'import, quitte à redimensionner plus finement après.
De plus, si tu n'as rien spécifié de précis du côté Access, les doivent être limitées en longueur à 50, par défaut, ce qui est peut-être trop petit. Pour tous les types numériquescôté DAO toujours) des types pouvant recevoir des (par défaut, Access a mis des Entiers Long). Et enfin, s'il y a des DatesDates (mais elles ne seront pas forcément compatibles), soit tu mets des chaînes de caractères (et il faudra rapidement les traiter pour les convertir en dates, les représentations littérales de date, ce n'est jamais viable)

Donc, tu l'as dit "et les types doivent etre identique", tu ne croyais pas si bien dire, ils se font un devoir d'être compatibles! :)

Bienvenue dans le monde de la conversion de types!

PS : évidemment le problème est un petit peu différent si tu souhaites automatiser le traitement de façon à pouvoir l'utiliser plusieurs fois.


rvblogn<SUP>
</SUP><SUP>Je veux ton bien... et je l'aurais
</SUP>
Messages postés
27
Date d'inscription
mercredi 15 mars 2006
Dernière intervention
3 avril 2006
0
Merci
merci pour ttes c info (mais ou va tu chercher tt ça RV!!!). Je vais donc bosser sur les types (je pensai que ça se résumai a numéric,text,date,....), mais je pense que le plus dure est fait.
Concernant l'automatisation, je compte importer ttjrs la même table (même type),c juste le contenu qui change.Je vous recontacte demain dans la soirée, bon week end a ts les deux !!!<?xml:namespace prefix o ns "urn:schemas-microsoft-com:office:office" />
Messages postés
794
Date d'inscription
vendredi 4 mars 2005
Dernière intervention
12 juin 2012
0
Merci
bon week-end (c'est quoi déjà un week-end, ah oui, les heures à 200%)


rvblogn<SUP>
</SUP><SUP>Je veux ton bien... et je l'aurais
</SUP>

Vous n'êtes pas encore membre ?

inscrivez-vous, c'est gratuit et ça prend moins d'une minute !

Les membres obtiennent plus de réponses que les utilisateurs anonymes.

Le fait d'être membre vous permet d'avoir un suivi détaillé de vos demandes et codes sources.

Le fait d'être membre vous permet d'avoir des options supplémentaires.