ADODB - Range.Delete dans une boucle de RecordSet désynchronise le RecordSet

Pierre,
Ta solution est très intéressante mais déjà d'un niveau confirmé++

En SQL on aurait

Code:

---

1 2 3 4

SELECT * FROM monOnglet WHERE True AND Compte = 'Toto' AND maDate >= #5/12/2018# AND maDate <= #14/07/2019#

---

Pour modulo 400 ne me rappelle plus comment implémenter ça en SQL

Sinon ne vois pas le problème d'ajouter une librairie...

Oui, c'est d'un niveau "confirmé" Excel, mais plus sur les formules que sur le VBA qui lui, ne change qu'au niveau de la ligne affectant la formule à la variable, le reste du code restant identique et simple à lire et à comprendre pour un "excellien" non programmeur (selon mes critères de simplicité qui ne sont probablement pas les tiens).

L'intérêt de nos deux démarches est de montrer deux façons différentes d'aborder une problématique donnée, selon les affinités que l'on a avec Excel et/ou la vraie programmation ;)

Ce n'est pas un problème en soi d'ajouter une bibliothèque, mais cela demande d'aborder des notions ADODB étrangères à l'utilisateur Excel qui n'est pas forcément orienté programmeur et donc pas forcément à l'aise avec les notions de Recordset, connection, sql... La formule Excel est "complexe" mais reste une formule Excel (un EQUIV matriciel) qui devrait être maîtrisée par tout utilisateur professionnel d'Excel. C'est en tout cas une techno que j'aborde dans les formations que je donne sur la façon de créer des formules dans Excel, tellement les matricielles dopent la puissance de l'outil.

Merci pour l'échange, en tout cas ;)

Merci à toi aussi Pierre pour cet échange qui effectivement permet de monter deux approches différentes et faire profiter la communauté de ton expertise

ICI ou ICI pour des exemples de la puissance du SQL pour rapprocher des données, exercice souvent demandé dans le monde professionnel.
Et SQL est le langage spécialisé pour ce type de demande, passer par du excel natif c'est vouloir réinventer le SQL mais en moins bien

Ok pour les liens. Pour rapprocher des données, on a aussi, depuis 2010, Power Query, qui permet des jointures "graphiques", un peu comme dans le QBE d'Access, et qui permet une préparations des données pour la consolidation, mais aussi le splittage de données, ainsi que la préparation des données pour une analyse par TCD... Les possibilités sont donc diverses, mais je privilégie nettement Power Query pour rapprocher des données par rapport à du VBA, qui plus est intégrant du SQL. Encore aujourd'hui, j'ai montré en formation les possibilités de consolidation et de traitement de Power Query qui ont tout simplement rendu inutile le code VBA utilisé auparavant pour la consolidation, la préparation, la réorganisation et le renommage de colonnes, tout se faisant dans Power Query via l'interface graphique.

Il faut noter toutefois que Power Query ne permet pas de travailler sur la source (pour modifier, ajouter ou supprimer des données) car il n'intervient qu'en lecture sur les tables sources. Dans ton cas, il y aurait donc du VBA pour supprimer les données. Mais on pourrait imaginer une restitution des données après suppression des lignes à supprimer, le code VBA s'occupant uniquement du transfert de la requête résultante nettoyée dans le tableau source. Il y a là du potentiel à exploiter, à mon avis, et probablement de nouvelles habitudes à prendre en termes de traitement de données sur des tables Excel ;)

Les technos évoluent et les outils embarqués par Excel pour l'analyse des données réduisent, voire rendent inutile, le code vba, ou le cantonnent, en gros, à des redirections de requêtes ;)

De mon point de vue, Excel est toxique pour le monde professionnel car il supplante le S.I. en alimentant de façon exponentielle le shadow IT qui est une véritable bombe à retardement pour les boites à plus d'un titre.

• Pas de support par la DSI donc non pérenne car tient généralement à la grâce de la bonne volonté de non développeurs dont ce n'est pas le boulot
• Développements non documentés et généralement abandon de l'outil à la disparition de la personne origine du développement
• Dispense de toute normalisation de la données donc calculs généralement faux et générant des traitements qui se complexifient jusqu'à arriver à une impasse
• Disparition de la source maîtresse de la données
• Resaisies multiples de la données donc diffusion de l'erreur initiale avec risque d'erreurs supplémentaires sans parler du temps perdu

J'arrête là mon réquisitoire à charge

C'est pour cela que moi et d'autres (78Chris par exemple) tentons de placer Power Query partout où nous pouvons le mettre, car cet outil aide à normaliser les données en vue de leur analyse.

Prochainement, les forums Excel seront étendus à un nouveau forum qui traitera exclusivement des aspects POWER (Power Query, Power Pivot, Power Map, Power View, et pourquoi pas Power BI) pour encourager les membres à utiliser ces nouveaux outils qui, je le rappelle et hormis Power BI, sont natifs dans Excel 2016 et suivants (365 et 2019), mais disponibles depuis XL 2010.

Super initiative. Merci à tous