[Base] Traduction de MS-Access Les Comptoirs

[jerome bourgeois]

Bonjour,

Pour faire un point sur les nouveautés de la 3.1 et des changements dans les macros qu'elle allait apporter et étant donné les améliorations de Base qui en fait un concurrent de plus en plus sérieux de Microsoft Access, je me suis mis demeure de transcrire "Comptoir", la base exemple bien connue de chez Access en une application Base...
Je joins le fichier... J'ai vérifié les copyrights, il n'y en n'a pas et le préambule encourage même à se servir de cette base comme modèle, ce que j'ai fait. Cependant, je comprendrais très bien que les "vilains modos" refusent le fichier, dans ce cas là, je le rapatrierai sur mon site. J'ai cependant mis un avertissement sur le menu de démarrage.. au cas où
Cette application me sert de mémo et n' a d'autre prétention que d'aider les débutants... Elle est incomplète mais recevra, j'espère de nombreuses contributions.

Elle m'a servi bien sûr également à faire le point sur l'avancée des travaux... En conclusion, et à mon humble avis, OpenOffice Base a encore des lacunes (retards) par rapport à son homologue de chez Windows, mais va en tout cas dans le bon sens. Je pourrai détailler les principales difficultés rencontrées le cas échéant.

Mais elle n'est pas sans atout parmi lesquels notamment :
Le fait qu'elle soit la seule application de ce type à tourner à la fois sur Windows, Mac et Linux (Access est Windows Only !) et l'intégration avec les autres modules de la suite : vous pouvez très facilement à partir de calc créer directement un pilote de données et son diagramme à partir d'une requête : avec la vue "Analyse des Ventes" par exemple (qui est là pour). Idem pour les planches d'étiquettes que proposent Access, elles sont très simples à réaliser à partir de l'assistant, accessible dans le menu de tous les modules (base y compris)...

Je voudrais finir avec un grand merci à ce forum dans lequel je me suis servi abondamment et je ne saurai également que recommander le livre "Programmation OpenOffice .org 3" ! Et enfin que tous ceux qui pensent se reconnaitre dans mes macros en soient remerciés !

Voilà, si le coeur vous en dit,

Cordialement

Jérôme

Ajout : mise à jour du lien

N.B. Le fichier étant en fait trop lourd (990 kio pour 500 autorisés), je me permets de mettre un lien direct vers son téléchargement :https://intranet.xlinfo.fr/remote.php?f ... mptoir.odb

[squenson]

Un EXCELLENT travail, toutes mes félicitations ! Je pense en effet que la popularité d'OOo passe par de nombreux exemples car je ne connais rien de mieux pour apprendre à utiliser un outil que de comprendre comment certaines fonctions ont été développées.

[jerome bourgeois]

Merci Squenson,

Le développement continu...
Donc n'hésitez pas à y jeter un œil de temps à autre....

Jérôme

[aishen]

excellent travail
voilà le genre d'exemple qui nous aimer base...
je cherche un soft comptabilité quelqu'un aurait un tuyau
merci encore pour ce magnifique travail

[jerome bourgeois]

Allez, pour commencer cette nouvelle année, j'ai rajouté trois nouveaux rapports, nécessitant Sun Report Builder, pour étudier les possibilités de ce dernier :
un rapport Employés (avec un champ image) et deux nouvelles versions des rapports analyse des Ventes et Ventes Annuelles avec les fonctions de Cumul du SRB.

Juste un aperçu...
Je creuserai par la suite les fonctions de diagrammes...

A suivre,

Jérôme

P.S. La base a été téléchargée à peu près 300 fois depuis sa mise en ligne en septembre...

[jerome bourgeois]

Bonjour,

A propos de la base comptoir et du SRB (Sun Report Builder) à moins que ça ne soit l' ORB (Oracle Report Builder) je crois avoir levé un bug... mais faut dire que je ne l'ai pas encore complètement apprivoisé...

J'aimerais savoir si vous pouvez le reproduire chez vous...

Il s'agit du formatage du mois de la date 1,2,3...
Chez moi, il n'affiche que janvier indépendamment du numéro de mois... comme dans le rapport Ventes annuelles(srb)

Sinon, si bug il ya , est-il à la connaissance de quelqu'un recensé ?

Cordialement et merci,

Jérôme

[spYre]

Bonjour jerome,

