C++ et excel ou access
Fermé
64fred64
Messages postés
3
Date d'inscription
samedi 18 novembre 2000
Statut
Membre
Dernière intervention
8 juillet 2005
-
8 juin 2005 à 21:41
michelatoutfox Messages postés 828 Date d'inscription mardi 5 octobre 2004 Statut Membre Dernière intervention 7 mai 2013 - 22 juil. 2005 à 11:03
michelatoutfox Messages postés 828 Date d'inscription mardi 5 octobre 2004 Statut Membre Dernière intervention 7 mai 2013 - 22 juil. 2005 à 11:03
A voir également:
- C++ et excel ou access
- Liste déroulante excel - Guide
- Si et excel - Guide
- Word et excel gratuit - Guide
- Formule excel - Guide
- Aller à la ligne excel - Guide
5 réponses
Char Snipeur
Messages postés
9696
Date d'inscription
vendredi 23 avril 2004
Statut
Contributeur
Dernière intervention
3 octobre 2023
1 297
9 juin 2005 à 09:28
9 juin 2005 à 09:28
oui, bien sur.
64fred64
Messages postés
3
Date d'inscription
samedi 18 novembre 2000
Statut
Membre
Dernière intervention
8 juillet 2005
9 juin 2005 à 20:47
9 juin 2005 à 20:47
t'es bien gentil mais est-ce que tu pourrais me dire comment je fais! et si ta reponse est oui bien sur et rien d'autre, tu peux t'abstenir.
merci d'avance
merci d'avance
Char Snipeur
Messages postés
9696
Date d'inscription
vendredi 23 avril 2004
Statut
Contributeur
Dernière intervention
3 octobre 2023
1 297
10 juin 2005 à 10:59
10 juin 2005 à 10:59
Salut.
je te répondrai : question précise, réponse présice.
je ne connais pas le format .dbf, mais il est toujours possible de le lire, et d'y ecrire. Le problème suivant c'est de savoir comment est codé le fichier ? Si il est codé, il existe souvent des bibliothèques C++ qui permettent de gérer ces fichiers facilement (sans tous reprogrammer les algo de compression decompression).
pour finir, je ne sais pas non plus ton niveau en C++. Ta question pourtai elle aussi sur les moyens d'ouvrir un fichier en C ??
ce n'es pas pour etre desagreable, ni autre chose. Mais si tu n'as pas plus de réponse, c'est que ta question est mal posé : trop vague, pas très clair, implicite.
je te répondrai : question précise, réponse présice.
je ne connais pas le format .dbf, mais il est toujours possible de le lire, et d'y ecrire. Le problème suivant c'est de savoir comment est codé le fichier ? Si il est codé, il existe souvent des bibliothèques C++ qui permettent de gérer ces fichiers facilement (sans tous reprogrammer les algo de compression decompression).
pour finir, je ne sais pas non plus ton niveau en C++. Ta question pourtai elle aussi sur les moyens d'ouvrir un fichier en C ??
ce n'es pas pour etre desagreable, ni autre chose. Mais si tu n'as pas plus de réponse, c'est que ta question est mal posé : trop vague, pas très clair, implicite.
michelatoutfox
Messages postés
828
Date d'inscription
mardi 5 octobre 2004
Statut
Membre
Dernière intervention
7 mai 2013
5
10 juin 2005 à 14:07
10 juin 2005 à 14:07
Bonjour 64Fred64,
le format dbf, ça n'est ni du excel, ni du access!
ce sont des fichiers de données de type "xbase", dont le format est légèrement différent selon qu'il s'agit de dbase, clipper, foxbase, foxpro, ou visualfoxpro.
voici quelques infos sur la structure de ces fichiers (en anglais, désolé)
ces infos sont extraites de l'aide de VisualFoxPro8, j'espère qu'elles te seront utiles.
je te conseille de regarder sur http://www.atoutfox.org (le site de la comunauté francophone des professionnels foxpro), et sur le forum microsoft foxpro (news://news.microsoft.com/microsoft.public.fr.fox ou http://www.microsoft.com/france/vfoxpro/newsgroup/default.asp)
Table Header Record Structure
Byte offset Description
0 File type:
0x02 FoxBASE
0x03 FoxBASE+/Dbase III plus, no memo
0x30 Visual FoxPro
0x31 Visual FoxPro, autoincrement enabled
0x43 dBASE IV SQL table files, no memo
0x63 dBASE IV SQL system files, no memo
0x83 FoxBASE+/dBASE III PLUS, with memo
0x8B dBASE IV with memo
0xCB dBASE IV SQL table files, with memo
0xF5 FoxPro 2.x (or earlier) with memo
0xFB FoxBASE
1 - 3 Last update (YYMMDD)
4 – 7 Number of records in file
8 – 9 Position of first data record
10 – 11 Length of one data record, including delete flag
12 – 27 Reserved
28 Table flags:
0x01 file has a structural .cdx
0x02 file has a Memo field
0x04 file is a database (.dbc)
This byte can contain the sum of any of the above values. For example, the value 0x03 indicates the table has a structural .cdx and a Memo field.
29 Code page mark
30 – 31 Reserved, contains 0x00
32 – n Field subrecords
The number of fields determines the number of field subrecords. One field subrecord exists for each field in the table.
n+1 Header record terminator (0x0D)
n+2 to n+264 A 263-byte range that contains the backlink, which is the relative path of an associated database (.dbc) file, information. If the first byte is 0x00, the file is not associated with a database. Therefore, database files always contain 0x00.
Field Subrecords Structure
Byte offset Description
0 – 10 Field name with a maximum of 10 characters. If less than 10, it is padded with null characters (0x00).
11 Field type:
C – Character
Y – Currency
N – Numeric
F – Float
D – Date
T – DateTime
B – Double
I – Integer
L – Logical
M – Memo
G – General
C – Character (binary)
M – Memo (binary)
P – Picture
12 – 15 Displacement of field in record
16 Length of field (in bytes)
17 Number of decimal places
18 Field flags:
0x01 System Column (not visible to user)
0x02 Column can store null values
0x04 Binary column (for CHAR and MEMO only)
0x06 (0x02+0x04) When a field is NULL and binary (Integer, Currency, and Character/Memo fields)
0x0C Column is autoincrementing
19 - 22 Value of autoincrement Next value
23 Value of autoincrement Step value
24 – 31 Reserved
A table file consists of a header record and data records. The header record defines the structure of the table and contains any other information related to the table. The header record starts at file position zero. Data records follow the header, in consecutive bytes, and contain the actual text of the fields.
Note The data in the data file starts at the position indicated in bytes 8 to 9 of the header record. Data records begin with a delete flag byte. If this byte is an ASCII space (0x20), the record is not deleted. If the first byte is an asterisk (0x2A), the record is deleted. The data from the fields named in the field subrecords follows the delete flag.
The length of a record, in bytes, is determined by summing the defined lengths of all fields. Integers in table files are stored with the least significant byte first.
le format dbf, ça n'est ni du excel, ni du access!
ce sont des fichiers de données de type "xbase", dont le format est légèrement différent selon qu'il s'agit de dbase, clipper, foxbase, foxpro, ou visualfoxpro.
voici quelques infos sur la structure de ces fichiers (en anglais, désolé)
ces infos sont extraites de l'aide de VisualFoxPro8, j'espère qu'elles te seront utiles.
je te conseille de regarder sur http://www.atoutfox.org (le site de la comunauté francophone des professionnels foxpro), et sur le forum microsoft foxpro (news://news.microsoft.com/microsoft.public.fr.fox ou http://www.microsoft.com/france/vfoxpro/newsgroup/default.asp)
Table Header Record Structure
Byte offset Description
0 File type:
0x02 FoxBASE
0x03 FoxBASE+/Dbase III plus, no memo
0x30 Visual FoxPro
0x31 Visual FoxPro, autoincrement enabled
0x43 dBASE IV SQL table files, no memo
0x63 dBASE IV SQL system files, no memo
0x83 FoxBASE+/dBASE III PLUS, with memo
0x8B dBASE IV with memo
0xCB dBASE IV SQL table files, with memo
0xF5 FoxPro 2.x (or earlier) with memo
0xFB FoxBASE
1 - 3 Last update (YYMMDD)
4 – 7 Number of records in file
8 – 9 Position of first data record
10 – 11 Length of one data record, including delete flag
12 – 27 Reserved
28 Table flags:
0x01 file has a structural .cdx
0x02 file has a Memo field
0x04 file is a database (.dbc)
This byte can contain the sum of any of the above values. For example, the value 0x03 indicates the table has a structural .cdx and a Memo field.
29 Code page mark
30 – 31 Reserved, contains 0x00
32 – n Field subrecords
The number of fields determines the number of field subrecords. One field subrecord exists for each field in the table.
n+1 Header record terminator (0x0D)
n+2 to n+264 A 263-byte range that contains the backlink, which is the relative path of an associated database (.dbc) file, information. If the first byte is 0x00, the file is not associated with a database. Therefore, database files always contain 0x00.
Field Subrecords Structure
Byte offset Description
0 – 10 Field name with a maximum of 10 characters. If less than 10, it is padded with null characters (0x00).
11 Field type:
C – Character
Y – Currency
N – Numeric
F – Float
D – Date
T – DateTime
B – Double
I – Integer
L – Logical
M – Memo
G – General
C – Character (binary)
M – Memo (binary)
P – Picture
12 – 15 Displacement of field in record
16 Length of field (in bytes)
17 Number of decimal places
18 Field flags:
0x01 System Column (not visible to user)
0x02 Column can store null values
0x04 Binary column (for CHAR and MEMO only)
0x06 (0x02+0x04) When a field is NULL and binary (Integer, Currency, and Character/Memo fields)
0x0C Column is autoincrementing
19 - 22 Value of autoincrement Next value
23 Value of autoincrement Step value
24 – 31 Reserved
A table file consists of a header record and data records. The header record defines the structure of the table and contains any other information related to the table. The header record starts at file position zero. Data records follow the header, in consecutive bytes, and contain the actual text of the fields.
Note The data in the data file starts at the position indicated in bytes 8 to 9 of the header record. Data records begin with a delete flag byte. If this byte is an ASCII space (0x20), the record is not deleted. If the first byte is an asterisk (0x2A), the record is deleted. The data from the fields named in the field subrecords follows the delete flag.
The length of a record, in bytes, is determined by summing the defined lengths of all fields. Integers in table files are stored with the least significant byte first.
Vous n’avez pas trouvé la réponse que vous recherchez ?
Posez votre question
Il y a beaucoup de réponses techniques à tes attentes sur la table dbf et la possibilité de l'attaquer avec du C / C++
La plus logique des réponses est d'affirmer que sous les Unix/Linux c'est du gâteau pour deux raisons :
- la table dbf exclue toute limitation de format
- les fichiers d'inclusion C/C++ sont liés à db.h
Sous windaube, c'est dramatique, les dbf sont limités en taillle (2go), en colonne (256 maxi) en nombre de caractère par nom de champs (20), etc . Les formats foxpro et visualfoxpro sont les plus chiants à coder.
Pour éviter les emmerdes de prog, il faut passer au format xml pour stocker les données des bases sur un poste local (puis les manip en local par l'utilisateur via l'appli qui lui est fournie), l'arbre codant les champs.
Bref, il faut oublier les dbf et ses différents format de données propriétaires, le format xml les dépasse sur tous les points.
windaube ou les Unix/Linux ont les fichiers nécessaires pour coder le xml.
Bon courage.
La plus logique des réponses est d'affirmer que sous les Unix/Linux c'est du gâteau pour deux raisons :
- la table dbf exclue toute limitation de format
- les fichiers d'inclusion C/C++ sont liés à db.h
Sous windaube, c'est dramatique, les dbf sont limités en taillle (2go), en colonne (256 maxi) en nombre de caractère par nom de champs (20), etc . Les formats foxpro et visualfoxpro sont les plus chiants à coder.
Pour éviter les emmerdes de prog, il faut passer au format xml pour stocker les données des bases sur un poste local (puis les manip en local par l'utilisateur via l'appli qui lui est fournie), l'arbre codant les champs.
Bref, il faut oublier les dbf et ses différents format de données propriétaires, le format xml les dépasse sur tous les points.
windaube ou les Unix/Linux ont les fichiers nécessaires pour coder le xml.
Bon courage.
michelatoutfox
Messages postés
828
Date d'inscription
mardi 5 octobre 2004
Statut
Membre
Dernière intervention
7 mai 2013
5
22 juil. 2005 à 11:03
22 juil. 2005 à 11:03
Trancheur,
ta réponse comporte quelques erreurs:
la longueur d'un nom de champ peut aller jusqu'à 128 caractères (si le dbf est du vfp, et qu'il est "rattaché" à un dbc)
le nombre de champs est de 255 (254 si au moins un champ peut stocker les valeurs NULL)
concernant la limitation à 2Go, celà ne provient pas de Windows: il s'agit d'une conséquence de la pose des verrous, qui va écrire au delà de la limite de la table, dans un maximum de 2 Go (pour simplifier). Je ne pense pas que ce soit contournable aujourdhui, mais si tu as des infos, je suis interessé!
et enfin, ta proposition concernant le xml est totalement irréaliste pour des fichiers un peu volumineux (par exemple quelques centaines de milliers d'enregistrements, avec une cinquantaine de champs, quelle sera la taille du xml???)
xml est très bien pour transférer, pas pour stocker. Et si on veut ne plus utiliser les dbf, on se tourne vers oracle, sql, mysql
ta réponse comporte quelques erreurs:
la longueur d'un nom de champ peut aller jusqu'à 128 caractères (si le dbf est du vfp, et qu'il est "rattaché" à un dbc)
le nombre de champs est de 255 (254 si au moins un champ peut stocker les valeurs NULL)
concernant la limitation à 2Go, celà ne provient pas de Windows: il s'agit d'une conséquence de la pose des verrous, qui va écrire au delà de la limite de la table, dans un maximum de 2 Go (pour simplifier). Je ne pense pas que ce soit contournable aujourdhui, mais si tu as des infos, je suis interessé!
et enfin, ta proposition concernant le xml est totalement irréaliste pour des fichiers un peu volumineux (par exemple quelques centaines de milliers d'enregistrements, avec une cinquantaine de champs, quelle sera la taille du xml???)
xml est très bien pour transférer, pas pour stocker. Et si on veut ne plus utiliser les dbf, on se tourne vers oracle, sql, mysql
