UNE DATABASE
cs_Nono40
Messages postés
962
Date d'inscription
mercredi 3 avril 2002
Statut
Membre
Dernière intervention
12 septembre 2006
-
13 oct. 2002 à 22:39
cs_bassma Messages postés 6 Date d'inscription mercredi 11 avril 2001 Statut Membre Dernière intervention 10 août 2005 - 10 août 2005 à 06:42
cs_bassma Messages postés 6 Date d'inscription mercredi 11 avril 2001 Statut Membre Dernière intervention 10 août 2005 - 10 août 2005 à 06:42
Cette discussion concerne un article du site. Pour la consulter dans son contexte d'origine, cliquez sur le lien ci-dessous.
https://codes-sources.commentcamarche.net/source/12178-une-database
https://codes-sources.commentcamarche.net/source/12178-une-database
10 août 2005 à 06:42
En fait le fichier n'est plus disponible sur http://www.freebase.tuxfamily.org/, puisque le serveur a été hacke il y a peut être 1 ou 2 ans et les fichiers ont été supprimés.
Sinon, la Freebase a subi d'ènorme modification et actuellement c'est la version V3 et elle sert de database pour SoftaMedCab, un logiciel de gestion de cabinet médical gratuit disponible sur http://www.softamed.com .
Bonne continuation
Bassma
28 oct. 2002 à 04:28
C'est un projet open source. Tout ceux qui ont envie d'y participer seront le bienvenue.
14 oct. 2002 à 23:16
Pour la strcuture des fichiers c'était surtout des remarques comme ça, il n'est pas nécessaire de tout changé. Je n'ai pas essayer de faire des tests de vitesses. Et je suppose que l'objet de la dll n'est pas de remplacer Oracle 8. J'ai vu que tu gérais bien l'ouverture multiple d'une base par plusieurs programme sur le même PC.
J'ai aussi une idée, mais ce n'est sans doute pas évident : il faudrait créer TMaTableBase descendant de TDataBase pour gérer tes bases de données. Ainsi on pourrait utiliser toutes les interfaces toutes faites de Dephi sur la gestion des BDD... ( c'est juste une idée comme ça ... )
Bonne continuation...
Nono.
14 oct. 2002 à 03:26
Tout vient du fait que tu utilise des majuscule dans les noms de field.
Avec les minuscules tout va s'arranger , ca fonctionne avec les minuscules.
utilise colb au lieu de COLB. et tu verras ca marche.
Tu tiens vrament a utiliser des majuscules dans les nom de field ??? c'est peut etre le seul bug (majuscule).
Bon, ca fait un moment que je n'ai pas touche a la classe table. j'ai peure de tout casser. mais je m'y metterais bientot.
14 oct. 2002 à 03:00
Et puis la table est peu rapide, donc mieux vaut creer des records (ex reccreatefromtable) permet de transformer ta table en record que tu peux par la suite travailler dessus dans la RAM (modifier 50 fois si tu veux ton enregistrement) et a la fin tu fais RecUpdateRecord, ceci vas upgrader ta table (et ecrit les donnes dans la table.
Mais c'est bizzare que tabgetnumfield n'a pas marche !!!!!!!!!!!
je viens de verifier ca marche. peux tu me donner ta fonction ???
d'abord verifier que
1 -le serveur est ouvert.
2- verifier que le nom du field est bon.
numfield := udll.tabgetnumfield(numtab,str1); doit obligatoirement marcher car sinon, l'exemple ne fonctionnera pas pour afficher les donnees dans les memos.
Je m'explique, vas dans
procedure TForm1.btnnextClick(Sender: TObject);
et met showmessage(inttostr(numfield));
apres
if numfield >= 0 then begin intres := udll.tabgetfieldvalue(numtab,numfield); mme1.Text := string(intres); end;
tu recupereras la valeur de numfield (0 ca veut dire le premier champ)
salut
14 oct. 2002 à 02:25
En effet, j'ai fait quelques modifications avant de uploader, j'ai passer les noms de record et nom de field et typefield en shortstring au lieu de string pour faciliter le passage des donnees entre dll et application. J'ai peut etre toucher par megard a autre chose.
je viens de lire ton message, c'est un peu tard, je vais demain verifier ce qui ne va pas pour repondre a tes questions.
Sinon, j'ai realiser des record de 200 000 enregistrements tres tres rapide en recherche et etc........
pour les donnes quand tu envoies par setvalue, il faut obligatoirement tout envoyer par string (integer(string)) que ca soit des integer float etc, puisque tout est garder dans la table (dof) en string.
pour ameliorer la rapidite, tout changement , s'effectue par ajout. et c'est vrai la table va s'agrandir rapidement. d'ou la fonction compacttable.
Cette structure en trois table est tres rapide.
A demain.
13 oct. 2002 à 23:38
Nono.
13 oct. 2002 à 23:32
J'ai vu aussi qu'il n'est pas possible de modifier la structure d'une base tant qu'elle est ouverte deux fois : c'est plutôt mieux !
J'ai aussi regardé un peu la structure des fichiers, tu travailles en permancence sur des chaines dans le fichier .DOF, à chaque modification d'enregistrement tu ajoutes en fin de fichiers, en cas de modification fréquente, ceci augmente rapidement la taille du fichier. Ce n'est pas la méthode utilisée généralement dans les BDD pour les champs simple ( STRING[] FLOAT INTEGER DATETIME ). En général le champ STRING à une longueur fixe définie au moment de l'ajout de la colonne. Le type integer est directement stocké en format binaire sur 4 octect et le type FLOAT et DATETIME au format Double directement compatible avec le FPU. Ensuite chaque enregistrement occupe une longueur fixe dans la base dont la longueur est la somme des tailles de champs. C'est un peu comme ça que tu as fait dans le fichier .SOF mais au lieu de stocker des pointeurs vers le fichier .DOF c'est directement les valeurs qu'il faudrait stocker. La méthode que tu utilises est surtout utile pour les champs dont la longueur n'est pas limitée comme les type BLOB et BINAIRE.
Nono.
13 oct. 2002 à 23:01
Ainsi on pourrait voir ce qui ne va pas...
J'ai une remarque d'ordre général :
Quel est l'usage de tout ceci ? Le bases de données ne manquent déjà pas dans delphi ( BDE ADO DBEXPRESS IB ) et sur tout type de table, en client sever etc etc...
Nono.
13 oct. 2002 à 22:39
Bon, j'admire toujours ceux qui ré-inventent la roue...
J'ai quelques soucis pour faire fonctionner ton programme d'exemple. J'ai vu déjà que si les noms de champs ne sont pas en majuscule, on ne peut pas renommer les colonnes. Ensuite pour afficher/modifier des valeurs il faut faire glisser les colonnes sur les memos pour les associer à des champs. Mais là pas moyen de modifier des enregistrements. A priori les bouton AddRec et DelRec fonctionnent car quand on ouvre de nouveau la table, le nombre d'enregistrement est correct. Par contre il semble que les valeurs ne soient pas conservées dans les fichiers ( j'ai regardé avec un éditeur binaire ).
J'ai suivi la méthode suivante, dis moi si je me trompe :
- Création d'une table ESS.TOF avec un champ COLB de type 1 ( string )
- Ouverture de la table ( elle s'affiche bien dans la liste )
- Je clique sur le nom => les colonnes sont biens affichées dans la liste du bas
- Je glisse la colonne ( COLB ) sur le memo en haut à gauche => COLB remplace bien le Record1 par défaut.
- Je clique sur "Add Enr"
- Je saisie la valeur ABC dans le mémo et je clique sur "Mod Enr"
- Je ferme la table
Bon pour vérifier :
- J'ouvre la table, je clique dessus et je glisse le champ COLB sur un des memos.
- Pas moyen de lire la valeur 'ABC' ( même avec first next last...)
Je me trompe sans doute quelque part, mais sans avoir le source de la dll, ce n'est pas facile de voir ce qui cloche. En fait il semble que le udll.tabgetnumfield(numtab,str1) ne fonctionne jamais. numtab vaut bien 0 et str1 'COLB', mais la fonctionne retourne en permanence -1.
J'ai aussi une remarque : dans l'aide tu précise qu'il faut passer la valeur d'un champ par Integer(ValeurChaine) mais comment passe-tu la valeur d'un Float ( de type Double ) ou d'une date ( TDateTime ). Car pour être optimisé ta dll ne doit surtout pas convertir en permanence. Pour les valeurs des champs il faudrait que tu utilises le type VARIANT, car ainsi n'importe quel type de valeur pourrait être passé en paramètre, ta dll se chargeant ( automatiquement : merci Delphi ) de la conversion dans le type réel du champ.
Nono.