Ne vous demandez pas ce que Kexi peut faire pour vous...

Posté par  . Modéré par Nÿco.
Étiquettes : aucune
0
2
nov.
2004
KDE
"... Mais ce que vous pouvez faire pour Kexi." Alors que nous venons juste de sortir Kexi 0.1beta5, l'environnement intégré pour la gestion de données, nous souhaitons faire appel à la communauté pour nous aider à faire de Kexi le remplaçant tant attendu de MS Access.

Nous voulons que Kexi devienne l'équivalent libre de MS Access, disponible sous Linux/Unix/Windows (et bientôt MacOSX), et par la même occasion un logiciel clef dans l'adoption de Linux et des logiciels libres dans de nombreuses entreprises. Mais cela ne sera pas possible sans l'aide de nouveaux développeurs. Actuellement, il n'y a qu'un développeur travaillant à plein-temps sur Kexi, et quatre autres développeurs volontaires. Malgré toute leur ingéniosité et leur motivation, ils ne peuvent pas mener à bien cette tâche ambitieuse sans aide. Kexi a le potentiel pour devenir le grand logiciel de base de données que nous attendons tous depuis si longtemps. Les modules de base sont très flexibles, modernes et efficaces. La première version stable (en termes de fonctionnalités) sortira dans quelques mois. Avec l'aide de nouveaux développeurs, Kexi pourrait rapidement acquérir de nouvelles fonctionnalités, comme les scripts ou les états.

Aucune connaissance des bases de données n'est requise pour les nouveaux développeurs, juste une certaine expérience de la programmation avec Qt et KDE. Nous recherchons aussi des traducteurs, des testeurs, des personnes pour écrire la documentation ou créer des paquetages. Toute aide, même la plus infime, sera la bienvenue.

Veuillez contacter Jaroslaw Staniek si vous souhaitez nous aider. Vous pouvez aussi nous rejoindre sur #kexi sur le serveur irc.freenode.net pour plus d'informations. Vous trouverez en outre plus de détails sur Kexi (notamment des captures d'écrans, la documentation de l'API, etc.) sur notre site internet (http://www.kexi-project.org).

La version 0.1-beta5 est disponible.

La Kexi Team

