Discussion :

[Tofalu]

J'ai même vu encore plus simple et utilisé régulièrement et au moins par 9 usagers de front :
1 seul fichier Access.mdb contient tout données et formulaires, posé sur un NAS en local..

C'est ce qui est justement déconseillé de faire. Il est largement conseillé de séparer en dorsale/frontale, à cause du moteur de base de données, du trafic réseau, du risque d'erreur et du verrouillage

Mais quand ils ne l'ont pas, c'est loin d'être évident de leur expliquer l'utilité de l'avoir, sachant que ça n'a d'intérêt que s'ils ont le sorcier qui va avec.

Pour ça, il y a le runtime. Il n'est absolument pas nécessaire d'avoir Access pour faire tourner une application développée avec Access

J'y connais rien à toute cette technologie web.
Ni aux langages, ni aux principes de serveurs, ni aux moteurs de bases de données, bref à rien du tout.

Alors conservez Access. Un développeur, surtout en application de gestion où la cohérence et l'intégrité sont les maîtres mots bien plus que l'aspect ludique de l'IHM est tout sauf un apprenti-sorcier.

De rares cas de problèmes, jamais considérés comme invalidant quand plusieurs usages modifient le même enregistrement.

Ca doit être sympa de bosser sur une de ces appli

[Access_ible]

Pour ça, il y a le runtime. Il n'est absolument pas nécessaire d'avoir Access pour faire tourner une application développée avec Access

Les renseignements que j'ai réussi à obtenir lorsque j'ai eu besoin du Runtime, c'était qu'il y en avait un pour chaque version d'Access, et que la version pour celui dont j'avais besoin était payante. Le patron a dit non.

En fait, je me demandais s'il existait des Runtimes Access (en l'occurrence 2003) gratuits, mais aussi si les fabricants d'applications avait réussi à en faire pour leurs plateformes respectives (Linux, Apple, Android…)

C'est ce qui est justement déconseillé de faire. Il est largement conseillé de séparer en dorsale/frontale, à cause du moteur de base de données, du trafic réseau, du risque d'erreur et du verrouillage

Alors conservez Access. Un développeur, surtout en application de gestion où la cohérence et l'intégrité sont les maîtres mots bien plus que l'aspect ludique de l'IHM est tout sauf un apprenti-sorcier. :

Ca doit être sympa de bosser sur une de ces appli

Il est clair que ça a plus que l'air d'être du bricolage. C'est du bidouillage.

Mais les services rendus par ces bases MacGyver (que je n'ai pas toutes crées, il n'y a pas que moi qui joue les apprenti-sorcier) sont inversement proportionnels à leur manque de professionnalismes. A tel point que les éventuels blocages n'ont jamais étés considérés comme des problèmes.

Quand à l'aspect ludique de l'IHM, je pense que c'est très important.

Non pas parce que c'est ce que je maîtrise le plus dans une base de données, mais parce que si il est possible de faire une base de donnée extrêmement fiable, le fiat qu'elle puisse être utilisé par le plus grand nombre sans que ceux-ci n'aient de connaissances spécifiques, passe forcément par un IHM agréable.

Sans vouloir me la jouer artiste, on peut utiliser un système d'exploitation Linux sans couche graphique et la plus part des utilisateurs chevronnés travaillent en ligne de commande.

Mais si Unbuntu et surtout Android ont les succès qu'on leurs connaît, n'est ce pas grâce à un IHM recherchée ?

De toute façon je vais continue avec Access, je ne sais faire que ça.

Mais je sens bien que c'est une technologie en fin de vie…

Sans avoir d'objectif précis et sans nécessité de réussite, en "loisir" par où pourrais-je commencer si je souhaitait me mettre aux bases web, 100% libres et gratuites avec éventuellement un assistant graphique ?

Encore merci.

[Tofalu]

Mais je sens bien que c'est une technologie en fin de vie…

On disait déjà ça avant 2007, puis finalement, le moteur a évolué, de nouvelles fonctionnalités ont été ajoutés. La vraie puissance d'Access jusque là, c'était la possibilité de travailler en natif avec SQL Server. On avait alors la puissance du serveur de données et les facilités de développement de l'IHM. Un formulaire continu se fait en 3 clics quand sous un autre logiciels il faut pondre des lignes de code, sans oublier les TCD, les graphs, etc.

