Discussion :

[bigs3232]

bonjour
j'ai travaille sur vba excel sur des petits projets pour classer es lignes excel.mais je ne sais pas si des developpeurs font des gros projets avec du genre des milliers de codes VBA et dans quel but car je trouve que VBA a tendance à planter souvent et l'editeur VBA est tres basique comparativement à notepad ect...
J'aimerais avoir un peu vos avis de pro
merci

[unparia]

Bonjour
Parlons de Excel avant de parler du langage de développement (VBA) qu'il accepte.
Excel a la vocation d'un tableur.
Je ne sais donc pas ce que tu entends exactement par "gros projets" et ne vois pas comment du "lies" cette notion à celle de "du genre des milliers de codes VBA"
C'est rarement VBA, qui "plante", mais plutôt les instructions écrites par le développeur.

J'ajoute que la vocation d'un tableur est l'usage personnel et non celle d'un projet qu'on "s'échange" ...
Lorsque les données d'un tableur sont à communiquer à d'autres, ce n'est pas le tableur (le projet), qui est à communiquer, mais les seules données à exploiter (fichier csv ou autre). Et ceci pour plusieurs raisons, dont la sécurité.
Si l'on s'en tient à cette philosophie qui me parait personnellement essentielle, il ne peut y avoir (par construction) aucun problème de portabilité.

[Invité]

Bonjour,
Vba permet avant tout d'automatiser des actions en relation avec les données du tableur!

Si pendant des années certains utilisaient Vba pour développer des applications plus ou moins lourde c'est parce qu'il fait partie du paquet cadeau!

Maintenant avec les versions express des outils Microsoft il n'y a plus de raison!

Maintenant notepad???... Quel rapport?

Je te rappel qu'on est dans un éditeur de code en vue d'être compile!
Qu'il met en évidence les erreurs de syntaxe ce que ne fait pas notepad!
Qu'il est pris en charge par le debuger!

De plus tu peux définir un autre éditeur par défaut comme notepad++ que je préfère à notepad!

[bigs3232]

oui le mot essentiel est bien:
Vba permet avant tout d'automatiser des actions en relation avec les données du tableur!
un peu comme php pour mysql.
j'ai souvent des fournisseurs qui m'envoient des gros fichiers de données en csv de produits.
avant j'importe sur mysql et les retraite sur php .c'est extremement lourd .du coup je refléchi à tout faire en vba directement sur le fichier csv
faire tous les filtrage,decouper les fichiers et réimporter par la suite sur mysql
je constate en plus qu'il y a une bonne communauté de developpeur francais sur vba
le seul inconvénient c'est quand meme la gestion des tableaux c'est assez lourd en vba et le codage est nettement plus long comparativement à jquery
avec des boucles for et des if a rallonge

[Invité]

https://www.developpez.net/forums/d1...u/#post9163787

[bigs3232]

merci dysorthographie je préfere utiliser CreateObject("Scripting.Dictionary") c'est plus court et facile à comprendre

[Invité]

oui sauf qu'avec Ado tu à la close where , rs.filter,Rs.movenext ,Rs("NomDuChamp") ,faire des calcule,des statistique,un traitement par requête et tu peut envoyer le résultat directement dans MySql par jointure externe!

mais c'est toi qui vois, je ne suis pas le maître d'ouvre!

[Marc-L]

Bonjour !

je trouve que VBA a tendance à planter souvent

C'est juste le reflet de la qualité du code, un bon code ne plante pas même en VBA ‼

Souvent un code est créé à la va vite pour un contexte précis et dès que ce dernier change,
si l'auteur du code n'a pas prévu les vérifications d'usage quant à ce contexte,
évidemment le code ne peut que planter mais le langage n'est pas fautif, le créateur du code lui oui
ou encore la faute peut être partagée par le demandeur ayant mal présenté le contexte réel et ses fluctuations !

Pour certains types de traitement de gros fichiers de données, SQL s'avère bien plus rapide qu'une procédure en "pur VBA" …

Déjà dans le cas d'un gros fichier mieux vaut utiliser Access qu'Excel car ce n'est pas tant le langage mais bien l'outil :
dans une récente discussion pour un même traitement d'un fichier, 53 minutes via Excel et via Access moins d'une !

[Invité]

Bonjour Marc,
j'ajouterai surtout quand on à MySql!

[Marc-L]

Salut Robert !