Aller plus loin

  • # Un logiciel qui nous manquait!

    Posté par  . Évalué à 6.

    Il faut bien avouer que les SGBDR type Access sont très mal représentés dans le libre. C'est donc une très bonne initiative à encourrager!
    De plus ce logiciel promet beaucoup du fait de ça portabilité sur d'autre environnement comme GNU/Linux, Windows (tout comme les logiciels à succes ex: OOo, Mozilla/Firefox..).
    Donc bon courrage Kexi!!

  • # C'est beau !

    Posté par  . Évalué à 8.

    Kexi a déjà marqué un point auprès des décideurs pressés : les captures d'écran sont vraiment belles ! Et quand on sait comment certains responsables font les choix techniques (la belle soeur du voisin a utilisé ça et trouve ça pas mal...), c'est un point à ne surtout pas négliger.

    Autre bon point : les développeurs ne cherchent pas à réinventer la roue et utilisent SQLite comme moteur par défaut, ce qui peut aussi booster ce projet (qui est dans le domaine publique).

    Il me plaît bien ce petit projet, je vais aller voir en quoi je pourrais les aider.

    • [^] # Re: C'est beau !

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

      "Kexi a déjà marqué un point auprès des décideurs pressés : les captures d'écran sont vraiment belles !"

      Un argument qui prend de l'importance pour les déciseurs pressés : ça fonctionne sous Windows, vous pouvez donc migrez progressivement. Quand toutes vos applis seront transferées, vous pourrez envisager de passer (partiellement ou totalement) sous un OS libre.

      • [^] # Re: C'est beau !

        Posté par  . Évalué à 9.

        Et malheureusement, il reperd très vite ce point... version 0.1 beta 5...

        De nos jours le décideur à peur si il voit un numéro de version inférieur à 8...

        Sous d'autres systèmes, pour le même état d'avancement, ils en seraient au moins à une version 5 :-)

        • [^] # Re: C'est beau !

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

          Suffit de faire comme Java(tm): passer de 0.1 beta 5 à 1.6 ou bien juste changer l'ordre des chiffre: 5.1. Sinon suffit de faire un fork dans lequel la seule chose qui changerait serait le numéro de version :op

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

  • # en parlant de *ccess, migation vers MySQL

    Posté par  . Évalué à 3.

    Bonjour,

    j'ai une base acces 97, je voudrais en prenant le fichier mdb pouvoir avoir un fichier .sql pour MySQL est ce que ce programme magic existe? moi jamais rien trouvé.

    Merci ;-)

    • [^] # Re: en parlant de *ccess, migation vers MySQL

      Posté par  . Évalué à 7.

      http://mdbtools.sourceforge.net/(...)

    • [^] # Re: en parlant de *ccess, migation vers MySQL

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

      Ceci devrait t'intéresser:

      http://mdbtools.sourceforge.net/(...)

      "Specifically, MDB Tools includes programs to export schema and data to other databases such as MySQL, Oracle, Sybase, PostgreSQL, and others."

    • [^] # Re: en parlant de *ccess, migation vers MySQL

      Posté par  . Évalué à 4.

      Cela fait un moment que je n'ai pas utilisé MS Access mais de mémoire, tu peux exporter en csv.

      Ensuite, tu prend presque n'importe quel logiciel qui se connecte à MySQL et tu importe le fichier csv.

      Si tu veux en plus créer les tables je ne peux pas te renseigner. Mais avec une bonne interface style PHPMyAdmin, tu peux créer les tables très simplement avant d'importer le fichier csv.

      • [^] # Re: en parlant de *ccess, migation vers MySQL

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

        Pour migrer de Access vers une autre base de données il y a aussi la solution de passer par l'étape SQLserver si on en déjà un serveur sous la main. On peut ainsi séparer la base de données de l'interface graphique qui sert à la manipuler. C'est une première mesure de salubrité. L'interface entre elles est ODBC.
        L'étape suivante consiste à remplacer la base de données en conservant ODBC.
        La migration de l'interface graphique d'Access vers OOcalc est alors envisageable de façon indépendante.

        Je vous conseille le document d'Alix Mascret : http://fr.openoffice.org/Documentation/How-to/Bdd/04migrfr.pdf(...) ansi que toute la section "Base de Données" sur http://fr.openoffice.org/Documentation/How-to/indexht.html(...)

        • [^] # Re: en parlant de *ccess, migation vers MySQL

          Posté par  . Évalué à 2.

          Dire que l'on peut remplacer Access par une base de données c'est oublié que l'un des intérêts d'Access est d'être une application auto-suffisante.

          Utiliser une base de données, c'est l'obligation de faire intervenir le service informatique dans ton développement avec tous les problèmes que cela pose (lenteur, obligation d'utiliser les logiciels certifiés conformes, incompétence crasse parfois, etc.). AVec Access tu développes ta petite base tranquillement dans ton coin.

          • [^] # Re: en parlant de *ccess, migation vers MySQL

            Posté par  (Mastodon) . Évalué à 7.

            AVec Access tu développes ta petite base tranquillement dans ton coin.

            oui et après c'est la misère à chaque changement de version parce que celui qui a développé sa ptite base dans son coin est mort et que personne ne veut reprendre le flambeau dans le service (ce n'est qu'un exemple parmi d'autres) ;)

            Access c'est un peu le cauchemard des sysadmins.

            • [^] # Re: en parlant de *ccess, migation vers MySQL

              Posté par  . Évalué à 8.

              Même mieux, en général, chacun à sa petite base de données qui fait la même chose que chacune des autres...

            • [^] # Re: en parlant de *ccess, migation vers MySQL

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

              Tiens, c'est exactement le problème que j'ai, c'est fou quand ça sent le vécu comme ça (appli très importante qui ne tourne que sur access...97)

              J'avais essayé de lier avec ODBC a mysql mais j'avais des problèmes d'import de certaines tables. Je vais reéessayer avec l'astuce plus bas de Benjamin.

              • [^] # Re: en parlant de *ccess, migation vers MySQL

                Posté par  . Évalué à 5.

                "appli très importante" --> si il y a besoin de mettre beaucoup de contraintes, de faire des procédures stockées d'entretien de la base etc... essaie plutôt avec PostgreSQL. MySQL manque encore de nombreuses fonctionnalités pour répondre aux besoins quotidiens d'une base de gestion (notamment les triggers et les procédures stockées).

                • [^] # Re: en parlant de *ccess, migation vers MySQL

                  Posté par  . Évalué à 1.

                  les procédures stockées sont dans MySQL 5 non ?

                • [^] # Re: en parlant de *ccess, migation vers MySQL

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

                  Ben c'est une conne base de clients (environ 80 000 noms dans 60 000 sociétés).

                  Je viens de passer tout ça sur une base MySQL, qui rame un peu (serveur test sur un...p233), mais j'ai quelques bugs, et je connais rien du tout en base de donnés. Entre autre les supaires dév du truc ont eu la bonne idée d'avoir des noms de tables avec des espaces...

                  Sinon il y'a des liens de table dans Access avec des fleches suivie du signe infini (il me demande quand je veux utiliser ODBC les liens entre les tables), je sais pas trop a quoi ca correspond, mais je suis sur la bonne voie, je pense que MySQL suffira largement, n'oublions pas que ça a tourné des années sur access 97.

                  En tout cas la méthode de Benjamin en bas du thread marche nickel, après il faut que le bouzin programmé dans access suive...

                  • [^] # Re: en parlant de *ccess, migation vers MySQL

                    Posté par  . Évalué à 4.

                    "Sinon il y'a des liens de table dans Access avec des fleches suivie du signe infini"

                    Ca serait pas les cardinalités des liaisons des fois ?
                    Genre pour un client tu as N commandes (Cardinalité 1:n).

                  • [^] # Re: en parlant de *ccess, migation vers MySQL

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

                    n'oublions pas que ça a tourné des années sur access 97

                    Access fonctionne avec lemoteur Jet qui a des défauts de stabilité importants surtout quand on travaille à plusieurs mais fonctionnellement, il est assez complet et implémente assez correctement les contraintes d'intégrité. Le portage vers MySQL est loin d'être satisfaisant dans tous les cas. Postgres par contre sera toujours à la hauteur.

                    • [^] # Re: en parlant de *ccess, migation vers MySQL

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

                      Hum, je sais pas, mysql je m'en suis toujours servi pour mettre des annonces de concerts, des news, ou des bidules et machins qui devaient s'afficher dans un site ouéb...

                      Je connais pas trop son utillisation en "vrai" base de donnée. Quand a access 97, oui ça marche pas mal, mais 1) on peux plus l'acheter 2) y'a quand même des choses étranges qui se passent, du genre compacter la base pour pas que ca rame 3) pas de pertes de données mais parfois des enregistrements vides.

                      Bon, pour Postgres, y'a un connecteur ODBC tout pareil ? Même procédure d'import ?

                      Allez, je vais un peu m'auto former sur les BDD moi...

            • [^] # Re: en parlant de *ccess, migation vers MySQL

              Posté par  . Évalué à 2.

              C'est le problème du service informatique pas le mien ! :))

              Il est vrai que les développements sauvages ont souvent un peu de mal à survivre au départ de leurs auteurs. Mais si tu connais une solution qui satisfasse à la fois les admins et les utilisateurs je serais curieux de la connaître.

            • [^] # Re: en parlant de *ccess, migation vers MySQL

              Posté par  . Évalué à 3.

              Access c'est un peu le cauchemard des sysadmins


              Oui c'est vrai mais il n'y a pas que le milieu pro.
              Chez moi j'ai une petite base de donnée qui tourne sous Access, me permet de sortir de jolis états, que je peux facilement transférer d'un PC à un autre et j'aimerai bien la migrer sous Linux mais je n'ai pas envie d'utiliser un truc lourd comme mysql ou postgresql. Ce qui me plait dans ma base access c'est que c'est un fichier monolytique.

            • [^] # Re: en parlant de *ccess, migation vers MySQL

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

              Access c'est un peu le cauchemard des sysadmins.

              C'est vrai, dans une entreprise, les petites bases de données Access sont ingérables. Mais il faut de poser la question : Pourquoi existent-elles ?
              La réponse est évidente : parce que le besoin existait. Le problème c'est que ces bases de données deviennent petit à petit indispensables et ne sont pas prises en compte dans le schéma informatique de l'entreprise.

              À qui la faute ? Un peu à certains utilisateurs, peut-être, mais l'essentiel de la responsabilité incombe aux services informatiques qui ne sont pas à l'écoute des besoins et n'aident pas les utilisateurs.
              La solution consiste à aider les utilisateurs à maquetter l'application dont ils ont besoin avec un outil personnel tel que Access et surtout de ne de faire en sorte que jamais une application de ce genre n'ait besoin de devenir opérationnelle.
              Je vais être dur : la multiplication des BD de type Access est révélatrice de la carence des centres informatiques.

              • [^] # Re: en parlant de *ccess, migation vers MySQL

                Posté par  . Évalué à 6.

                Elle est révélatrice aussi des petits besoins. Un petit traitement en batch, quelques données, qu'une seule personne fait de temps en temps.... C'est un besoin métier spécialisé qui est compliqué à exprimer et de faire l'outil cela aide celui qui a en charge le boulot. C'est un dev dont ils ne veulent pas que cela les engage auprès d'autres services - une maquette qui devient petit à petit l'appli elle-même.
                C'est aussi le fait que souvent les gens aiment bien faire du dev, et que cela les amuse tout simplement.
                Pas seulement une carence, cela montre aussi que l'informatique va excède le contrôle des services informatiques. D'ailleur microsoft dit souvent cela - enfin... c'était un argument qu'avait donné pbpg un jour : m$ permet à des non informaticiens de "se débrouiller".

                • [^] # Re: en parlant de *ccess, migation vers MySQL

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

                  Lorsque la même personne possède les compétences dans le métier et dans l'informatique, on obtient le meilleur résultat au meilleur coût car le besoin de dialoque entre l'homme du métier et l'informaticien se font dans le même cerveau.
                  Le problème de la maquette qui devient petit à petit l'appli elle-même peut donner quelque chose de bon à condition d'être intégrée au schéma informatique de l'entreprise. Parfois elle est ignorée par le service informatique au motif NIH (not invented here) et dans ce cas c'est une faute.

                  • [^] # Re: en parlant de *ccess, migation vers MySQL

                    Posté par  . Évalué à 6.

                    Bon ca fait deux fois que ca tape sur le service info donc la je reagis...

                    Le pb c'est que lorsque chacun a ca petite base, avec des duplications de donnees, que l'on retrouve encore une fois dans une base au niveau du support informatique tu fais quoi?

                    Tu proposes de travailler ensemble afin de mettre en place une base unique ou chacun va pouvoir retrouver ces donnes, mais aussi celle des autres et enfin s'assurer qu'on a les infos a jour en beneficiant des mises a joru des autres.

                    Le temps de finir la phrase, t'as plus personne. Chacun a developpe son petit bebe et veut pas qu'un autre y touche. La premiere fois, tu dis c'est dommage, la seconde fois tu demandes ce qui se passe, la troisieme fois t'abandonne.

          • [^] # Re: en parlant de *ccess, migation vers MySQL

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

            Comme avec OOo et SQLite ?

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

      • [^] # Re: en parlant de *ccess, migation vers MySQL

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

        C'est compliqué tout ça... man mysqlimport.

    • [^] # Re: en parlant de *ccess, migation vers MySQL

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

      Tu Installes MySQL ODBC ( http://www.mysql.com(...) )
      Ensuite tu ouvres le Gestionnaire ODBC ( sous Windows ) pour faire un lien vers ta base MySQL.
      Ensuite tu ouvres ta "base" Access tu selectionnes tes tables et tu fais :
      Menu Fichier - Exporter
      dans l'onglet type de fichier tu selectionnes ODBC Database et hop tu selectionnes ton lien ODBC et ca roule .......

      Après tu peux gerer les index et autres dans MySQL

    • [^] # Re: en parlant de *ccess, migation vers MySQL

      Posté par  . Évalué à 1.

      Et avec windev 9 ? on importe la base access dans windev et on exporte en java pour que ca tourne sur toutes les plateformes ?

      Ok j'y vais ... -----> []

  • # MS Access: un des obstacles aux migrations

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

    Effectivement, MS Access est un des points bloquants pour une migration vers le libre. C'est fou le nombre d'applis Access dévelopées en sauvage dans les entrprises/collectivités locales et qui vont venir bloquer toute migration. Une des premières approches est de migrer les données elle mêmes vers une base de donnée comme Postgres via une liaison ODBC et ça fonctionne très, très bien sans grop loup. Mais il faut quand même un poste MS Windows pour tourner l'interface Access et là, difficile de migrer :-( surtout qu'un programmeur Access est assez efficace et en plus, son code est quasiment inmaintenable donc le gars se retrouve indispensable

    • [^] # Re: MS Access: un des obstacles aux migrations

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

      Je confirme, migrer les données elles-mêmes n'est pas le plus dur, par contre en ce qui concerne toutes les applis / macros en VB codées avec les pieds qui vont avec, là ça devient vraiment la galère.

      Et bien sûr pas question de migrer quoi que ce soit sans une compatibilité à 100%, en entreprise on ne peut pas se permettre que ça ne marche plus aussi bien qu'avant...

    • [^] # Pour remplacer Access, utilisez OpenOffice !

      Posté par  (Mastodon) . Évalué à 2.

      J'entends très souvent dire qu'il n'existe pas d'équivalent à Access libre... C'est je crois dû en grande partie à une méconnaissance des possibilité d'OOo en ce domaine...

      Access c'est :
      - un moteur de SGDB/R (assez médiocre) --> il est avantagesement remplacé par [mettez ici votre base préférée] (MySql, Postgresql, SAP DB, ...)

      - une interface graphique qui permet d'éditer les tables, de créer des formulaires de saisie agrémentés de certains contrôles, de généréer des états (papier) --> toutes ces fonctionnalités sont présentes (mais pas mises en avant du tout) dans les fonctions de sources de données d'OOo et les auto-pilotes de formulaire, état, ... Ca permet vraiment de faire presque tout ce que fait Access, et c'est libre !!!

      nb : la version 2 d'OOo améliore les choses de ce point de vue et propose en particulier un format de ficher base de données à part entière (aujourd'hui c'est une source, et des liens vers des documents writer qui contiennent les formulaires, états, ...)

  • # Et d'autres

    Posté par  . Évalué à 7.

    Pourquoi ne pas penser à une collaboration entre les devs de Kexi et ceux de knoda : http://www.knoda.org?(...) Knoda est "assez" stable, il faut encore paufiner quelques points, mais on peut déjà s'amuser avec!

    • [^] # Re: Et d'autres

      Posté par  . Évalué à 2.

      D'ailleurs, à ce sujet, quelles sont les différences entre knoda et kexi ?

      Je parle de différences "d'objectifs". Parce que je vois bien que les états sont déjà en place dans knoda et pas encore dans kexi, mais à terme cela ne les différeciera plus.

    • [^] # Re: Et d'autres

      Posté par  . Évalué à 1.

      Je ne sais pas pour la collaboration, mais en tous cas, il semblent déjà savoir que ça existe puisque un lien vers knoda apparait sur le site de kexi : http://www.kexi-project.org/wiki/wikiview/index.php?Scripting(...) (tout en bas)

      • [^] # Re: Et d'autres

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

        Sur la même page on trouve aussi un lien vers le site de Rekall ( http://www.rekallrevealed.org/(...) ) qui a l'air d'être un troisième programme du même genre. Même question que pour Knoda: c'est quoi les différences ?

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

    • [^] # Re: Et d'autres

      Posté par  . Évalué à 5.

      La différence entre Kexi et Knoda se situe au niveau des objectifs. Comme tu l'as dis, "on peut déjà s'amuser" avec KNoda. Mais il ne semble pas vraiment boxer dans la meme categorie que Access.

      Kexi a pour but de devenir un réel compétiteur de Access. Il propose les memes fonctionnalités (pour l'instant) que KNoda, mais poussées plus en avant. Par exemple, pour le support des formulaires, on a développé un créateur d'interfaces général et complet, pouvant facilement rivaliser avec ceux de Visual Basic ou Qt Designer. Au contraire, le créateur d'interfaces de Knoda est assez basique.

      De plus, Kexi fait partie de KOffice, et s'intégrera donc avec toutes les applications de cette suite, ce que ne fait pas KNoda.

  • # possibilité ?

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

    Est-ce que il y a des plans d'utilisé les nouvelles téchnologies comme les générateurs d'interface en XML comme la techno mozilla XUL ? Est-ce que l'on pourrait utiliser mysql ou postregre au choix ?

    Les "grosses" applications access sont souvent sur pluiseurs machine connecter à une base unique en odbc.

    J'imagine que faire "facilement" un client riche web en techno xul ou simplement en xml sans se taper du html ou du javascript à la main. (comme dans access, avec le web en plus)

    Mais il ne faut pas oublier non plus la base de donnée + exe unique qui tient dans un fichier bricoler dans un coin.

    "La première sécurité est la liberté"

    • [^] # Re: possibilité ?

      Posté par  . Évalué à 3.

      Pour répondre a toutes tes questions:
      * Oui, on pourra choisir entre des serveurs de bases de données (comme postgresql ou MySQL) et des bases de données stockées dans un seul fichier (comme SQLite).
      * La gestion de ODBC est aussi prévue, ainsi que les applications sur plusieurs postes. (meme si ce dont tu parles dépasse un peu la portée d'une application comme Access ou Kexi, et requiert plutot des programmes "normaux")
      * KexiDB, la bibliothèque d'accès aux bases de données de Kexi, pourra aussi être utilisée par d'autres aplis, pour créer des applis plus grosses et natives.
      * Sinon, les formulaires utilsent un format XML, celui de Qt, pour la description des interfaces.

  • # tookit ?

    Posté par  . Évalué à -9.

    chais pas vous, mais pour moi choisir qt/kde c'est freinner portage et interop...

    • [^] # Re: tookit ?

      Posté par  . Évalué à 3.

      A l'origine (et c'est toujours le cas), Kexi est prévu pour faire partie de la suite Koffice. On peut difficilement demander au developpeur d'utiliser GTK.

      A l'équipe de Gnome Office de faire la même chose en GTK.

      Ce qui serait vraiment pratique c'est que Kexi soit un ensemble de librairie indépendant du toolkit. Mais j'imagine que c'est dur puisque justement dans ce type d'application l'interface tient une place extrêmement importante. (Comment font les dev de OOo ?)

      D'ailleurs, qu'en est il des projets qui visaient à remplacer l'une des librairies Qt/GTK par l'autre. Je pense à QtGtk qui fait tourner une application GTK avec le toolkit Qt. Le projet inverse existe t'il (Qt->Gtk) ?

  • # Access ne me manque pas

    Posté par  . Évalué à 2.

    Mais si un client veut un support type access, je lui propose pgaccess:

    http://www.pgaccess.org(...)

    et des scrinchoute (dans le bb)

    http://www.pgaccess.org/index.php?page=Screenshots(...)

    • [^] # Re: Access ne me manque pas

      Posté par  . Évalué à 3.

      Outre le fait que l'esthétique de l'interface de pgAccess soit pas une réussite, ce logiciel ne joue pas dans la même catégorie que Access, qui permet de développer une petite application sans avoir de serveur de base de données, et/ou de se connecter à un serveur.

      pgAccess, comme son nom l'indique (sauf erreur de ma part), requiert la présence d'un PostGreSQL, là où Kexi exploite sqlite.

      • [^] # Re: Access ne me manque pas

        Posté par  . Évalué à 1.

        Justement séparer interface et base est un sacré avantage, un jour si je veux changer d'affichage je change pas la base.

        En partant sur le principe d'access (tout en un), tout est à reprendre.

        Un petit point sur sqlite, en "lockant" les fichiers lors d'une écriture, on bloque l'accès à d'autres utilisateurs.

        Pour l'esthétique ca se discute en effet .......

        • [^] # Re: Access ne me manque pas

          Posté par  . Évalué à 3.

          Justement, l'objectif de SQLite n'est pas de gérer de nombreux accès concurrents, mais simplement de fournir une interface SQL vers un fichier indexé. L'utilisation ciblée est plus des applis en client lourd pour un seul poste. D'où son intérêt pour des solutions de type Access, où on peut vouloir transporter une base entière d'un poste à un autre simplement en copiant un fichier, et sans forcément avoir besoin de gérer un SGBDR complet.

          Bref, pour une utilisation monoposte, mono-utilisateur (ou même pour faire du développement de formulaires, avant de les déployer ailleurs) --> SQLite.
          Pour une utilisation multi-utilisateurs --> PostgreSQL ou autre.

          • [^] # Re: Access ne me manque pas

            Posté par  . Évalué à 1.

            Je me pose une question sur sqlite:

            Peux-t'on mettre en relation plusieurs tables comme dans Access?

            J'ai parcouru le site de sqlite mais je n'ai pas trouvé de réponse à ma question mais bon comme je ne suis pas spécialiste des BD j'ai peut-être mal cherché...

            • [^] # Re: Access ne me manque pas

              Posté par  . Évalué à 3.

              Trouvé là :

              http://www.sqlite.org/lang.html#select(...)

              "The query is executed against one or more tables specified after the FROM keyword. If multiple tables names are separated by commas, then the query is against the cross join of the various tables. The full SQL-92 join syntax can also be used to specify joins. A sub-query in parentheses may be substituted for any table name in the FROM clause. The entire FROM clause may be omitted, in which case the result is a single row consisting of the values of the expression list."

              Autrement dit, SQLite supporte les jointures entre tables. Le contraire aurait été inquiétant :o). Par ailleurs, SQLite supporte aussi les vues (en lecture uniquement), les jointures externes gauche, certaines sous-requêtes, etc... (cf doc).

  • # pgaccess

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

    Est-ce que ça a quelque chose à voir avec pgaccess, ou pas du tout?

    http://www.pgaccess.org/(...)
    http://sourceforge.net/projects/pgaccess/(...)
    «pgaccess is a graphical interface to PostgreSQL database written in Tcl/Tk and applications building environment. »

    • [^] # Re: pgaccess

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

      Pgaccess fonctionne bien mais c'est du tcl/tk et on sent ses limitations quand on s'en sert. C'est un peu limité à côté d'une interface graphique réalisée avec gtk ou Qt.
      J'ai beaucoup apprécié pgaccess et je l'apprécie toujours, mais il n'est pas tout à fait au niveau fonctionnel del'interface graphique d'Access. Je ne crois pas qu'il puisse un jour rivaliser avec elle car elle est, reconnaissons-le, fort bien réussie. C'est ce qui est dessous qui n'est pas à la hauteur.

  • # petite erreur

    Posté par  . Évalué à 2.

    Un petit commentaire hors-sujet : erreur de frappe, irc.freenode.net fonctionnerait mieu que irc.frenode.net :) voila tout...

  • # quelqu'un a le mot de passe?

    Posté par  . Évalué à 5.

    Comme les screenshots montrent une avancee certaine du projet, et intrigue par le numero de la version, je suis curieux de regarder la liste des bugs recences...

    Je clique sur "Bug Database" et la... login/password ?

  • # Pourquoi un objectif Kxx avec QT ?

    Posté par  . Évalué à -1.

    Si l'objectif est réellement d'aboutir à un concurrent crédible de M$ Access, il ne faut pas imposer la structure Qt qui n'est libre sous W32 qu'en version 2.
    D'autre part Qt est plutôt liée à KDE, ce n'est pas le seul gestionnaire de bureau (Gnome, Wm, E!, etc.) Gtk est peut-être un peu plus libre et multi plate-forme, il n'y a pas de licence spécifique à W32.
    Cela dit, je ne critique aucunement le travail de qualité fait par Trolltek, mais les restrictions liées à W32 peuvent provoquer des incompatibilités à plus long termes (delta entre V3.3 et V2 pour W32).

    • [^] # Re: Pourquoi un objectif Kxx avec QT ?

      Posté par  . Évalué à 5.

      KDE n'est pas un gestionnaire de bureau, mais un bureau complet. Le fait de lier une
      application à KDE via QT présente plusiseurs avantages dont un qui me parrait capital,
      à savoir le look-and-feel homgène et cohérent avec le reste. Autre avantage, le partage d'infos avec les autres applis via les bus KDE et pour finir la possibilité de rendre les applis
      "embeded" les unes vis à vis des autres. Et je ne parle pas du gain en temps de développement grace à l'utilisation du framework KDE (ensembe de super classes au dessus de QT)
      Vouloir absolument que les applis développer pour Linux tournent aussi sous windows
      ne produit que des applis genre electrons libres qui ne s'intègrent pas ou mal avec les desktop et ça fait bricolo. Enfin c'est mon avis.

      • [^] # Re: Pourquoi un objectif Kxx avec QT ?

        Posté par  . Évalué à 1.

        Je suppose que vous n'utilisez pas d'applications comme Eclipse, Mozilla, etc. car pour vous, ce sont des bricolages qui ne s'intègrent pas ou mal avec le desktop KDE.
        Si l'on veut un produit utilisé par un grand nombre d'utilisateur il faut tenir compte de la pieuvre (M$ W32), combien sommes nous dans le monde à utiliser Linux et Unix en général sur les machines de bureau et le desktop KDE en particulier. Le produit dont on parle est un outil bureautique donc destiné à un large public pas seulement des bricoleurs.
        S'adresser à des utilisateurs sous Window$ apporte aussi plus de testeurs pour les nouvelles versions. Sauf si l'on désire avoir un petit programme dans un coin qui fait des choses pas très bien comme par exemple bluefish(Gnome), Quanta(KDE) loin derrière un Dreamweaver (produit fermé pour Window$) mais quels pro peuvent utiliser Quanta+ ou Bluefish ? (Je ne mets pas en cause les développeurs de ces programmes) Là oui c'est destiné aux bricoleurs qui parlent HTML dans les textes.
        Il manque trop d'applications sous Linux (libres ou non) pour avoir un très grand nombre d'utilisateurs, il faut donc développer multi plate-formes.

        • [^] # Re: Pourquoi un objectif Kxx avec QT ?

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

          >[...] il faut donc développer multi plate-formes.

          Multi plate-formes, c'est l'esprit du libre ! Linux n'est qu'une partie du libre, ne l'oublions pas. Vive les applis libre sous Linux, windows, macosX et même sous BSD s'il le faut !

          ...
          ...

          On me soufle que BSD, c'est libre.
          Bon. Mais quand même, les utilisateurs de BSD ne sont pas des linuxiens comme les autres !

          Ok, ==>[]

        • [^] # Re: Pourquoi un objectif Kxx avec QT ?

          Posté par  . Évalué à 1.

          "Il manque trop d'applications sous Linux (libres ou non) pour avoir un très grand nombre d'utilisateurs, il faut donc développer multi plate-formes."

          Je vois mal le rapport entre le fait qu'il manque des applications sous GNU/Linux et le fait de devoir développer des logiciels multi-plateforme.
          Le but d'un logiciel n'est pas d'avoir 3 milliards d'utilisateurs, c'est de bien faire ce pourquoi il est conçu.

          Mais de toutes façons Qt fonctionne (et s'intègre) très bien sous MS Windows.

        • [^] # Re: Pourquoi un objectif Kxx avec QT ?

          Posté par  . Évalué à 4.

          >>>Je suppose que vous n'utilisez pas d'applications comme Eclipse, Mozilla, etc. car pour >>>vous, ce sont des bricolages qui ne s'intègrent pas ou mal avec le desktop KDE.

          j'utilise eclipse toute la journée et c'est vrai que c'est une belle appli mais il n'empeche
          qu'elle n'est pas integré au desktop et qu'elle se suffit à elle meme vue que c'est une grosse
          usine. Quand à mozilla effectivement je ne l'utilise plus, je préfère de loin konqueror qui lui utilise pleinement KDE. Bon c'est vrai que je ne suis pas un utilisateur représentatif puisque j'utilise exclusivement KDE au boulot et à la maison. windows, connait pas...

        • [^] # Re: Pourquoi un objectif Kxx avec QT ?

          Posté par  . Évalué à 5.

          Si l'on veut un produit utilisé par un grand nombre d'utilisateur il faut tenir compte de la pieuvre (M$ W32), combien sommes nous dans le monde à utiliser Linux et Unix en général sur les machines de bureau et le desktop KDE en particulier. Le produit dont on parle est un outil bureautique donc destiné à un large public pas seulement des bricoleurs.

          D'un autre côté, si on est toujours liés à 3000 paramètres, on n'avance pas. Faut avoir un peu de liberté pour pouvoir innover...
          En voulant faire un produit qui marche avec absolument tout on se ferme beaucoup de possiblités.

  • # OpenOffice est en passe de le faire aussi

    Posté par  . Évalué à 2.

    http://dba.openoffice.org/miscellaneous/dba20.html(...)

    • [^] # Re: OpenOffice est en passe de le faire aussi

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

      d'ailleurs, étant donné la notoriété du projet OOo et sa position de standard de fait des suites bureautiques libres, sa solution a 90% de chance de s'imposer si elle n'est pas plus mauvaise qu'une autre.

      L'utilisation de la suite Koffice reste encore anecdotique. On lui souhaite de progresser, diversité étant mère de richesse.

      Et si toutes les aplications sont compatibles, c'est encore mieux...

    • [^] # Re: OpenOffice est en passe de le faire aussi

      Posté par  . Évalué à 1.

      ouais, mais à l'epoque ou j'avais contacté un dev de ce projet, j'avais eu l'information qu'ils ne comptaient pas proposer le même principe qu'access, c'est à dire un fichier unique (comprenant les donnée, formulaire etc)....

      en fait c'etait juste un nieme client de base de donnée.

      alors bon... ca a peut-être changé hein....

Suivre le flux des commentaires

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