Le hic, c'est que 2013 ne propose plus les projets ADP, du coup, on passe forcément par un lien avec Sharepoint, ce qui est tout de même bien moins simple. MSDE à l'époque, c'était vraiment top.

Mais puisque la mode est au cloud, il faut bien, hélas, faire avec.

Sans avoir d'objectif précis et sans nécessité de réussite, en "loisir" par où pourrais-je commencer si je souhaitait me mettre aux bases web, 100% libres et gratuites avec éventuellement un assistant graphique ?

Le couple Php/MySql. Sur PC, EasyPhp ou Wamp permettent de faire tourner le serveur Web et MySQL sur la même machine et s'installe super facilement. Et en plus, la communauté Php est énorme. Par contre, pour les assistants graphiques, il faudrait poser la question dans les forums Php de developpez.com mais, à coup sûr, tu ne retrouveras jamais la facilité et la rapidité de développement que tu as sous Access.

[viandelle]

Filemaker
- Développez-vous régulièrement avec filemaker ?

Oui, mais pas à plein temps, du coup mieux vaut confirmer vos infos sur http://www.fmsource.com/index.php qui regroupe les pros francophones de Filemaker.

- Que produit filemaker ? des fichiers utilisables depuis n'importe quel navigateur web et hébergé sur n'importe quel serveur web, ou bien des fichiers filemaker qui necessite l'installation d'un filemaker sur tous les postes qui souhaitent se connecter et d'un serveur filemaker pour héberger les fichiers ?

- Est-ce que l'existence d'un runtime (et je suppose son installation sur le poste usager) permet d’utiliser un fichier filemaker de manière autonome, sans connexion et sans installation de filemaker sur le poste usager ?

- Si oui, faut-il développer spécifiquement en vue d'une distribution en runtime, ou bien on développe son truc pour le web, mais avec la possibilité à la fin (genre export) de le compiler sous forme d'un runtime (à emporter en quelques sortes) ?

Il y a deux version de Filemaker, une version simple et une version 'Advanced', seule la version Advanced peut produire un runtime.

Filemaker produit deux types de fichier