Oui tu as raison sinon ce serait gâcher !  

[bigs3232]

merci pour vos point de vue en resumé c'est combinaison soit
excel+vba
acces+vba
msyq+php
le fichier fait autour de 15000 ligne pour 9Mo de données.
ca reste faisable sur excel ou il faut passer par accesss ou mysql
petit question c'est obligé de déclarer les variables avec dim?car c encore un peu lourd.ce serait quoi la conséquence si je ne déclare pas les variables

[Invité]

petit question c'est obligé de déclarer les variables avec dim?

ce n'est pas obligé mais les déclaration implicite bonjour le dégugage!

combinaison soit
excel+vba
acces+vba
msyq+php

Excel Vba;Csv;MySql;Adodb!

Code Module de classe ADODBRD :

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
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
 
Private Connexion
Public TYPEBASE As MyAdo
Public Base
Public Server
Public Fichier
Public User
Public PassWord
Enum MyAdo
 ACCESS97 = 1
ACCESS2000 = 2
ACCESS2012 = 1
ODBC = 4
ORACLE = 5
 SQLSERVER2005 = 6
SQLServer2008R2 = 7
SQLite = 8
SQLite3 = 9
CSV = 10
ExcelSensTire = 11
ExcelAvecTire = 12
MySQL = 13
End Enum
Public AvecTitre As Boolean
 
 
Private Function GenereCSTRING()
'Permet de générer le Cornec String
'1 - ACCESS 97
'2 - ACCESS 2000
'3 - ACCESS 2012
'4 - ODBC
'5 - ORACLE
'6 - SQL SERVER 2005
'7 - SQL Server 2008 R2
'8 - SQLite
'9 - SQLite3
If Trim("" & Fichier) = "" Then Fichier = Base
Select Case TYPEBASE
    Case ExcelAvecTire
        GenereCSTRING = "Provider=Microsoft.ACE.OLEDB.12.0;Data Source=" & Base & ";Extended Properties=""Excel 12.0;HDR=YES;"""
    Case ExcelSensTire
        GenereCSTRING = "Provider=Microsoft.ACE.OLEDB.12.0;Data Source=" & Base & ";Extended Properties=""Excel 12.0;HDR=no;"""
    Case ACCESS97
        GenereCSTRING = "Provider=Microsoft.Jet.OLEDB.3.51;Persist Security Info=False;Data Source=" & Fichier
    Case ACCESS2000
        GenereCSTRING = "Provider=Microsoft.Jet.OLEDB.4.0;Data Source=" & Fichier & ";Persist Security Info=False"
    Case ACCESS2012
        GenereCSTRING = "Provider=Microsoft.ACE.OLEDB.12.0;Data Source=" & Fichier & ";"
    Case MySQL
    GenereCSTRING = " DRIVER={MySQL ODBC 5.1 Driver};SERVER=" & Server & ";UID=" & User & ";DATABASE=" & Base & ";Password=" & PassWord
    Case ODBC
        GenereCSTRING = "Provider=MSDASQL.1;Password=" & PassWord & ";Persist Security Info=True;User ID=" & User & ";Data Source=" & Base
    Case ORACLE
        GenereCSTRING = "Provider=OraOLEDB.Oracle.1;Password=" & PassWord & ";Persist Security Info=True;User ID=" & User & ";Data Source=" & Base
    Case SQLSERVER2005
        GenereCSTRING = "Provider=SQLOLEDB.1;Password=" & PassWord & ";Persist Security Info=True;User ID=" & User & ";Initial Catalog=" & Base & ";Data Source=" & Server
    Case SQLServer2008R2
        GenereCSTRING = "Provider=SQLNCLI;Server=" & Server & ";Database=" & Base & ";UID=" & User & ";PWD=" & PassWord & ";"
    Case SQLite
        GenereCSTRING = "Provider=OleSQLite.SQLiteSource.3; Data Source=" & Fichier
        GenereCSTRING = "Driver={SQLite ODBC (UTF-8) Driver};Database=" & Fichier & ";StepAPI=;Timeout="
    Case SQLite3
        GenereCSTRING = "Driver={SQLite3 ODBC Driver};Database=" & Fichier & ";LongNames=0;Timeout=4000;NoTXN=0;SyncPragma=NORMAL;StepAPI=0;"
    Case CSV
        GenereCSTRING = "Provider=Microsoft.ACE.OLEDB.12.0;Data Source=" & Server & ";Extended Properties=""Text;HDR=" & Array("No", "YES")(Abs(AvecTitre)) & ";FMT=Delimited;"""
    Case Else
        GenereCSTRING = "PAS ASSEZ DE PARAMETRES RENSEIGNES !!!"
End Select
End Function
Public Function OpenConnetion()
    OpenConnetion = False 'Ouvre une connexion à  la base de données.
    On Error Resume Next
    Dim ConnecString
     Dim NbErr
    Set Connexion = CreateObject("ADODB.Connection")
    Connexion.Open GenereCSTRING 'ConnecString
    If Err = 0 Then
        OpenConnetion = True
       Connexion.CommandTimeout = 14400
    End If
    Debug.Print Err.Description
    Err.Clear
    On Error GoTo 0
End Function
Public Function CloseConnection()
CloseConnection = False
On Error Resume Next
    Connexion.Close 'Referme la connexion
    Set Connexion = Nothing
     If Err = 0 Then
        CloseConnection = True
    End If
    Err.Clear
    On Error GoTo 0
End Function
Public Function OpenRecordset(Sql)
'Retourne un RecordeSet
On Error Resume Next
    Dim Rs
Dim NbErr
Err.Clear
If Connexion.State = 0 Then
    OpenConnetion
End If
    Set OpenRecordset = CreateObject("ADODB.Recordset")
    OpenRecordset.Open Sql, Connexion, 1, 3
    If Err Then
    NbErr = NbErr + 1
        If NbErr < 11 Then
            Set OpenRecordset = Nothing
        End If
    End If
    Err.Clear
End Function
Public Function RetournConnection()
Set RetournConnection = Connexion
End Function
Public Function CloseRecordSet(Rs)
On Error Resume Next
    Rs.Close
    Set CloseRecordSet = Nothing
End Function
Public Function Execute(Sql)
    Execute = False
    On Error Resume Next
    Dim NbErr
Reprise:
If Connexion.State = 0 Then
    OpenConnetion
End If
Debug.Print Sql
    Connexion.Execute Sql
    If Err = 0 Then
        Execute = True
Else
    MsgBox Err.Description
    End If
 
 
    Err.Clear
End Function

Code Module Standard :

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
Private Sub test()
Dim Cn_Csv As New ADODBRD, Cn_MySql As New ADODBRD
Cn_MySql.Server = "Localhost": Cn_MySql.User = "root": Cn_MySql.PassWord = "root": Cn_MySql.Base = "testrd": Cn_MySql.TYPEBASE = MySQL
Cn_MySql.OpenConnetion
Cn_Csv.Server = "C:\MyRepertoire\Nouveau dossier": Cn_Csv.TYPEBASE = CSV: Cn_Csv.AvecTitre = True
Cn_Csv.OpenConnetion
txt = "[aa2.CSV]" & vbCrLf & _
"Format=Delimited(;)"
NewFichierTxt "C:\MyRepertoire\Nouveau dossier\schema.ini", txt
Set Rs = Cn_Csv.OpenRecordset("select * from [aa2#csv]")
 txt = Rs.GetString(, , "','", "'),('")
 txt = "('" & Left(txt, Len(txt) - 3)
 Debug.Print txt
 Cn_MySql.Execute "INSERT INTO tabletest (test,test2) VALUES" & txt & ";"
 Set Rs = Cn_Csv.CloseRecordSet(Rs): Cn_Csv.CloseConnection: Cn_MySql.CloseConnection
End Sub
Private Sub NewFichierTxt(Fichier, txt)
Dim fso, NewFichier
Set fso = CreateObject("Scripting.FileSystemObject")
Set NewFichier = fso.OpenTextFile(Fichier, 2, True)
NewFichier.Write txt
NewFichier.Close
Set NewFichier = Nothing
Set fso = Nothing
End Sub

[bigs3232]

merci dysorthographie
ce serait quoi le débugage car pour l' instant je n'ai rarement eu de problème avec mon code vba sans déclaration.
ca risque de prendre surement un peu plus de temps car VBA ne sait pas alloué une mémoire aux variables sans declaration aux préalables

[Invité]

Code :

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

1
2
TOTO=10
debug.print TauxTaux

la on peut parlé de faute d’orthographe multiplié par 2000 ligne de code! alors que Option Explicie t’oblige à déclarer le DIM et les variables existent forcément!

