Si cette question est Hors Sujet, je ne sais où la poser.
J'ai besoin de certaines des fonctionalités proposées par des
gestionnaires de bases de données tels que 'Access'. Sous Linux, il y a
"OpenOffice Base", mais je n'arrive pas à en tirer parti pour mon
application. Sans doute me manque-t-il les infos dont j'ai besoin pour ce
faire, à moins - ce dont je doute fortement - que 'OO Base' n'arrive
vraiment pas à la cheville de 'MS Access'
Je dois gérer une base d'environ 120,000 lignes (enregistrements). Tant
que cette base n'excédait pas 65536 lignes, je la gérais sans problème
avec StarOffice Calc, l'équivalent d'EXCEL. Désormais ce n'est plus
possible, à moins de diviser le fichier en deux bases, avec les problèmes
que vous imaginez.
Une fois, dans les années 2002 ou environ, j'ai fait appel à 'MS Access'.
Si mes souvenirs sont bons, cet utilitaire permettait d'afficher une
grosse base sans problème, et j'avais pu faire ce que je voulais. C'était
avec le 'MS Access' de mon employeur, auquel je n'ai plus accès. Sans
doute mes moyens me permettraient ils encore d'acheter une version perso
d''Access', mais je souhaite rester sous Linux et utiliser les ressources
qui existent ici, même s'il n'est pas question pour autant de discréditer
le travail des concepteurs de logiciels tels que MS Access.
Mes premiers essais avec OpenOffice 2.4 DataBase sont très décourageants
à ce stade, et j'espère que quelqu'un ici va me diriger vers une doc
utile.
Sur mes bases d'environ 120,000 enregistrements, je n'ai pas besoin de
faire grand chose: simplement les éditer, éventuellement faire des tris
et des recherches.
Les premiers essais que j'ai faits ici m'ont donné les résultats
suivants :
Création de tables : çà prend plusieurs heures d'attente ! (alors que
mon PC - datant d'environ 3 ans - est infiniment plus performant que
celui dont je disposais lorsque je faisais usage de MS ACCESS pour une
base de la même taille)
Mes bases : 21 champs qui, en moyenne, font environ 50 char en TXT, pour
120,000 enregistrements. La moitié de cela, c'est à dire le même nombre
de champs avec seulement 60,000 enregistrements, s'ouvre sous OO Calc
(équivalent à Excel) en seulement quelques secondes.
Le Sun, 04 Oct 2009 04:51:54 +0200, Dominique a écrit :
Bernard a écrit :
Mes bases : 21 champs qui, en moyenne, font environ 50 char en TXT, pour 120,000 enregistrements. La moitié de cela, c'est à dire le même nombre de champs avec seulement 60,000 enregistrements, s'ouvre sous OO Calc (équivalent à Excel) en seulement quelques secondes.
Bonjour, Là, comme ça à vif, je dirais que OO Base n'est effectivement pas très performant en terme de vitesse.
Ah oui !!!
J'ai découvert hier que, sur ma vieille partition MSWIN XP, je disposais encore de MS ACCESS. J'y suis allé faire des tests et comparaisons avec ma demi-base de 65,000 enregistrements. Pour vous donner une idée de la taille de cette base, elle a 21 champs, tous en TXT. Voici la taille de chaque champ en octet (nombre de car): A 55 B 6 C 12 D 30 E 30 F 10 G 40 H 40 I 40 J 30 K 30 L 75 M 30 N 30 O 10 P 40 Q 40 R 40 S 30 T 30 U 75
Ceci fait, sauf erreur, un total de 548 octets par ligne (enregistrement) soit, pour 65,000 lignes : 3,562,000 octets rien que pour les données. Ce n'est tout de même pas énorme. Le fichier Calc, que je sauvegarde toujours en xls, fait 21,503,488 octets, et le fichier texte (csv) : 14,514,473 octets.
Sous OpenOffice Calc, ce fichier s'ouvre en quelques dixièmes de secondes. Les recherches sont au moins aussi rapides, les tri n'excèdent pas 5 secondes, même lorsqu'il s'agit de trier selon 3 champs.
Sous OpenOffice Base... Je reprends les notes que j'ai prises lors de mes récents essais :
Création d'une table par copié/collé des 65,000 enregistrements. Après redéfinition des champs et attribution du nombre de char comme précisé ci- dessus, option "sans clef primaire", j'ai noté l'heure : 15h15. A 15h20, le processus était toujours en cours. Je suis allé vaquer à une autre occupation et, à 16h15 c'était terminé, peut-être depuis un moment.
Ceci étant fait, l'ouverture de la table ne prenait qu'une dizaine de secondes, mais, par contre, parcourir les enregistrements du premier au dernier demandait l'"éternité plus un jour", selon le dicton australien. Ainsi, ayant cliqué sur l'icône ">>|" (dernière fiche) à 16h54, à 17h24 le processus étant toujours en cours, j'ai fait une sortie forcée (avant hier, le même test, toujours en cours après 3 heures, était terminé le lendemain matin à mon réveil !). J'ai alors rouvert ladite table, et essayé d'y naviguer plus progressivement, en affichant des valeurs en bas et à gauche. Il m'a fallu HUIT minutes pour avancer de la fiche 1 à la fiche 5000, soit parcourir seulement environ 8% de la longueur de ma base !
Sous MS ACCESS, les mêmes essais m'ont donné ceci : une fraction de seconde pour copier la même base, un quart de seconde pour passer de la première à la 65,000 ième fiche !
Ensuite, bien sur, je ne sais pas comment ajouter la seconde moitié de mon fichier (les 50,000 dernièrs enregistrements), mais je n'ai pas non plus trouvé comment le faire sous OObase, sauf à ne pas générer de clef primaire. De toutes façons c'est inutile de chercher, vu le temps que prennent les traitements.
Y-a-t-il un bug sur mon système - je devrais dire sur mes systèmes, puisque cela ne fonctionne pas mieux sur mon portable DELL Inspiron sous UBUNTU 8.04 (ici c'est Debian Lenny). Est-ce GNOME qui retarde le tout ? Durant les interminables attentes, j'ai testé "top", et, chaque fois, j'avais 99 - 100% de la CPU accaparée par OpenOffice, et entre 30 et 60% de la RAM occupée pareillement.
Si vraiment ce genre de comportement est classique, il se pourra dire que OpenOffice BASE n'est qu'une grosse plaisanterie, face à ACCESS. Si çà ne convient qu'à de toutes petites bases, alors je dirai que, dès l'instant où ces dites bases ont moins de 65536 lignes, on a plus avantage à utiliser OO Calc.
Autant je suis parfaitement satisfait de OO Writer et OO Calc, s'agissant de OO Base, au stade de mes connaissances et expérimentations, je suis terriblement déçu.
Merci d'avance pour vos commentaires et suggestions. J'espère que quelqu'un va me démontrer que quelque chose n'est pas normal chez moi, et qu'on peut obtenir beaucoup mieux de OO base.
Ah, au fait, j'ai refait les essais avec une base plus petite, comportant seulement 20,000 enregistrements, au lieu de 65,000 auparavant. Même nombre de champs (21), mêmes tailles. La création de la table par copié/ collé a pris 13 minutes. ensuite, dans cette table, une fois ouverte, cela m'a pris 8 minutes pour passer de la fiche 1 à la fiche 5000 !! J'ai bien dit HUIT MINUTES, pas 8 secondes, encore moins huit dixièmes de seconde !
En revanche, les fonctionnalités valent celle de MS Acces. Je n'ai pas de base de 120 000 lignes. Je me contente d'une base de 33 000 ! Parfois, je bascule le tout OO calc qui est bien plus rapide. A contrario, les tris un peu poussés se font mieux sous OO base. Pourquoi n'essayeriez-vous pas Mysql qui fonctionne très bien sous Linux ? Bonne journée,
MySQL ? Ce que j'en ai entendu, c'est qu'il n'était pas question de l'aborder en dilettante, mais qu'il fallait y investir un temps et une énergie considérable avant d'être opérationnel dans ce système. S'agissant des bases ci-haut décrites, pensez vous qu'en seulement quelques heures de travail je puisse les exploiter avantageusement via MySQL ?
Comment, par exemple, après la création d'un dit "serveur" MySQL, pourrai- je "importer" mes données (à partir de fichier CSV, ODS/SDC, XLS...) automatiquement (sans avoir à saisir ou copier/coller ligne par ligne) ?
Le Sun, 04 Oct 2009 04:51:54 +0200, Dominique a écrit :
Bernard a écrit :
Mes bases : 21 champs qui, en moyenne, font environ 50 char en TXT,
pour 120,000 enregistrements. La moitié de cela, c'est à dire le même
nombre de champs avec seulement 60,000 enregistrements, s'ouvre sous OO
Calc (équivalent à Excel) en seulement quelques secondes.
Bonjour,
Là, comme ça à vif, je dirais que OO Base n'est effectivement pas très
performant en terme de vitesse.
Ah oui !!!
J'ai découvert hier que, sur ma vieille partition MSWIN XP, je disposais
encore de MS ACCESS. J'y suis allé faire des tests et comparaisons avec
ma demi-base de 65,000 enregistrements. Pour vous donner une idée de la
taille de cette base, elle a 21 champs, tous en TXT. Voici la taille de
chaque champ en octet (nombre de car):
A 55
B 6
C 12
D 30
E 30
F 10
G 40
H 40
I 40
J 30
K 30
L 75
M 30
N 30
O 10
P 40
Q 40
R 40
S 30
T 30
U 75
Ceci fait, sauf erreur, un total de 548 octets par ligne (enregistrement)
soit, pour 65,000 lignes : 3,562,000 octets rien que pour les données. Ce
n'est tout de même pas énorme. Le fichier Calc, que je sauvegarde
toujours en xls, fait 21,503,488 octets, et le fichier texte (csv) :
14,514,473 octets.
Sous OpenOffice Calc, ce fichier s'ouvre en quelques dixièmes de
secondes. Les recherches sont au moins aussi rapides, les tri n'excèdent
pas 5 secondes, même lorsqu'il s'agit de trier selon 3 champs.
Sous OpenOffice Base... Je reprends les notes que j'ai prises lors de mes
récents essais :
Création d'une table par copié/collé des 65,000 enregistrements. Après
redéfinition des champs et attribution du nombre de char comme précisé ci-
dessus, option "sans clef primaire", j'ai noté l'heure : 15h15. A 15h20,
le processus était toujours en cours. Je suis allé vaquer à une autre
occupation et, à 16h15 c'était terminé, peut-être depuis un moment.
Ceci étant fait, l'ouverture de la table ne prenait qu'une dizaine de
secondes, mais, par contre, parcourir les enregistrements du premier au
dernier demandait l'"éternité plus un jour", selon le dicton australien.
Ainsi, ayant cliqué sur l'icône ">>|" (dernière fiche) à 16h54, à 17h24
le processus étant toujours en cours, j'ai fait une sortie forcée (avant
hier, le même test, toujours en cours après 3 heures, était terminé le
lendemain matin à mon réveil !). J'ai alors rouvert ladite table, et
essayé d'y naviguer plus progressivement, en affichant des valeurs en bas
et à gauche. Il m'a fallu HUIT minutes pour avancer de la fiche 1 à la
fiche 5000, soit parcourir seulement environ 8% de la longueur de ma
base !
Sous MS ACCESS, les mêmes essais m'ont donné ceci : une fraction de
seconde pour copier la même base, un quart de seconde pour passer de la
première à la 65,000 ième fiche !
Ensuite, bien sur, je ne sais pas comment ajouter la seconde moitié de
mon fichier (les 50,000 dernièrs enregistrements), mais je n'ai pas non
plus trouvé comment le faire sous OObase, sauf à ne pas générer de clef
primaire. De toutes façons c'est inutile de chercher, vu le temps que
prennent les traitements.
Y-a-t-il un bug sur mon système - je devrais dire sur mes systèmes,
puisque cela ne fonctionne pas mieux sur mon portable DELL Inspiron sous
UBUNTU 8.04 (ici c'est Debian Lenny). Est-ce GNOME qui retarde le
tout ? Durant les interminables attentes, j'ai testé "top", et, chaque
fois, j'avais 99 - 100% de la CPU accaparée par OpenOffice, et entre 30
et 60% de la RAM occupée pareillement.
Si vraiment ce genre de comportement est classique, il se pourra dire que
OpenOffice BASE n'est qu'une grosse plaisanterie, face à ACCESS. Si çà ne
convient qu'à de toutes petites bases, alors je dirai que, dès l'instant
où ces dites bases ont moins de 65536 lignes, on a plus avantage à
utiliser OO Calc.
Autant je suis parfaitement satisfait de OO Writer et OO Calc, s'agissant
de OO Base, au stade de mes connaissances et expérimentations, je suis
terriblement déçu.
Merci d'avance pour vos commentaires et suggestions. J'espère que
quelqu'un va me démontrer que quelque chose n'est pas normal chez moi, et
qu'on peut obtenir beaucoup mieux de OO base.
Ah, au fait, j'ai refait les essais avec une base plus petite, comportant
seulement 20,000 enregistrements, au lieu de 65,000 auparavant. Même
nombre de champs (21), mêmes tailles. La création de la table par copié/
collé a pris 13 minutes. ensuite, dans cette table, une fois ouverte,
cela m'a pris 8 minutes pour passer de la fiche 1 à la fiche 5000 !!
J'ai bien dit HUIT MINUTES, pas 8 secondes, encore moins huit dixièmes de
seconde !
En revanche, les fonctionnalités valent
celle de MS Acces.
Je n'ai pas de base de 120 000 lignes. Je me contente d'une base de 33
000 ! Parfois, je bascule le tout OO calc qui est bien plus rapide. A
contrario, les tris un peu poussés se font mieux sous OO base. Pourquoi
n'essayeriez-vous pas Mysql qui fonctionne très bien sous Linux ? Bonne
journée,
MySQL ? Ce que j'en ai entendu, c'est qu'il n'était pas question de
l'aborder en dilettante, mais qu'il fallait y investir un temps et une
énergie considérable avant d'être opérationnel dans ce système.
S'agissant des bases ci-haut décrites, pensez vous qu'en seulement
quelques heures de travail je puisse les exploiter avantageusement via
MySQL ?
Comment, par exemple, après la création d'un dit "serveur" MySQL, pourrai-
je "importer" mes données (à partir de fichier CSV, ODS/SDC, XLS...)
automatiquement (sans avoir à saisir ou copier/coller ligne par ligne) ?
Le Sun, 04 Oct 2009 04:51:54 +0200, Dominique a écrit :
Bernard a écrit :
Mes bases : 21 champs qui, en moyenne, font environ 50 char en TXT, pour 120,000 enregistrements. La moitié de cela, c'est à dire le même nombre de champs avec seulement 60,000 enregistrements, s'ouvre sous OO Calc (équivalent à Excel) en seulement quelques secondes.
Bonjour, Là, comme ça à vif, je dirais que OO Base n'est effectivement pas très performant en terme de vitesse.
Ah oui !!!
J'ai découvert hier que, sur ma vieille partition MSWIN XP, je disposais encore de MS ACCESS. J'y suis allé faire des tests et comparaisons avec ma demi-base de 65,000 enregistrements. Pour vous donner une idée de la taille de cette base, elle a 21 champs, tous en TXT. Voici la taille de chaque champ en octet (nombre de car): A 55 B 6 C 12 D 30 E 30 F 10 G 40 H 40 I 40 J 30 K 30 L 75 M 30 N 30 O 10 P 40 Q 40 R 40 S 30 T 30 U 75
Ceci fait, sauf erreur, un total de 548 octets par ligne (enregistrement) soit, pour 65,000 lignes : 3,562,000 octets rien que pour les données. Ce n'est tout de même pas énorme. Le fichier Calc, que je sauvegarde toujours en xls, fait 21,503,488 octets, et le fichier texte (csv) : 14,514,473 octets.
Sous OpenOffice Calc, ce fichier s'ouvre en quelques dixièmes de secondes. Les recherches sont au moins aussi rapides, les tri n'excèdent pas 5 secondes, même lorsqu'il s'agit de trier selon 3 champs.
Sous OpenOffice Base... Je reprends les notes que j'ai prises lors de mes récents essais :
Création d'une table par copié/collé des 65,000 enregistrements. Après redéfinition des champs et attribution du nombre de char comme précisé ci- dessus, option "sans clef primaire", j'ai noté l'heure : 15h15. A 15h20, le processus était toujours en cours. Je suis allé vaquer à une autre occupation et, à 16h15 c'était terminé, peut-être depuis un moment.
Ceci étant fait, l'ouverture de la table ne prenait qu'une dizaine de secondes, mais, par contre, parcourir les enregistrements du premier au dernier demandait l'"éternité plus un jour", selon le dicton australien. Ainsi, ayant cliqué sur l'icône ">>|" (dernière fiche) à 16h54, à 17h24 le processus étant toujours en cours, j'ai fait une sortie forcée (avant hier, le même test, toujours en cours après 3 heures, était terminé le lendemain matin à mon réveil !). J'ai alors rouvert ladite table, et essayé d'y naviguer plus progressivement, en affichant des valeurs en bas et à gauche. Il m'a fallu HUIT minutes pour avancer de la fiche 1 à la fiche 5000, soit parcourir seulement environ 8% de la longueur de ma base !
Sous MS ACCESS, les mêmes essais m'ont donné ceci : une fraction de seconde pour copier la même base, un quart de seconde pour passer de la première à la 65,000 ième fiche !
Ensuite, bien sur, je ne sais pas comment ajouter la seconde moitié de mon fichier (les 50,000 dernièrs enregistrements), mais je n'ai pas non plus trouvé comment le faire sous OObase, sauf à ne pas générer de clef primaire. De toutes façons c'est inutile de chercher, vu le temps que prennent les traitements.
Y-a-t-il un bug sur mon système - je devrais dire sur mes systèmes, puisque cela ne fonctionne pas mieux sur mon portable DELL Inspiron sous UBUNTU 8.04 (ici c'est Debian Lenny). Est-ce GNOME qui retarde le tout ? Durant les interminables attentes, j'ai testé "top", et, chaque fois, j'avais 99 - 100% de la CPU accaparée par OpenOffice, et entre 30 et 60% de la RAM occupée pareillement.
Si vraiment ce genre de comportement est classique, il se pourra dire que OpenOffice BASE n'est qu'une grosse plaisanterie, face à ACCESS. Si çà ne convient qu'à de toutes petites bases, alors je dirai que, dès l'instant où ces dites bases ont moins de 65536 lignes, on a plus avantage à utiliser OO Calc.
Autant je suis parfaitement satisfait de OO Writer et OO Calc, s'agissant de OO Base, au stade de mes connaissances et expérimentations, je suis terriblement déçu.
Merci d'avance pour vos commentaires et suggestions. J'espère que quelqu'un va me démontrer que quelque chose n'est pas normal chez moi, et qu'on peut obtenir beaucoup mieux de OO base.
Ah, au fait, j'ai refait les essais avec une base plus petite, comportant seulement 20,000 enregistrements, au lieu de 65,000 auparavant. Même nombre de champs (21), mêmes tailles. La création de la table par copié/ collé a pris 13 minutes. ensuite, dans cette table, une fois ouverte, cela m'a pris 8 minutes pour passer de la fiche 1 à la fiche 5000 !! J'ai bien dit HUIT MINUTES, pas 8 secondes, encore moins huit dixièmes de seconde !
En revanche, les fonctionnalités valent celle de MS Acces. Je n'ai pas de base de 120 000 lignes. Je me contente d'une base de 33 000 ! Parfois, je bascule le tout OO calc qui est bien plus rapide. A contrario, les tris un peu poussés se font mieux sous OO base. Pourquoi n'essayeriez-vous pas Mysql qui fonctionne très bien sous Linux ? Bonne journée,
MySQL ? Ce que j'en ai entendu, c'est qu'il n'était pas question de l'aborder en dilettante, mais qu'il fallait y investir un temps et une énergie considérable avant d'être opérationnel dans ce système. S'agissant des bases ci-haut décrites, pensez vous qu'en seulement quelques heures de travail je puisse les exploiter avantageusement via MySQL ?
Comment, par exemple, après la création d'un dit "serveur" MySQL, pourrai- je "importer" mes données (à partir de fichier CSV, ODS/SDC, XLS...) automatiquement (sans avoir à saisir ou copier/coller ligne par ligne) ?
Cornelia Schneider
Bernard wrote in news:4ac917c4$0$984$ba4acef3 @news.orange.fr:
Y-a-t-il un bug sur mon système
Ma première idée serait que ta base sous MS est indexée et celle sous OO uniquement à lecture séquentielle.
Cornelia
-- Be out and be proud - today is the first day of the rest of your life Support Transgenre Strasbourg : www.sts67.org Creative stuff : www.bownbend.com GPG key ID 83FF7452
Bernard <bdebreil@teaser.fr> wrote in news:4ac917c4$0$984$ba4acef3
@news.orange.fr:
Y-a-t-il un bug sur mon système
Ma première idée serait que ta base sous MS est indexée et celle sous OO
uniquement à lecture séquentielle.
Cornelia
--
Be out and be proud - today is the first day of the rest of your life
Support Transgenre Strasbourg : www.sts67.org
Creative stuff : www.bownbend.com
GPG key ID 83FF7452
Bernard wrote in news:4ac917c4$0$984$ba4acef3 @news.orange.fr:
Y-a-t-il un bug sur mon système
Ma première idée serait que ta base sous MS est indexée et celle sous OO uniquement à lecture séquentielle.
Cornelia
-- Be out and be proud - today is the first day of the rest of your life Support Transgenre Strasbourg : www.sts67.org Creative stuff : www.bownbend.com GPG key ID 83FF7452
Fabien LE LEZ
On 5 Oct 2009 00:48:53 +0100, Cornelia Schneider :
Ma première idée serait que ta base sous MS est indexée et celle sous OO uniquement à lecture séquentielle.
Ouémébon... La lecture séquentielle de quelques Mo, ça ne devrait pas dépasser une ou deux secondes, tout de même.
On 5 Oct 2009 00:48:53 +0100, Cornelia Schneider
<cschneider@pccsxb.com>:
Ma première idée serait que ta base sous MS est indexée et celle sous OO
uniquement à lecture séquentielle.
Ouémébon... La lecture séquentielle de quelques Mo, ça ne devrait pas
dépasser une ou deux secondes, tout de même.
Tu as regardé kexi ? Il utilise tout seule sqllite (mais peut aussi utiliser mysql et postgresql) qui est très très rapide.
très bien sqlite. Mais il n'y a pas de type de champ date (du moins je n'ai pas trouvé).
Thierry B
On 2009-10-05, Fabien LE LEZ wrote:
que cette base n'excédait pas 65536 lignes, je la gérais sans problème avec StarOffice Calc,
Au fait, pourquoi a-t-on toujours cette limite de 65536 lignes ? Est-ce parce que Windows 3.1 fonctionne en 16 bits, ou y a-t-il une autre raison ?
Si je me souviens bien, c'est plutôt une limitation sur le format de fichier de sauvegarde des feuilles. Et comme il faut rester compatible avec l'acteur majeur du secteur...
--
Optimists think the glass is half full. Pesimists think the glass is half empty. Engineers think the glass is twice too big.
Some people say, "Hey, this isn't my glass! My glass was FULL"
On 2009-10-05, Fabien LE LEZ <gramster@gramster.com> wrote:
que cette base n'excédait pas 65536 lignes, je la gérais sans problème
avec StarOffice Calc,
Au fait, pourquoi a-t-on toujours cette limite de 65536 lignes ?
Est-ce parce que Windows 3.1 fonctionne en 16 bits, ou y a-t-il une
autre raison ?
Si je me souviens bien, c'est plutôt une limitation sur le format
de fichier de sauvegarde des feuilles. Et comme il faut rester
compatible avec l'acteur majeur du secteur...
--
Optimists think the glass is half full.
Pesimists think the glass is half empty.
Engineers think the glass is twice too big.
Some people say, "Hey, this isn't my glass! My glass was FULL"
que cette base n'excédait pas 65536 lignes, je la gérais sans problème avec StarOffice Calc,
Au fait, pourquoi a-t-on toujours cette limite de 65536 lignes ? Est-ce parce que Windows 3.1 fonctionne en 16 bits, ou y a-t-il une autre raison ?
Si je me souviens bien, c'est plutôt une limitation sur le format de fichier de sauvegarde des feuilles. Et comme il faut rester compatible avec l'acteur majeur du secteur...
--
Optimists think the glass is half full. Pesimists think the glass is half empty. Engineers think the glass is twice too big.
Some people say, "Hey, this isn't my glass! My glass was FULL"
Fabien LE LEZ
On 05 Oct 2009 14:08:01 GMT, Thierry B :
Si je me souviens bien, c'est plutôt une limitation sur le format de fichier de sauvegarde des feuilles. Et comme il faut rester compatible avec l'acteur majeur du secteur...
Si on veut enregistrer au format XLS, je veux bien. Mais à ma connaissance, ce n'est pas le format d'enregistrement par défaut d'Open Office, ni de Microsoft Office.
On 05 Oct 2009 14:08:01 GMT, Thierry B <tth@nowhere.invalid>:
Si je me souviens bien, c'est plutôt une limitation sur le format
de fichier de sauvegarde des feuilles. Et comme il faut rester
compatible avec l'acteur majeur du secteur...
Si on veut enregistrer au format XLS, je veux bien. Mais à ma
connaissance, ce n'est pas le format d'enregistrement par défaut
d'Open Office, ni de Microsoft Office.
Si je me souviens bien, c'est plutôt une limitation sur le format de fichier de sauvegarde des feuilles. Et comme il faut rester compatible avec l'acteur majeur du secteur...
Si on veut enregistrer au format XLS, je veux bien. Mais à ma connaissance, ce n'est pas le format d'enregistrement par défaut d'Open Office, ni de Microsoft Office.
Fabien LE LEZ
On 05 Oct 2009 12:10:00 GMT, moi-meme :
Mais il n'y a pas de type de champ date
Yep, SQlite est très économe en matière de types.
Disons que dans MySQL, un champ "date" est implicitement un nombre qui est transformé en texte (Y-M-d par exemple) à la lecture. Dans SQlite, un champ "date" est explicitement un nombre, qu'on peut afficher sous forme de date par les fonctions décrites ici : http://www.sqlite.org/lang_datefunc.html
On 05 Oct 2009 12:10:00 GMT, moi-meme <chiebel@free.fr>:
Mais il n'y a pas de type de champ date
Yep, SQlite est très économe en matière de types.
Disons que dans MySQL, un champ "date" est implicitement un nombre qui
est transformé en texte (Y-M-d par exemple) à la lecture.
Dans SQlite, un champ "date" est explicitement un nombre, qu'on peut
afficher sous forme de date par les fonctions décrites ici :
http://www.sqlite.org/lang_datefunc.html
Disons que dans MySQL, un champ "date" est implicitement un nombre qui est transformé en texte (Y-M-d par exemple) à la lecture. Dans SQlite, un champ "date" est explicitement un nombre, qu'on peut afficher sous forme de date par les fonctions décrites ici : http://www.sqlite.org/lang_datefunc.html
Sergio
Thierry B a écrit :
Au fait, pourquoi a-t-on toujours cette limite de 65536 lignes ? Est-ce parce que Windows 3.1 fonctionne en 16 bits, ou y a-t-il une autre raison ?
Si je me souviens bien, c'est plutôt une limitation sur le format de fichier de sauvegarde des feuilles. Et comme il faut rester compatible avec l'acteur majeur du secteur...
Euh... L'acteur majeur du secteur c'est qui ?
Parce que pour un des challengers, j'ai nommé MS Excel, il accepte 1 048 576 lignes sur 16 384 colonnes depuis sa version 2007.
-- Serge http://leserged.online.fr/ Mon blog: http://cahierdesergio.free.fr/ Soutenez le libre: http://www.framasoft.org
Thierry B a écrit :
Au fait, pourquoi a-t-on toujours cette limite de 65536 lignes ?
Est-ce parce que Windows 3.1 fonctionne en 16 bits, ou y a-t-il une
autre raison ?
Si je me souviens bien, c'est plutôt une limitation sur le format
de fichier de sauvegarde des feuilles. Et comme il faut rester
compatible avec l'acteur majeur du secteur...
Euh... L'acteur majeur du secteur c'est qui ?
Parce que pour un des challengers, j'ai nommé MS Excel, il accepte 1 048 576 lignes sur 16 384 colonnes depuis sa version 2007.
--
Serge http://leserged.online.fr/
Mon blog: http://cahierdesergio.free.fr/
Soutenez le libre: http://www.framasoft.org
Au fait, pourquoi a-t-on toujours cette limite de 65536 lignes ? Est-ce parce que Windows 3.1 fonctionne en 16 bits, ou y a-t-il une autre raison ?
Si je me souviens bien, c'est plutôt une limitation sur le format de fichier de sauvegarde des feuilles. Et comme il faut rester compatible avec l'acteur majeur du secteur...
Euh... L'acteur majeur du secteur c'est qui ?
Parce que pour un des challengers, j'ai nommé MS Excel, il accepte 1 048 576 lignes sur 16 384 colonnes depuis sa version 2007.
-- Serge http://leserged.online.fr/ Mon blog: http://cahierdesergio.free.fr/ Soutenez le libre: http://www.framasoft.org
Emmanuel Florac
Le Sun, 04 Oct 2009 21:46:44 +0000, Bernard a écrit:
MySQL ? Ce que j'en ai entendu, c'est qu'il n'était pas question de l'aborder en dilettante, mais qu'il fallait y investir un temps et une énergie considérable avant d'être opérationnel dans ce système.
Non, tu n'as pas besoin de te casser la tête. Installe mysql, puis quand tu crées ton document OO Base, choisis de te connecter à mysql.
Tout ce que tu as à faire dans mysql c'est de créer une base vide et un utilisateur pour t'y connecter.
-- There are only two kinds of languages: the ones people complain about and the ones nobody uses. Bjarne Stroustrup
Le Sun, 04 Oct 2009 21:46:44 +0000, Bernard a écrit:
MySQL ? Ce que j'en ai entendu, c'est qu'il n'était pas question de
l'aborder en dilettante, mais qu'il fallait y investir un temps et une
énergie considérable avant d'être opérationnel dans ce système.
Non, tu n'as pas besoin de te casser la tête. Installe mysql, puis quand
tu crées ton document OO Base, choisis de te connecter à mysql.
Tout ce que tu as à faire dans mysql c'est de créer une base vide et un
utilisateur pour t'y connecter.
--
There are only two kinds of languages: the ones people complain about and
the ones nobody uses.
Bjarne Stroustrup
Le Sun, 04 Oct 2009 21:46:44 +0000, Bernard a écrit:
MySQL ? Ce que j'en ai entendu, c'est qu'il n'était pas question de l'aborder en dilettante, mais qu'il fallait y investir un temps et une énergie considérable avant d'être opérationnel dans ce système.
Non, tu n'as pas besoin de te casser la tête. Installe mysql, puis quand tu crées ton document OO Base, choisis de te connecter à mysql.
Tout ce que tu as à faire dans mysql c'est de créer une base vide et un utilisateur pour t'y connecter.
-- There are only two kinds of languages: the ones people complain about and the ones nobody uses. Bjarne Stroustrup
