Cheetah_chm

J' ouvre ce sujet pour ne pas parasiter celui de Kgf_chm.

La définition est la même pour "CheetahLoadDll" et "CheetahShutdown".

Merci. C'était un oubli de distribution et c'est corrigé.

Là, c' est pas clair...



la commande est simple, son contenu moins

field=	Nom du champ	Type	Nbre caracteres	Décimals
field=	Mon_champ1,	C,	1 à 254,	0
field=	Mon_champ2,	N,	8 octets,	?	Nbre de decimals après la virgule ? ou  1=vrai 0=Faux ?
field=	Mon_champ3,	D,	8 octets,	0
field=	Mon_champ4,	L,	"T", ou "F", ou "",	0
field=	Mon_champ5,	M,	4 octets,	0

Qu'est-ce qui n'est pas clair, là-dedans ? Voici les types de champs en format DBase:

Citation :

types pour DBASE:
C = 1 à 254 caractères (texte)
N = numérique,
8 octets dans la base, 1 à 20 octets affichés
valeurs -.9999999999E+19 à .9999999999E+20
D = date: 8 octets 20040719   0001-01-01 à 9999-12-31
L = logique (booléen) ("T"=true, "F"=false, " "=indéfini)
M = mémo (4 octets dans l'enregistrement)
le fichier mémo a l'extension *.dbt

Format C - Caractères - champ texte de longueur variable de 1 à 254 caractères dans le fichier
Format N - Numérique - champ binaire mémorisé sur 8 octets dans le fichier
Format D - Date - champ texte mémorisé sur 8 octets dans le fichier, sous forme aaaammjj
Format L - Logique - champ texte mémorisé sur 1 octet avec valeurs possibles "T" (true), "F" (false) et " " (indéfini)
Format M - mémo - champ binaire mémorisé sur 4 octets dans fichier, représentant un pointeur dans le fichier de mémos associé à la base de données. Les textes peuvent être de longueur totalement libre.

Est-ce plus clair comme ça ?

EDIT

Juste pour être encore plus clair: peu importe comment ces informations sont mémorisées dans la base. Eb réalité, une base de données sert à cela: elle s'occupe du stockage et de la recherche des informations. la façon interne de faire cela est parfaitement insignifiant pour le programme extérieur. Les fonctions documentées dans le section "Lecture d'enregistrements" servent justement (entre autres) à récupérer les informations, dans des variables Panoramic, tout en ignorant totalement la façon interne de mémorisation de ces éléments.

C'est en effet une façon différente de voir la gestion d'information. Normalement, on a intuitivement tendance à vouloir maîtriser le contenu, champ par champ, et de pourvoir localiser, lire ou modifier le contenu d'un champ, en le manipulant directement. Mais ce n'est pas comme ça qu'une vraie base de données travaille, et ce n'est pas comme ça que Cheetah travaille. Un champ est une entité logique, manipulée par des fonctions. Ces fonctions injectent une variable Panoramic (ou le contenu d'un mémo entier dans le cas d'un champ de type M) dans la base, sans avoir à se soucier de la position de l'information, de son codage, de la place que ça prend etc. On manipule juste la notion logique de "champ". Pareil pour la lecture: on récupère le contenu d'un champ de la base dans une variable Panoramic (ou dans un mémo !), sans savoir du tout où se trouve l'information. Il suffit d'indiquer le champ à la base qui fait le reste du travail.

Le truc pas clair est la chaine de caractères à monter dans cmd$

field="Nomduchamp,type (CNDLM),par1$,par2$"

pour Memo tu dis que par1$ est un pointeur sur un fichier *.dbt 
youpi !...
...et moi je mets quoi ? 4 pour réserver 4 octets ou le pointeur ?

par2$ = décimals
là encore youpi !

je mets le nombre de decimales voulu après la virgule ou une valeur boleenne (1 ou 0) ?

d' où mon petit tableau 

Ma logique voudrait que, même si ce n' est pas le cas, 
en tout cas cela n' a pas l' air de l' être pour le type L, 
que par1$ et par2$ soient str$(NbreOctetsAReserver).

Je ne comprends pas ce que tu veux dire. Quelle fonction ? Exemple ?