ca risque de prendre surement un peu plus de temps car VBA ne sait pas alloué une mémoire aux variables sans declaration aux préalables

te temps c'est de la force de frappe, car explicite ou implicite les variable sont chargé en mémoire et retrouver son erreur peux prendre plusieurs jours parfois!

[bigs3232]

quand c'est bien codé avec des petits fonctions ca va encore .si le contenu d'un sub est long le risque de trouver le bug en question est galère non?

[Marc-L]

C'est exactement du même niveau qu'en VBScript, PHP, JScript, … car dépendant des capacités de l'auteur du code !

[unparia]

quand c'est bien codé avec des petits fonctions ca va encore .si le contenu d'un sub est long le risque de trouver le bug en question est galère non?

Ah ? ben ... Heu .. Puisque tu l'affirmes ....
Bref .... Le "bug" est en général entre le siège et le clavier. Et si le "bug" ainsi défini ne sait pas se trouver lui-même, le siège est fort mal occupé.
Et un salut très amical à Marc-L pour sa franchise.

[Pierre Fauconnier]

quand c'est bien codé avec des petits fonctions ca va encore .si le contenu d'un sub est long le risque de trouver le bug en question est galère non?

Un principe de programmation: Une fonction = UNE ET UNE SEULE responsabilité...

En respectant cette règle de base, tu ne saurais pas avoir de "sub long"...

Comme le dit unparia, le problème, c'est l'interface entre le dossier et le clavier.

Et il y a moyen de créer de vraies applications en VBA avec Excel. Cela ne dépend pas du nombre de lignes de codes, ce paramètre n'entrant pour moi pas en ligne de compte pour qualifier un développement de professionnel ou non. J'ai développé de véritables applications en VBA avec Excel, avec de la gestion de données, maintenables, distribuables, réutilisables. Ce n'est pas le langage qui fait qu'une application plante ou pas. Ces développements gèrent les non-conformités, le risque d'accident de travail ou le risque environnemental et permettent aux sociétés qui les utilisent d'être certifiées ISO. Le "professionnel" ne dépend donc ni du langage ni de l'outil qui supporte ce langage.

Comparer VBA/EXCEL ou VBA/ACCESS avec PHP/MySQL n'a pour moi aucun sens, ne serait-ce déjà que parce que php/Mysql sera utilisé pour développer des applications WEB et donc, la finalité technique n'est pas la même.

Mais personnellement, je ne réduirais pas VBA/EXCEL à des "petits" développements ou à des applications "personnelles", parce que ces termes sont à définir et que pour pouvoir en débattre, il faudrait tomber d'accord sur une définition commune, restreinte au cercle des participants à cette discussion, de ces termes tels que "professionnel", "petite", "application", "personnelle"...

Bref, un débat souvent vain parce qu'il participe plus de la volonté de convaincre que de partager.

[Invité]

Si je devais te rejoindre sur un point ce serait sur la taille du code!

Non pas que vba ne permet pas de développement conséquent mais plus le code est tassé plus il est maintenable!

80% du temps est généralement consacré à l'analyse, le codage en lui même n'est pas un problème de langage de programmation mais de syntaxe lié à ce langage.

Je découpe ma problématique en fonctionnalité!

Je prend souvent l'exemple d'un vélo!

Il est composé d'une parti cadre,cycle et propulsion (chaine,pédalier,etc)

Chaque découpe de mon projet général devient une sous routine de mon projet en d'autre terme je factorise!

Une méthode ne doit rarement dépasser une dizaine de lignes!

J'ai une méthode qui gère mes classeurs; une qui gère les onglets d'un classeurs une autre qui gère un onglet! Et le tout interagi!

[Pierre Fauconnier]

Tout à fait, Robert...

Et plus on découpe le code en petites fonctions à responsabilité unique, plus on engrange des "briques logicielles" que l'on peut réutiliser dans d'autres projets.

Pour réaliser cela, éviter autant que possible les variables globales, éviter le hard coding, utiliser l'outil sur lequel on travaille plutôt que réinventer la roue (En VBA pour Excel, penser Excel avant de psner VBA permet souvent de s'éviter de pisser de code, d'avoir des fonctions optimisées et d'éviter les bugs, ...).

Et je garantis que l'on peut réaliser des applications sérieuses, professionnelles, maintenables et évolutives en VBA, et en VBA sur Excel...