Discussion :

[smyley]

Oracle c'est gratuit ?

Sinon pour utiliser Access il ne suffit pas de redistribuer JET et autres sauces MDAC et compagnie ?
Ou alors si c'est du Windows Only (bah Access ...) tu pourrai peut être regarder SQL Server CE ou SQL Server Express. A la limite si tu n'en demandes pas trop à la base de donnée tu pourrai carrément te tourner vers SQLite comme solution de DB ...

Ou encore, peut être que ceci pourrai t'aider :
http://argyronet.developpez.com/offi...e/?page=page_3

[master_och]

Oracle c'est gratuit ?

Bah à toi de répondre si je me trompe, en fait dans le site d'oracle y'en a plein de versions et tout semble gratuit, j'ai tombé sur la version ORACLE JDevelopper, ce qui donne l'impression d'avoir une relation avec java je l'ai donc telechargé et c'est tout à fait gratuit, tout ce que ca vaux c'est la création d'un compte dans le site .
Mais le problème c'est que je comprends toujours pas à quoi sert ce JDevelopper

Sinon pour utiliser Access il ne suffit pas de redistribuer JET et autres sauces MDAC et compagnie ?

Jamais entendu de ces trucs peux tu m'éclaircir un peu la dessus stp?

Ou alors si c'est du Windows Only (bah Access ...) tu pourrai peut être regarder SQL Server CE ou SQL Server Express. A la limite si tu n'en demandes pas trop à la base de donnée tu pourrai carrément te tourner vers SQLite comme solution de DB ...

Justement la portabilité est une des raisons qui me pousse à migrer vers oracle (ou autre SGBD gratuit plus simple si vous connaissez d'autres).

Concernant ma base de données, elle contient 23 tables "reliés", même si les relations que j'ai effectué sous access ne me sont pas d'une grande utilité, puisque mon programme est supposé anticiper les notifications d'integrité de données générées par access.

bien entendu j'ai effectué la connexion de la base de donnée avec le systeme en passant par outils d'administration\Sources de données (ODBC) etc ... j'ai nommé ma base javalait, ensuite voici le code que j'ai utilisé pour établir la connexion entre le programme et la base :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
try {
	        Class.forName("sun.jdbc.odbc.JdbcOdbcDriver");
	    }catch(ClassNotFoundException e)
	    {System.out.println("impossible de charger le drivers");}
	    try {
	 	   final String url="jdbc:odbc:javalait";
	            con=DriverManager.getConnection(url,"","");
	    }catch(SQLException e)
	    {System.out.println("impossible de crèer une connexion");}

toutes mes requetes sql sont exécutées à travers des PreparedStatement.

J'éspère avoir fourni assez clairement toutes les informations necessaires sur la procédure de communication entre le programme et la base, en contre partie j'éspère obtenir votre aide qui me sera certainement d'une grande utilité.

merci d'avance

[sinok]

Ce serait un peu dommage de limiter ton appli à Windows alors que c'est du java...
Tu devrais te pencher vers des sgbd que tu peux embedder dans ton application très facilement.
De plus il en existe certain qui sont écrits totalement en java comme Derby ou HSQLDB. Pour les utiliser il suffit d'inclure le jar à ton appli et l'affaire est fini (bon faut un peu écrire la partie SQL pour la création des tables et vérifier que les requêtes que tu as codées pour access sont bien compatibles).

De plus ces deux SGBD sont stables, bien documentés, utilisables depuis un client comme Squirrel. Et tout ça en open source bien sur.

Puis en plus à déployer c'est quand même vachement (la j'suis pil poil niveau vocabulaire) plus simple qu'Access. Juste un jar à ajouter au livrable, pas de package à redistribuer, par de source ODBC à créer toussa toussa.

[master_och]

Bonjour sinok

Toujours là pour me sauver la vie !

Bon je vais essayer de me renseigner un peu sur Derby, et je te tiens au courant si j'aurais des problèmes ...

Merci bien pour les infos

[CinePhil]