Tout d'abord bravo pour l'initiative et pour le travail fourni !

J'ai testé le rapport en cause, sans pouvoir reproduire le problème. Ci-dessous une copie d'écran de la dernière page des ventes 1997 :

En revanche, lorsque j'ai voulu ouvrir le rapport en mode édition pour étudier la source, celle-ci apparaît instable et se modifie d'office à l'édition
À première vue ce serait dû au mode requête paramétrée, mais quant à savoir pourquoi...

Bon courage pour la suite.

[jerome bourgeois]

Merci Spyre,

En fait, le problème des dates se trouve dans les entêtes (en lettre) comme tu peux le voir dans cette copie d'écran où le mois de janvier ne correspond pas au mois en cours (février)...

As-tu la même chose ???

Cordialement,

Jérôme

[jeanmimi]

Bonjour,
Peux tu essayer de modifier la requête Ventes annuelles de cette façon pour extraire le mois et l'année de la date des commandes :

Code : Tout sélectionner

SELECT "Commandes"."Date commande", "Commandes"."Destinataire", "Commandes"."Date envoi", "Commandes"."N° commande", "SousTotauxCommandes"."SousTotal", YEAR( "Date commande" ) AS "Année", MONTH( "Date commande" ) AS "Mois" FROM "Commandes" AS "Commandes", "SousTotauxCommandes" AS "SousTotauxCommandes" WHERE "Commandes"."N° commande" = "SousTotauxCommandes"."N° commande" ORDER BY "Commandes"."Date commande" ASC, "Mois" ASC

En créant le rapport sur cette requête avec le SRB, j'obtiens ce type de document (je n'ai imprimé que la page 1), mais avec encore un problème sur le format du mois :

Ventes_annuelles_SRB.pdf

(4.7 Kio) Téléchargé 606 fois

[spYre]

Re,

Le mois
Le problème vient que tu demandes un formatage 'date' pour une valeur numérique qui n'a plus rien à voir. Ainsi, 1 pour janvier est compris comme 31.12.1899, qui est la date de référence pour OOo. Les valeurs 2 à 12 équivalent donc à 1.1.1900, 2.1.1900, etc.
Il suffit simplement de remplacer le champ de données "Mois" par "Date d'envoi", sans rien changer au formatage ni aux groupements.

Le problème d'édition
Je le reproduis systématiquement, et il disparaît dès que je supprime l'instruction "ORDER BY" de la requête source. Il y a visiblement conflit avec les tris SRB, ou autre chose qui m'échappe. En attendant de comprendre, il semble donc préférable de gérer les tris dans la seule boîte de dialogue "Tris et regroupements" (on peut très bien spécifier un tri sans regroupement).

@edit : quelques précisions
Le problème n'apparaît qu'à l'édition du rapport (clic droit-> modifier puis bouton "trois-petits-points" du champ 'contenu') : la colonne MONTH("Date envoi") est remplacée par "Date envoi" . Même chose, logiquement, si je désactive le mode ébauche pour afficher le sql.
Le comportement est le même si je fais le test dans une requête hors SRB, donc celui-ci n'est en fait pas en cause. En revanche, en mode sql direct, aucun souci. Il semblerait que ce soit l'interpréteur sql de Base qui pose problème... À moins que quelque chose d'évident ne m'ait échappé...
Cordialement.

[jeanmimi]

remplacer le champ de données "Mois" par "Date d'envoi"

Pour moi, ça fonctionnerait plutôt en choisissant "Date commande"
Pour la requête, je trie bien comme tu l'as vu dans le code.

[jerome bourgeois]

Merci à vous deux...

Il est clair que le formatage de Base ne reconnaît pas la fonction date de HSQLDB... Des fois, j'ai honte (formateur OpenOffice quand-même !)... Encore un bug qui se trouvait entre la chaise et le clavier !
Côté HSQLDB, j'ai bien trouvé la fonction MONTHNAME qui n'est pas mal sauf qu'elle est ... en anglais et qu'après le tri côté Base se fait alphabétiquement ! Ben oui ! Pareil !
Heureusement, vos solutions marchent lorsqu'on remplace le "mois" par la "date d'envoi" dans le rapport mais parce qu'au préalable on a indiqué un groupement par Mois = MONTH("date envoi") ... Ainsi, remplacer le champs MONTH(date envoi") par "date envoi" directement dans la requête, fait que dans le rapport les dates sont regroupées ... par date et plus par mois même si le formatage indique bien chaque jour le même mois ! Donc du coup, on est bien obligé de passer par un champs Month("Date") côté SQL pour le regroupement et le remplacer après dans le rapport en mode édition par la date elle-même (avec le format qui va bien)... Logique après coup (comme toujours), mais encore fallait-il y penser

@spYre : Pour ce qui est de l'édition de la requête, en effet c'est du SQL direct... D'ailleurs, j'ai remplacé (dernière version) dans le navigateur de rapport le type de contenu : Instruction SQL par requête, histoire que le rapport puisse être généré dynamiquement (paramètres obligent) par un appel de macro... Même s'il n'est pas lié au menu pour l'instant... allez pour la 3.2, je passe full SRB !

Et encore merci,

Jérôme

[jeanmimi]

Comme le fichier devient plus volumineux que ce que le forum peut accepter, j'ai mis une version ici :
http://dl.free.fr/g46xfW3Qg
Elle illustre ce que tu as décrit dans ton dernier message : la requête avec l'extraction du mois, et le champ de SRB Mois qui doit chercher sa source dans la Date_commande ou la Date_Envoi pour la cohérence du format du mois.

[jerome bourgeois]

Merci JeanMimi, mais je mets régulièrement la base à jour... Le lien étant hébergé chez moi...

[jerome bourgeois]

En fait en creusant la question, il y a une autre solution avec le SRB qui consiste à dupliquer le champ "date d'envoi" dans la requête en y ajoutant un alias ... par exemple

Code : Tout sélectionner

select "date envoi" as Mois, ...,"date envoi"...

et en faisant un regroupement par l'alias du premier (ici : "Mois") et en choisissant dans la fenêtre "tris et regroupements" le regroupement par mois...
Peut-être plus simple mais je ne le mets pas en place pour le moment car ça me flinguerait mon rapport "classique" basé sur la même requête.

Sinon, j'ai mis en ligne un nouveau projet ici http://user.services.openoffice.org/fr/ ... 26&t=20777 qui fait appel au SRB, mais c'est pus simple, vu que c'est un regroupement hebdomadaire... Pas besoin de conversion de format... La fonction WEEK de HSQLDB suffit dans ce cas là !

[Courstoujours]

Je voudrais finir avec un grand merci à ce forum dans lequel je me suis servi abondamment et je ne saurai également que recommander le livre "Programmation OpenOffice .org 3" ! Et enfin que tous ceux qui pensent se reconnaitre dans mes macros en soient remerciés !

Voilà, si le coeur vous en dit,

Cordialement

Jérôme

N.B. Le fichier étant en fait trop lourd (990 kio pour 500 autorisés), je me permets de mettre un lien direct vers son téléchargement :http://xlinfo.net/clic.php?url=Comptoir.odb

Bonjour,
j'ai récupéré le .odb ! et j'ai du mettre les mains dans le moteur, je m'explique, dans "une commande" lorsque je selectionne un produit, il bogue et me renvoi à la macro Module 2 "listBox.Parent.getByName("Prix unitaire").value = Resultat.getdouble(1) " avec pour message "variable d'objet non définie". Je ne vois pas le problème pouvez-vous m'éclairer?

[jerome bourgeois]

Désolé d'avoir mis si longtemps à vous répondre...

Je n'arrive pas à reproduire le bug...
Quel formulaire ? Nouvelle commande ? Pourriez-vous détailler plus ....

[Courstoujours]

Mille excuses, je n'ai plus le problème je pense, qu'il était lié à open 3.2, car depuis que je suis revenu au 3.1 plus de problème.

Merci encore et bravo pour ce travail de traduction


Mon objectif etait "comme dans comptoir" de faire un copier coller du prix d'un produit dans une autre table
J'ai essayé d'extraire la macro "module 2 actualiser" pour la remettre dans une autre table, sans succès.

Pourriez-vous regarder mon essai merci.

prixunitaire.odb

(14.55 Kio) Téléchargé 555 fois

Plus de problème j'ai trouvé mon problème: dans formulaire la propriété de "prix" n'était pas en format numérique "Numeric Field"
Voici en copie la version corrigée

prixunitaire.odb

nouveau fichier

(15.24 Kio) Téléchargé 713 fois

merci à tous