Journal un Access-like libre ?

Posté par  (site web personnel) .
Étiquettes : aucune
0
10
août
2004
Voila, je recherche un outil qui permette de créer des applications client-serveur accédant a des bases de données, dans le style de Access (simple).

Je n'arrive pas a trouver ce genre d'outils, la méthode la plus simple finalement serait de faire en php+sql mais bon...

un outil qui permette de créer ses tables et formulaires, et qui nous sortirait une appli gtk|qt|wxwidgets|xul çà serait bien sympa quand même.
  • # heu

    Posté par  . Évalué à 4.

    dans le style access, j'ai entendu parler de kexi

    hope it helps
  • # Quelques outils :

    Posté par  (site web personnel, Mastodon) . Évalué à 5.

    GTK 1 :

    - gasql
    - gaby (pour les petites DB)


    GTK2 :

    - mergeant + gnomedb2 (ça à l'air très bien)

    PHP :

    - phpmyadmin c'est quand même vachement bien

    Sinon, OpenOffice fait ça très très bien de se connecter aux bases de données et je crois que Gnumeric le fait via plugins.

    /me n'a jamais utilisé access donc n'a aucune idée de ce que doit être une bonne interface pour DB

    Mes livres CC By-SA : https://ploum.net/livres.html

    • [^] # Re: Quelques outils :

      Posté par  . Évalué à 2.

      Y'a moyen d'avoir un backend MySQL (ou PGSQL) quand on utilise libgnomedb ? Parce que par défaut il n'y a que le backend XML et je n'arrive pas à trouver d'autres backend, ce qui limite franchement l'utilisation de Mergeant du même coup...
      • [^] # Re: Quelques outils :

        Posté par  . Évalué à 3.

        Auto réponse : en fait j'avais pas vu que libgnomedb était elle-même une surcouche à libgda qui gère les accès aux bases de données. Il suffit d'installer le backend MySQL à libgda et tout devrait marcher.

        Sauf que ça marche pas. J'arrive bien à définir des accès à des BDD, mais mergeant ne me laisse pas les sélectionner lorsque je veux me connecter. La liste des BDD définies - reste désespéremment vide.

        D'ailleurs pourquoi il ne va pas chercher les bases de données disponibles tout seul comme un grand comme le fait PHP My Admin ? Il suffirait de sélectionner un backend (XML, MySQL, etc.) ainsi qu'un login et hop : il nous donne la liste des BDD auxquelles on a accès et on peut s'y connecter.

        C'est idiot de devoir définir les BDD disponibles...

        Ou alors y'a un truc que j'ai pas compris et c'est franchement pas user-friendly (un comble pour une appli GNOME 2).
    • [^] # Re: Quelques outils :

      Posté par  . Évalué à 3.

      - phpmyadmin c'est quand même vachement bien

      a noté aussi phpMyEdit qui est pas mal pour les bases simples.
  • # oo

    Posté par  (site web personnel) . Évalué à 2.

    la prochaine version d'open office disait en integrer une.
    toujours vrai ?
    • [^] # Re: oo

      Posté par  . Évalué à 2.

      Je ne sais pas où tu as pu lire ca, mais j'ai bien peur que ca tienne de la légende ... désolé.

      M
      • [^] # Re: oo

        Posté par  (site web personnel) . Évalué à 4.

        Pas de base de données à l'horizon (même s'il me semble effectivement avoir vu passer quelquechose à une époque...).
        En revanche, OpenOffice.org a une API permettant d'appeler une base de données
        et a priori toute une interface utilisateur qui permette de faire les écrans de saisie

        Plus de détails ici : http://dba.openoffice.org/(...)
        ça permet une bonne séparation application / base de données, qui est difficilement réalisable en Access après coup (va réécrire ton appli pour stocker les données dans une base distante quand t'as commencé avec tout en même temps ;-) La question se pose surtout à partir du moment d'une utilisation en réseau : faut gérer les locks, ce qu'il n'y a pas à faire en local)

        et ici pour la partie gestion d'interface utilisateur : http://dba.openoffice.org/source/browse/gsl/forms/(...) (si quelqu'un trouve mieux que le CVS direct, avec des snapshots toussa... je suis preneur pour voir la tête que ça peut avoir et surtout la possibilité de générer "automatiquement" des interfaces à partir du modèle de données de la base ;-)
  • # rekall

    Posté par  (site web personnel) . Évalué à 3.

    Rekall, par theKompany, a été libéré récemment. http://www.rekallrevealed.org(...)
    Quand je l'ai testé, ça crashait souvent, mais c'était une bêta et c'était peut-être un problème d'empaquetage.
  • # kexi

    Posté par  (site web personnel, Mastodon) . Évalué à 4.

  • # sqlite

    Posté par  (site web personnel) . Évalué à 3.

    la méthode la plus simple finalement serait de faire en php+sql
    Si tu veux le faire toi même, le mieux serait plutôt d'utiliser SQLite + le langage de ton choix.

    pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.

    • [^] # Re: sqlite

      Posté par  . Évalué à 1.

      arguments ?
      • [^] # Re: sqlite

        Posté par  (site web personnel) . Évalué à 4.

        Il peut être inclu dans l'application donc pas besoin d'un serveur de db "séparé". Dans ce sens, ça ressemble plus à MS Access qu'un serveur SQL traditionnel.

        Ou alors j'ai rien compris à ce qu'il voulait.

        pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.

    • [^] # Re: sqlite

      Posté par  (site web personnel) . Évalué à 1.

      oui en fait kexi ou rekall c'est exactement ce que je cherches.

      le seul probleme, c'est ensuite d'avoir un client portable (win/linux/osx)

      ce qu'il faudrait c'est créer un fichier qui definisse les tables et forms, et un client qui ensuite afficherais l'appli en se conectant à un serveur sql, ce client pouvant etre ensuite quelconque (un en qt, un en gtk, un autre en php...)
  • #

    Posté par  . Évalué à 2.

    Sur cette page tu trouveras différents soft permettant de faire des formulaires, états, création de basse... dans le style d'access :
    http://linuxtransition.free.fr/logiciels/logiciels_bureautique.php(...)

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.