J'ai cru comprendre, à la lecture d'une image de ton appli, que celle-ci n'est pas développée en France (éleveur à Bizerte) ?

Il se trouve que j'ai travaillé à l'INRA sur une BDD relative aux bovins pour un thésard de l'école vétérinaire de Toulouse. Je ne travaillais pas directement sur la BDNI mais sur une extraction de données pour des études statistiques sur l'élevage bovin et une autre sur le contrôle laitier pour une autre thésarde.

Les numéros d'identification des bovins dans ton appli ne semblent pas correspondre aux NUMNAT utilisés en France.

Si tu veux vendre ton appli aux français, il faudrait qu'elle soit compatible avec les critères de la BDNI (Base de donnée nationale d'identification).

Ton appli semble intéressante mais je ne sais pas si ça fait doublon avec certaines fonctions de la BDNI que les éleveurs renseignent maintenant depuis chez eux par internet.

Bon courage pour la suite !

[master_och]

J'ai cru comprendre, à la lecture d'une image de ton appli, que celle-ci n'est pas développée en France (éleveur à Bizerte) ?

bah t'as bien compris, en fait l'éleveur pour lequel je developpe l'application est bien en tunisie, et y'en a encore 3 ou 4 autres eleveurs tunisiens qui veulent tester l'application.

Pour ce qui est de la vente en France, j'aimerai bien en arriver là, même si c'était pas prévu à l'avance!
Je pourrais bien faire les modifications necessaires sur demandes biensure!

Concernant les Numéros officiel des vaches la seul contrainte que j'ai imposé c'est que ce doit être un entier positif, pour les codes nat des taureaux j'ai rien imposé puisque ce code peut contenir des lettres.

Voilà merci bien pour l'encouragement

[CinePhil]

Concernant les Numéros officiel des vaches la seul contrainte que j'ai imposé c'est que ce doit être un entier positif, pour les codes nat des taureaux j'ai rien imposé puisque ce code peut contenir des lettres.

Mettre un type entier pour un code est une mauvaise idée !

C'est comme si tu disais "Le numéro de sécu ne contient que des chiffres alors je mets un type entier."
Idem pour le code postal : celui de Foix n'est pas l'entier 9000 mais la chaîne de caractères '09000'.
Idem pour les numéros de téléphone : ils commencent tous par zéro en France (hors numéors courts et spéciaux). Si tu mets un entier tu perds le zéro.