Un fichier de type .fmp12 (.fp7 pour l'ancienne version) qui n'est lisible que depuis un Filemaker

Un runtime de type .exe (et l'équivalent sur Mac)

On peut héberger un fichier Filemaker directement sur le web mais uniquement sur un serveur équipé de Filemaker Server.

Si on héberge via le système Instant Web Publishing aucun développement web n'est nécessaire mais on est limité dans les actions de scripts possibles.

Un bon résumé est disponible sur http://buzz.beezwax.net/2011/04/15/f...-right-for-you

Les bases hébergées sur un Filemaker Server peuvent également être accessible à des clients Filemaker distant

Il existe sur Iphone/Ipad un client Filemaker gratuit http://www.filemaker.fr/products/filemaker-go/

[Access_ible]

Bonjour.

9 années se sont écoulées.

Alors, oui ça ressemble lourdement à du déterrage.

Mais si les modérateurs tolèrent que j’agisse de la sorte, vous allez pouvoir découvrir que je pense qu’il est pertinent de poursuivre là où la conversation s’était arrêtée la dernière fois.

Car, encore plus qu'auparavant, je suis à la recherche (forcée) d'une alternative accessible (désolé pour le jeu de mots) à Access.

Je pense que je pourrais poster la suite de mon (long) message ici, mais si un modérateur le juge nécessaire, je suis bien entendu d'accord pour créer un nouveau post (qui sera sur le même sujet).

Merci.

[argyronet]

Bonjour,

Vous n'êtes pas le seul dans cette situation et même si c'est du déterrage, il semble que votre sujet ne soit pas clos depuis plusieurs années. Cela peut en toute apparence paraître surprenant puisque votre premier sujet a environ neuf ans ce qui signifie que depuis, vous êtes restés sur Access si je comprends bien.

Si je peux vous rassurer, je suis en charge du maintien d'une application Access 2003 qui tourne et évolue (grandement) depuis 2005 et a fait l'objet de différents emplacements entre postes de travail local ;
sur serveur partagé avec un NAS ;
et maintenant Citrix…
…et ce, à cause des distances qui séparaient souvent les sites qui exploitaient l'application via un raccourci et l'emplacement physique de celle-ci parfois à plusieurs dizaines de kilomètres) ;
de subir les modifications qui vont bien en adéquation avec les nouvelles versions de Microsoft Access (application tourne aussi bien sur la version 2003 que sur toutes les suivantes y compris la version 2019 sans aucun problème).

Depuis que l'application tourne sous Citrix, on est dans une philosophie de fonctionnement qui reste très performante tout en laissant supposer à l'utilisateur qu'il utilise une instance Microsoft Access locale.
Bien entendu, il faut que l'application soit développée de telle sorte à ce qu'elle puisse fonctionner comme telle ; j'entends par là, stabilité, fiabilité du code, et tout ce qui va autour au niveau de la modélisation.
L’inconvénient ici, ce serait le coût, Serveur Cloud en sus.

Les problèmes inhérents au partage de la base sont tout à fait gérables avec les modes de verrouillage idoines des enregistrements ainsi que vous l'a déjà expliqué Christophe. Ce n'est pas le point le plus ennuyeux ou bloquant de ce type d'application choisi avec cette technologie si cela est bien géré même si le moteur de base de données de Microsoft Access n’est pas le nirvana des moteurs.

À notre grand regret à tous, les projets ADP présents jusqu’à la version 2003 étaient vraiment idéaux et vous permettaient d’avoir une stabilité au niveau de la base de données puisque vous ne vous serviez de Microsoft Access que comme application frontale avec toute la facilité qu’elle offre pour concevoir des écrans et des états de très bonne qualité. Vous pourriez passer dans un mode pseudo projet identique en faisant des connexions ODBC mais vous risquez effectivement d’être confrontés à des problèmes de performances qui rejoindront de près ou de loin celles équivalentes à l’usage d’un écosystème Full Microsoft Access.

Si effectivement vous souhaitez virer votre cuti vis-à-vis de Microsoft Access au profit d'une autre technologie, il va falloir que : vous décidiez du choix technologique vous voulez employer à savoir application Web ou bien application Windows même si cette dernière technologie a tendance à disparaître.
Vous utiliserez un outil de développement digne de ce nom (Visual Studio par exemple) et que vous attaquez une base de données partageable, SQL Server, MySQL ou encore Oracle.
=> Vous pourriez même envisager d'utiliser une base de données Microsoft Access ; dans ce cas, pas besoin de Microsoft Access pour la faire tourner, car votre exécutable serait même, avec les composants qu'il embarque, de pouvoir lire le contenu et d'exécuter des requêtes comme il se doit.

En choisissant une nouvelle technologie de basculer en exécutable, vous vous exposez bien évidemment à tout développer et reconstruire tous les écrans un par un ainsi que reconstruire également toutes les requêtes. Certes, vous n'aurez pas besoin de disposer d’une licence Microsoft Access mais du Framework qui va bien selon le langage utilisé.

En fait, vous pensez ou vous semblez nous laisser penser qu’il n’y a pas de solution à votre disposition, mais en fait il y en a plein. Le souci que vous rencontrez selon ma petite personne est que vous avez du mal à faire le pas faute de connaissance des nouvelles technologies qu’il va falloir apprendre, et de savoir les appliquer avec la même aisance que votre maîtrise, quelle qu’elle soit, de Visual Basic pour Application et de Microsoft Access en général.
La portée de la difficulté n’est pas du tout la même.

Quant au Runtime, petit objet dont je possède une certaine maitrise que j’ai manipulé tant de fois, a posé pas mal de problèmes en matière de compatibilité du fait des différentes versions qui sont sorties.
Cela explique pourquoi, je laisse mon application nationale en mdb, car au final, ça tient comme ça et je n’ai aucun problème dans ce sens, Runtime ou pas.

Alternative ou pas, je suis exposé au désidérata de mon client qui va un jour vouloir s’affranchir de Microsoft ; pour l’instant, je maintiens et je reste avec mon fidèle compagnon que je connais depuis sa naissance en invoquant qu'une refonte coûtera 3 ans de DEV pour pas grand-chose de mieux. Ça se discute.
Je vous laisse continuer ou reprendre…
Mais il va falloir que vous preniez une décision.

Argy

[Access_ible]

Bonjour.

Merci pour cette relance, c'est parti du coup :

Neuf années de plus effectivement.

À l’époque, je souhaitais déjà trouver une alternative à Access, que certains annonçaient déjà comme fini, tandis que, dans certaines entreprises, Access n'avait jamais été installé, ou avait été supprimé depuis.

Une des réponses sages que j'ai reçu et qui est régulièrement proposée, c'est que tant que c'est dispo, pourquoi essayer de faire à peu près bien avec autre chose quand on sait faire bien avec ce qu'on maitrise déjà.

En clair, vous savez utiliser Access, et il est dispo et bien utilisez le.

Et c'est ce que j'ai fait pendant encore plusieurs années depuis le dernier message

Seulement voilà, au moment où j'ai commencé à rédiger le présent message, j'étais salarié dans une structure qui s'est imaginé que LibreOffice = Microsoft Office et se sont donc débarrassé de Microsoft (même s'ils conservent Windows pour leurs OS).

Du coup, j'ai passé un sale moment à essayer de me mitonner mes petits outils avec les logiciels gratuits…

Base perd plus ou moins, mais toujours systématiquement, des enregistrements à l’import, plante pour les formats de tables…

Quand à se rabattre sur Calc, qui n'est pas plus fait qu'Excel pour servir de base de données, on a une mise en forme conditionnelle incompréhensible et/ou difficilement gérable, pour ne citer que cette limitation parmi celles qui m'ont vraiment cassé les pieds (Ajoute des décimales aux nombres (quand 0,11 est le chiffre exact, il affiche 0,109999999)…

Il est difficile de trouver de l'aide et même des forums dédiés à LibreOffice contiennent plus de réponses sur la façon de poser la question que d'aide opérationnelle.

À quoi me sert Access :

Je ne suis pas un développeur, je suis juste un utilisateur d'Access.

Mon objectif est de me bricoler des outils à l'ergonomie parfaite là où d'autres utilisent Excel.

Si ces outils ont vocation à être partagés, tant mieux.

Si ils doivent être partagés sur un nombre d'utilisateurs, ou un périmètre géographique plus large, ou contenir des données critiques et/ou sensibles, je serais le premier à recommander à mon employeur de faire développer un outil qui reprendra les fonctions du mien, mais en y ajoutant stabilité, fiabilité, sécurité.

Garder ma capacité de développer avec Access est aussi garder la capacité de prouver par l'exemple que des présentations, des formats, des automatismes sont possibles.

Il est inadmissible de se voir répondre que telle ou telle fonction n'est pas possible et/ou trop compliquée à mettre en œuvre, par une entreprise retenue pour développer l'application.

Mais tant qu'on a rien à montrer, on est classé dans les YakaFocon.

Si moi qui suit à peine plus qu'un secrétaire je peux le faire avec Access (et Developpez… et beaucoup de temps), alors les entreprises spécialisées qui répondent aux appels d'offre doivent le faire, avec la technologie de leur choix.

Juste un exemple pour que vous compreniez de quoi il retourne :

J'ai travaillé pour une grosse structure, avec des moyens et des infrastructures.

On a eu une réunion pour nous présenter une nouvelle application qui devait regrouper les données et les reverser dans plusieurs applications déjà existantes de structures partenaires.

À un moment de la présentation, il nous a été expliqué que dans un des champs, il fallait veiller à ne pas dépasser un certain nombre de caractères, car sinon une des applications dans laquelle le contenu de ce champ était recopié et qui avait une limitation du nombre de caractère, créerait une erreur.

J'ai donc, naturellement, comme je pense à peu près tout le monde sur le présent forum, indiqué qu'il suffirait de mettre une limitation au nombre de caractère du champ de la nouvelle application.

Et on m'a ri au nez en me disant qu'une telle chose n'était pas possible.

Je ne cherche pas à abandonner Access qui me va très bien.

Mais mes employeurs présents, passés et potentiels l'ont déjà plus ou moins tous mis de côté.

Il faut que je puisse arriver avec une solution gratuite, à installer uniquement sur leur PC (Car je pourrais installer un runtime sur leur machine et faire le développement sur mon PC portable. Mais on ne peut pas se connecter au réseau d'entreprise de toutes les entreprises…).

Voilà ce que j’utilise dans Access :

Objets :
- Tables,
- Requêtes (y compris pour en récupérer la SQL générée par l'assistant),
- Formulaires,
- États,
- Macro (que je n’utilise plus depuis que je sais faire du VBA),
- Modules (que j’utilise depuis que je sais faire du VBA),

Contrôles :
- Zone de texte,
- Étiquette,
- Bouton de commande,
- Contrôle Onglet,
- Groupe d’options,
- Zone de liste déroulante,
- Ligne,
- Rectangle,
- Case à cocher,
- Bouton d’option,
- Sous-forme/Sous-port,
- Image,
- Formulaires imbriqués (simples et/ou continus, plusieurs sous formulaires sur une même page),
- Infos bulles,
- Formats de saisie, d’affichage, de stockage des données

Voilà ce que je fais avec les formulaires d’Access :
- Contrôles "détournés" pour se comporter comme des "voyants",
- Contrôles "détournés" pour se comporter comme un fond de couleur conditionnelle,
- Mise en forme conditionnelle d’un champ sur son contenu ou sur le contenu d’un autre champ,
- Boite de message standard, modifiées, ou ultra personnalisées ou mini formulaires utilisés comme des boites de messages,
- Actions sur un contrôle de saisie avant, pendant, après la saisie,
- Utilisation des évènements à presque tous les niveaux existants,
- Utilisation du VBA pour que tout le traitement des données se fasse en arrière-plan (ajout/suppression d’enregistrements, extraction/mise en forme de données, imports/exports),
- Affichage/Masquage dynamique de contrôles,
- Liste déroulantes modifiées à la volée,
- Entêtes comportant des fonctions de tris,
- Bouton Copier qui envoie un texte formaté vers le presse papier,
- Bouton pour afficher/maquer un onglet,
- Formulaire reprenant l’aspect et l’organisation d’un document papier en vue de sa saisie,
- Positionnement conditionnel de focus,
- Sélection multi lignes ultra poussée (CTRL+Clic/MAJ+Clic/Combo),
- Ajout de codes barre aux états avant impression,
- Contrôle et interaction d’applications tierces (Explorateur de fichiers, Notepad, Excel, Word, Navigateur internet, SIG…),
- Contrôle et interaction d’appareils (dialogue via le port Série…),
- …

La plupart du temps, je ne fais que modifier des paramètres et/ou une mise en forme conditionnelle, ou je me contente de recopier du code que d'autre ont très aimablement posté sur un forum, mais, avec le temps, j'arrive à modifier de plus le code de bases pour n'en conserver que ce qui m'intéresse pour l'usage qui m'intéresse.

Un immense merci à la communauté de Développez…

Un certain nombre de forum accueillent des demandes similaires à la mienne :

On veut de quoi faire une base de données et des solutions ont été proposées plus avant sur ce même forum, comme SQLite.

Et pour faire des bases de données, il n'y a aucun problème, il existe une foule de solutions, largement diffusées, largement documentées, gratuites, surpuissantes

Et pas du tout user-friendly !

Franchement, si c'est pour avoir juste une ou plusieurs ou énormément de tables, on n'est pas très loin d'Excel dans la saisie des données !
Du coup, on s'interroge sur comment ajouter un formulaire à ces bases.

Et la majorité des réponses que j’ai pu lire oriente le demandeur vers une solution dans laquelle le formulaire, généré relativement automatiquement, certes, ressemble au modèle généré par l’assistant formulaire d’Access :

Oui, c’est un formulaire, oui, c’est mieux que de faire de la saisie en lignes et colonnes, mais c’est loin d’être ce qu’on peut faire de mieux et Access, un logiciel livré dans une suite bureautique, permet de faire mieux sans trop se casser la tête.

D'ailleurs, on voit bien que tous les sites commerciaux, ou des administrations, ou les progiciels utilisés par nos banquiers ou nos agents immobiliers, ou nos restaurants (oui, je sais, trois exemples qui montrent que j'ai les moyens…) sont des bases de données.

Mais ils ont tous une frontale dans laquelle on saisit sa recherche, ses infos perso, on lance des filtres, etc…

Et ni la saisie, ni les réponses ne sont affichées sous forme de table ou de formulaire basic.

Est-ce qu'en dehors de moi, personne n'utilise de formulaire un peu recherché pour interagir avec ses données ?

J'ai commencé à chercher tout azimut et j'ai trouvé donc de nombreux forums avec des personnes qui cherchent aussi comment faire des bases de données avec des frontales un peu agréables à utiliser, sans que pour autant il faille être un as de la programmation.

Et, le résultat actuel de mes recherches, c'est que cela n'existe pas. Je m'explique :

Je n'arrive pas à remettre la main sur un forum dans lequel j'ai une discussion sur quel langage de programmation était le plus simple à aborder.
Chacun y allait de son avis, généralement pour approcher une conclusion (je résume lourdement) que plus le langage était facile à aborder, moins il était "professionnel" (l'habituel débat sur la professionnalité de VBA, mais reportée tout à tour sur tous les langages).

Et il y a avait un intervenant qui expliquait (très bien) que le mieux, c'était donc Excel.

Car, selon lui et je suis plutôt d'accord avec son avis, pour progresser rapidement et "agréablement" dans l'apprentissage d'un nouveau langage (et je pense que cela peut s'étendre à de nombreux autres apprentissages) il faut pouvoir constater rapidement une amélioration des résultats.

Hors, avec Excel, il est facile de passer de rien du tout à quelque chose d'un peu satisfaisant (que ce soit la mise en forme, ou une formule un peu imbriquée).

On modifie un peu quelque chose et on a le résultat de suite.

Il semble que ce soit plus compliqué pour les langages de programmation.

L'avantage d'Access, ce sont ses nombreux assistants graphiques qui permettent commencer à faire quelque chose (voir des choses très sophistiquées) sans devoir connaitre une nouvelle langue.

Table, formulaires, requêtes, états, macro…

Et on peut très vite aller modifier des choses impactantes, juste avec un clic droit "Propriétés".

Et on a le résultat de suite.

Alors que ce que j'ai pu trouver pour les langages de programmation nécessite, dans un premier temps le recours à un langage de programmation (sur Access, il est toujours là, mais on peut faire sans) et dans un second temps de toujours savoir comment les choses s'écrivent.

Pour l'instant, dans l'idée de trouver une alternative à Access, j'ai dégrossi le pacage suivant (il faut que tout soit gratuit, pour le cas où j'arrive dans une entreprise qui n'a que faire des bases de données et qui pense que Calc fait très bien l'affaire. Il faut que je puisse demander l'installation de tous ces composants et justifier de leur absence de surcout) :

- SQlite pour les données,
- Un gestionnaire de bases, quelque chose comme DBeaver
- Une frontale programmée en Python,
- Un assistant graphique pour mettre en place Python (Une variante de Glade, vraisemblablement)

Je n'ai encore rien essayé pour l'instant.

Mais il semble que même avec une tonne d'assistants graphique, il faut encore faire du code, et par là, j'entends faire encore plus de code qu'avec Access !

Certes, Glade permet de créer des boutons, mais le moindre paramètre doit être codé manuellement.

À l'école primaire, on a appris le Logo. Au collège le Turbo Pascal. Au lycée Word, et j'ai appris le VBA dans mon travail.

Logo et Turbo Pascal, on faisait la même chose : on dessinait avec le pointeur.

Il fallait plusieurs lignes pour faire un carré et beaucoup plus encore pour produire autre chose.

Bref, l'ardoise magique version barbante.

Des décennies plus tard, c'est toujours pareil.

En Python, il faut décrire tout ce qu'on veut faire apparaitre à l'écran.

Il semble une constante que les programmeurs ne souhaitent pas rendre accessible facilement et via des interfaces graphiques, les possibilités de résultats qu'eux produisent via des pages de code. La preuve en est que la console est toujours un élément incontournable des distributions Linux, alors qu'on peut tous constater qu'il existe des équivalent graphiques pour de nombreuses taches.

Heureusement, Developpez en rassemble nombreux qui ont l'esprit de partage, mais ça reste en code (en écrivant cela, je me dit que c'est plus simple de copier et partager, récupérer et modifier une page de code aboutissant à un résultat, plutôt que la commande équivalente via des boutons et de menus).

Plus incompréhensible, pour moi, TKinter, qui est présenté comme une interface graphique de programmation Python, alors qu'elle ne m'apparait que comme une console.

Évidemment qu'il faut bien quelque chose à l'écran pour taper du texte dedans !

Alors, oui, je n'ose pas sauter le pas.

Je n'ai trouvé que des alternatives qui nécessitent au moins deux applications (et des tonnes de code) là où Access est autonome et ergonomique.

Alors, est-ce que j'ai manqué quelque chose, ou bien est-ce que mon combo SQLite/Python est la seule (car la plus accessible) alternative pour, malheureusement, se passer d'Access ?

D'avance, merci pour votre patience et vos avis éclairés.