Discussion :

[Le Sage]

Bonjour !

Entre les deux façons ci-dessous de se connecter à un classeur fermé, quelqu'un pourrait-il m'énumérer les restrictions/avantages/inconvénients de chacune d'entre elles et préciser s'il existe des contexte où l'une est plus appropriée que l'autre ?

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
Public Function Requete(ByVal FichierSource As String, _
                        ByVal FeuilleSource As String, _
                        Optional ByVal ImporterEntetes As Boolean)
    ' Sert juste à tester diverses chaînes de connexion
    Dim adoConnexion As ADODB.connection
    Dim adoRst As ADODB.Recordset
    Dim strSql As String
    
    Set adoConnexion = New ADODB.connection
    
    With adoConnexion
        .ConnectionString = "Provider=Microsoft.ACE.OLEDB.12.0" & _
                            ";Data Source=" & FichierSource & _
                            ";Extended Properties=""Excel 12.0" & _
                            ";HDR=" & IIf(ImporterEntetes, "No", "Yes") & _
                            ";IMEX=1"""

        .Open
    End With
    
    strSql = "SELECT * FROM [" & FeuilleSource & "$]"
        
    Set adoRst = adoConnexion.Execute(strSql)
    
    Requete = Transpose(adoRst.GetRows)
End Function

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
Public Function Requete(ByVal FichierSource As String, _
                        ByVal FeuilleSource As String, _
                        Optional ByVal ImporterEntetes As Boolean)
    ' Sert juste à tester diverses chaînes de connexion
    Dim adoConnexion As ADODB.connection
    Dim adoRst As ADODB.Recordset
    Dim strSql As String
    
    Set adoConnexion = New ADODB.connection
    
    With adoConnexion
        .ConnectionString = "DSN=Excel Files" & _
                            ";DBQ=" & FichierSource & _
                            ";DefaultDir=C:\data\Temp;DriverId=1046" & _
                            ";MaxBufferSize=2048" & _
                            ";PageTimeout=5;"

        .Open
    End With
    
    strSql = "SELECT * FROM [" & FeuilleSource & "$]"
        
    Set adoRst = adoConnexion.Execute(strSql)
    
    Requete = Transpose(adoRst.GetRows)
End Function

et Quid de "Provider=Microsoft.ACE.OLEDB.15.0" ?

Merci d'avance !

[Thumb down]

Bonjour,
Il existe d'autres méthodes également, personnellement je prendrais une version qui fonctionne.

Notes que la différence entre la 12 et la 15 c'est la version d'office qui l'impose.

maintenant si tu trouves une connexion ado qui permet d'atteindre la plage A1:XFD1048576 je prend.

[Le Sage]

Salut Thumb down.

J'ai fouillé et trouvé une discussion dans laquelle un utilisateur dit avoir résolu le problème en spécifiant les colonnes de la feuille source, mais surtout pas les lignes :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

SELECT * FROM [MaFeuille$A:G]

A tester avec A:XFD... Mais risque de falloir du temps !

[Pierre Fauconnier]

Salut

[...]

maintenant si tu trouves une connexion ado qui permet d'atteindre la plage A1:XFD1048576 je prend.

Autant je peux comprendre l'intérêt de dépasser les 65 536 lignes, autant aller à 16384 colonnes ne doit pas intéresser grand monde. Je doute qu'une table de plus de 256 colonnes soit facile à gérer, comme je doute de sa pertinence, d'une façon générale et hors cas très particuliers.

[jurassic pork]

Hello,

Salut
Autant je peux comprendre l'intérêt de dépasser les 65 536 lignes, autant aller à 16384 colonnes ne doit pas intéresser grand monde. Je doute qu'une table de plus de 256 colonnes soit facile à gérer, comme je doute de sa pertinence, d'une façon générale et hors cas très particuliers.

J'ajouterai que passé un certain nombre de données, utiliser excel comme bdd n'est pas adapté : il faut passer à une vraie base de données.

[Thumb down]

Bonjour,
En fait AdoDb pour Excel n'a pas beaucoup évolué après 2003.

Il ce trouve qu'ADODB accepte les fichiers XLSX, XLSM mais n'otorise qu'une capacité Xls soit A1:IV65536 pas A1:XFD1048576 comme un XLSX.

Si tu précises la plage A1:XFD1048576 dans ta requête ou même A1:A1048576 tu as un message d'erreur !

[Le Sage]

Re !

J'avais compris, et ce ce qu'explique l'auteur du post que j'ai lu (sur un autre forum, c'est pour ça que je n'ai pas posé de lien) :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

SELECT * FROM [MaFeuille$A1:G1048576]

Plante.

Mais d'après ce qu'il dit,

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

SELECT * FROM [MaFeuille$A:G]

fonctionne (je viens de tester avec 80 000 lignes).

Autrement dit, si on veut passer la limite des 65536, il faut spécifier les colonnes mais pas les lignes.

Faut voir si on dépasse IV en colonnes...

[Thumb down]

Bonjour,
pour m'a part il n'y a aucun intérêt d'utiliser EXCEL comme base de données.

Excel est un tableur et doit au minimum permettre la présentation de données dans une limite raisonnable.

je peux comprendre qu'Excell présente la seule solution à ceux don l'entreprise restreins voir interdit l'utilisation de base de données comme Access par exemple.

j'ai milité quand j'étais encor en activité {nostalgie quand tu nous tient} pour une base de données contiennent toutes les informations utile à tous les niveaux.

j'avais réussi a bannir tous les petits fichier Excel, sur les quels on me sollicitait parfois pour corriger des bugs.

j'avais cependant trouvé avec power Query un allié de poids!

comme le dit Clément Marcote Excel n'est pas une SGBD!

du reste quand je dis je prend c'est a tire d'expérience

[Le Sage]

@Thumb down je suis totalement d'accord.

Le souci se pose souvent avec des logiciels qui pondent des extractions au format .XLS* ou CSV et qu'il faut les analyser avec Excel.
Il y a bien Power Query, mais l'approche ADO a parfois son intérêt.

Ce qui m'a amené à poster au départ ce sont deux de ces extractions dont je voulais lire la ligne d'entêtes avant d'en passer les adresses à Power Query.
Les deux fichiers concernés accusent chacun plus de 800 000 lignes.

Il s'agit donc d'un cas particulier, qu'on rencontre rarement, mais...

[Pierre Fauconnier]

Je pense que nous sommes tous d'accord là-dessus.

Mais comme le dit LeSage, on doit parfois faire avec, ne serait-ce que pour des extractions +/- pourries... Je fais aussi la chasse aux fichiers Excel "DB" dans une boite de 400 personnes qui utilise MS SQL au travers d'un erp, d'un crm et d'autres outils, mais qui a multiplié les "petites tables" en Excel pour mapper des trucs qu'on ne voulait pas corriger ou qui "n'entraient pas dans le système"... N'étant pas directeur du S.I., je ne peux que pleurer et placer des emplâtres là où je passe, en attendant que le S.I. prenne la chose au sérieux...

Ceci dit, ces échanges ont été productifs pour cerner les problèmes, les utilisations et les limites de solutions quelles qu'elles soient