Les NUMNAT français sont effectivement composés de chiffres mais forment une chaîne de 12 caractères (de mémoire, c'est peut-être 10 je ne sais plus).

Bref, on en tire la règle générale : un code, une référence, est toujours de type caractère et jamais de type numérique.
Ne seront de type numérique que :
- les identifiants "informatiques" (pas présentés à l'utilisateur) dans les tables ;
- les quantités (prix, mesure, dose, capacité, distance...), c'est à dire des données qui pourront faire l'objet de calculs.

[master_och]

Mettre un type entier pour un code est une mauvaise idée !

Mais qui a dit que les numéro officiel sont de type entiers, j'ai juste dit qu'il y aura un controle n'acceptant que des chiffres...
cela dit que mes numéro officiel sont bien des strings, et que les zéro au début d'un numéro sont tout à fait pris en compte

Une autre raison qui m'a mener à choisir le type chaine de caractères pour ces numéros, c'est par précaution d'avoir des cas où les numéros officiels dépassent la valeur max d'un long ...

[master_och]

Bonjour sinok

J'ai a peu près terminé avec la documentation de Derby, sauf qu'il me reste une toute petite question que j'ai posé ici http://www.developpez.net/forums/d79...t/#post4589828, sans réponse jusqu'à maintenant.

Et vu que c'est toi qui m'a dirrigé vers Derby je me suis dit que peu être t'auras une idée.

J'attends ta réponse, et merci d'avance

[master_och]

Bonjour

Un peu trop en retard, mais je poste quand même .

Voici un lien vers une version DEMO : [ame="http://www.megaupload.com/?d=WQ2IUAWZ"]MEGAUPLOAD - The leading online storage and file delivery service@@AMEPARAM@@Filename:</font> <font style="font-family:arial; color:#FF6700; font-size:18px; font-weight:bold;">CLIENT APPLICATION.rar@@AMEPARAM@@CLIENT APPLICATION.rar[/ame]


- la durée d'évaluation est de 2 mois.

- cette version démo n'accepte pas plus de 120 femelles.

- un fichier lisez moi est inclus dans l'archive pour expliquer l'installation de l'application.

- la base de données contient une liste de maladies, et une liste de medicament (qui ne sont pas exhaussives). Aucune femelle, male ni vaccin n'a été enregistré ==> c'est à l'utilisateur de remplir sa base de données relativement à ses propres données.

- Vu le manque de temps j'ai pas encore réalisé un manuel d'utilisation, ce serait fait dès que j'aurais un peu de temps libre, cependant je suis près à répondre à toutes vos questions dans ce topic.


J'attends vos remarque/avis/questions.

Merci d'avance.


- Concernant le look and feel substance, j'ai laissé tomber puisqu'il s'est avéré qu'il n'est pas stable. Je me suis contenté du Look & Feel standard en fin de compte.

[master_och]

Bonjour

Voici une nouvelle mise à jour de l'application avec beaucoup d'améliorations.

http://www.2shared.com/file/i5zTicmI/COWBOY_Demo.html

L'archive contient les fichiers suivants:

- Le repertoire contenant les fichiers de l'application. Ce répertoire englobe une base de données contenant des informations +/- réalistes pour la démonstration.

- une base de données vide.

- une base de données contenant une liste de médicaments + une petite liste de vaccins + une liste de maladies.

- un répertoire setup permettant d'installer la license d'évaluation.

- un fichier .txt pour expliquer l'installation de l'application.

- un manuel d'utilisation sous format PDF.

N'oubliez pas de poster vos commentaires/avis si jamais vous testez l'application.

Merci d'avance

[zecreator]

Bravo master_och pour ton travail. Elle a de la gueu... ton application.

Je suis d'accord avec sinok : pourquoi développer en java, et utiliser un SGDB Windows ?

Est-ce que ton application est sencée être utilisée uniquement en local en mono-poste, ou peut-elle être utilisée en multi-poste à travers un réseau ?

Si c'est juste du local, tu aurais pu utiliser du XML. Les parsers DOM et SAX Java sont plutôt puissants, c'est standard.

Si c'est pour du réseau, pourquoi ne pas tenté du J2EE ?

Ne perds pas de vue que l'application devra être installée, et selon la technicité de ton application, certains pourraient manquer de compétences pour le faire eux-même. je pense notement à l'installation et la configuration d'un SGDB...

Mais encore bravo pour ce joli boulot...

[zecreator]

ha ben tiens, il me vient une idée, je ne sais pas si tu y avais pensé master_och.
Ce serait peut-être utile d'avoir une application mobile qui permettrait à l'éleveur de se connecter à ses données à distance (par exemple, il entre le N° d'un animal et voit sa fiche...).
Cela peut-être fait en J2ME ou en HTML 5 (pour les mobiles Apple).
C'est juste une idée qui me traverse l'esprit, je te la donne comme elle me viens

Bonne continuation.

[sinok]

Bravo master_och pour ton travail. Elle a de la gueu... ton application.

Je suis d'accord avec sinok : pourquoi développer en java, et utiliser un SGDB Windows ?

Est-ce que ton application est sencée être utilisée uniquement en local en mono-poste, ou peut-elle être utilisée en multi-poste à travers un réseau ?

Si c'est juste du local, tu aurais pu utiliser du XML. Les parsers DOM et SAX Java sont plutôt puissants, c'est standard.

Le problème a déjà été traité, relis la discussion, l'application tourne désormais avec une base embarquée sou Derby.

Ne perds pas de vue que l'application devra être installée, et selon la technicité de ton application, certains pourraient manquer de compétences pour le faire eux-même. je pense notement à l'installation et la configuration d'un SGDB...

Euh, pour une application java de ce genre, installer = décompresser une archive, ce n'est pas chose très difficile.

[master_och]

salut zecreator

Bon je vois que Sinok (que je salut fort) t'a déjà répondu.

Est-ce que ton application est sencée être utilisée uniquement en local en mono-poste, ou peut-elle être utilisée en multi-poste à travers un réseau ?

Si c'est juste du local, tu aurais pu utiliser du XML. Les parsers DOM et SAX Java sont plutôt puissants, c'est standard.

Mon application est en fait sencée être utilisée en local uniquement, mais vu que j'ai utilisé Derby comme base de données, il sera facile de transférer les données d'une machine à une autre rien qu'avec un simple copier coller.

Concernant XML, il n'est pas sensé remplacer les bases de données à ce que je sache, il est plutot à utiliser lorsqu'il s'agit d'enregistrement de données de faibles tailles.

Pour ce qui est de DOM et de SAX, en fait je les connais pas mais je suis tout à fait satisfait avec Derby.

Voilà en tout cas merci pour ton intervention.

[zecreator]

Derby est très intéressant effectivement, mais attention elle ne prend qu'une seule instance à la fois.

En mode embarqué, une base Derby ne peut donc pas être partagée par plusieurs applications. Si tu as besoin d'avoir plusieurs applications qui accèdent de manière concurrente à une base Derby, il te faudra utiliser le serveur livré avec la distribution de Derby.

Donc, passer par une phase d'installation coté serveur.

[sinok]

Derby est très intéressant effectivement, mais attention elle ne prend qu'une seule instance à la fois.

En mode embarqué, une base Derby ne peut donc pas être partagée par plusieurs applications. Si tu as besoin d'avoir plusieurs applications qui accèdent de manière concurrente à une base Derby, il te faudra utiliser le serveur livré avec la distribution de Derby.

Donc, passer par une phase d'installation coté serveur.

En même temps si tu embarque Derby dans une appli, le but est de faire du Standalon, pas quelque chose de distribué.

Son appli n'a pas franchement vocation à posséder une BD centralisée...
Je ne vois pas trop le bénéfice qui pourrait en être tiré...

L'appli est prévue pour permettre à un éleveur de recenser ses bêtes. Le besoin d'un serveur SGBD distribué est loin d'être évident et amène pas mal de constraite (en particulier l'obligation de connexion au réseau, le fait que pour des raisons de sécurité on ne laisse jamais un client accéder directement à un SGBD mais qu'il faut coder une couche logique entre les deux afin de contrôler toutes les requêtes émises en direction de la base et ainsi de suite).

[zecreator]

Je pense juste que ce type d'application peut très rapidement entrer dans un effet de gamme.

D'après ce que j'ai lu plus haut, il ne s'agit pas seulement d'une commande particulière mais de pouvoir la distribuer (commercialiser ?).

Du coup, le besoin d'avoir une centralisation des données (je pense par exemple à groupement d'éleveurs) peut se présenter et il faudra bien penser à une version client-serveur.

[master_och]

En fait la société pour laquelle j'ai développé l'application, n'a pas éxigé une structure client - serveur, pour la simple raison que cela demandera beaucoup plus d'effort de developpement (ce qui coutera beaucoup plus chère), sans être d'une grande utilité.

(je pense par exemple à groupement d'éleveurs)

Si un groupe d'eleveurs veulent échanger leur données (pour se comparer par exemple ?), il peuvent échanger leurs bases de données. Comme je l'ai déjà dit cet échange de données ne necessitera rien de plus qu'un simple copier coller.

[master_och]

Voici une nouvelle mise à jour, juste au niveau du design du tabbedpane.

[ame="http://www.megaupload.com/?d=PQ7K7LFS"]MEGAUPLOAD - The leading online storage and file delivery service@@AMEPARAM@@Filename:</font> <font style="font-family:arial; color:#FF6700; font-size:22px; font-weight:bold;">COWBOY DEMO.rar@@AMEPARAM@@COWBOY DEMO.rar[/ame]

un petit aperçu: