Base de donnée inaccessible

Bonjour à tous,

Je galère toujours avec cette BDD créée avec OOo sous Mandriva. J'y accède par un formulaire.
Sous Mandriva, aucun problème : je peux accéder à mon formulaire, naviguer et apporter des modifs...

Avec LibO, sous ArchLinux, pas moyen : la BDD est toujours là, mais le formulaire reste vide.
J'ai essayé de recréer la connexion avec la BDD, et depuis, c'est encore pire : je peux toujours l'ouvrir mais ensuite je ne peux plus rien faire, même pas le fermer. Je suis obligé de le killer.

Ensuite, à chaque fois que j'ouvre LibO, il faut d'abord qu'il récupère le fichier, que je suis ensuite obligé de killer...

De plus, avec OOo, quand j'avais un fichier qu'OOo s'obstine à vouloir restaurer, je faisais :
rm /home/joel/.ooo3/user/registry/data/org/openoffice/Office/Recovery.xcu

Mais là, pas moyen de trouver "Recovery.xcu"
J'ai cherché dans /home/joel/.config/.libreoffice/3/user/, mais il n'y a rien de tel...

Où se trouve-t-il ?

Que faire pour utiliser mon formulaire ?

Bonjour Joel,

Que faire pour utiliser mon formulaire ?

Quelle est la version du moteur HSQLDB indiquée dans le fichier
Manifest.xml de ton fichier ODB ?

Alex

Voici le contenu de ce fichier :
[joel@localhost darktable-0.7.1 15-02-2011 17:30] $ cat /documents/discours/META-INF/manifest.xml
<?xml version="1.0" encoding="UTF-8"?>
<manifest:manifest xmlns:manifest="urn:oasis:names:tc:opendocument:xmlns:manifest:1.0">
<manifest:file-entry manifest:media-type="application/vnd.sun.xml.base" manifest:full-path="/"/>
<manifest:file-entry manifest:media-type="" manifest:full-path="META-INF/"/>
<manifest:file-entry manifest:media-type="text/xml" manifest:full-path="content.xml"/>
<manifest:file-entry manifest:media-type="" manifest:full-path="database/script"/>
<manifest:file-entry manifest:media-type="" manifest:full-path="database/log"/>
<manifest:file-entry manifest:media-type="" manifest:full-path="database/properties"/>
<manifest:file-entry manifest:media-type="" manifest:full-path="database/"/>
<manifest:file-entry manifest:media-type="text/xml" manifest:full-path="settings.xml"/>
</manifest:manifest>

Bonjour Joel,

Bonjour Joel,

Bonjour, Alex,

Excuse-moi, c'est le fichier "properties", dans le répertoire
sous-répertoire "database", qu'il faut vérifier à l'intérieur du fichier
ODB.

Ah oui, ça correspond mieux...

hsqldb.cache_version=1.7.0
hsqldb.original_version=1.8.0
hsqldb.compatible_version=1.8.0

Bonsoir Joel,

Ah oui, ça correspond mieux...

hsqldb.cache_version=1.7.0
hsqldb.original_version=1.8.0
hsqldb.compatible_version=1.8.0

Bizarre, bizarre, ça devrait fonctionner avec cette version là. A moins
qu'il ne faille ajouter ".10" après "hsqldb.original_version=1.8.0" ?

Je regarde à nouveau ce j'ai dans les miens.

Alex

Bonsoir Joel,

Ah oui, ça correspond mieux...

hsqldb.cache_version=1.7.0
hsqldb.original_version=1.8.0
hsqldb.compatible_version=1.8.0

Gmail déconne, alors je renvoie :

- que vois tu dans les fichiers "data" et "backup" ?
- vois tu également un fichier "script" ?

Alex

- que vois tu dans les fichiers "data" et "backup" ?

Rien :
[joel@localhost ~ 16-02-2011 23:03] $ ls /documents/discours/database/
log properties script

- vois tu également un fichier "script" ?

En voici le contenu :
[joel@localhost ~ 16-02-2011 23:01] $ cat /documents/discours/database/script
SET DATABASE COLLATION "French"
CREATE SCHEMA PUBLIC AUTHORIZATION DBA
CREATE USER SA PASSWORD ""
GRANT DBA TO SA
SET WRITE_DELAY 60

Bonjour Joel,

Le 16/02/11 23:05, joel tarlao a écrit :Rien :

[joel@localhost ~ 16-02-2011 23:03] $ ls /documents/discours/database/
log properties script

C'est mauvais signe s'il n'y a pas de fichier DATA :-/
Dans le log, il y a quoi, peut-être le moyen de récupérer les données ?

- vois tu également un fichier "script" ?

En voici le contenu :
[joel@localhost ~ 16-02-2011 23:01] $ cat /documents/discours/database/script
SET DATABASE COLLATION "French"
CREATE SCHEMA PUBLIC AUTHORIZATION DBA
CREATE USER SA PASSWORD ""
GRANT DBA TO SA
SET WRITE_DELAY 60

Ça non plus, ce n'est pas bon signe parce qu'il n'indique aucune
instruction SQL sur la création de tables...je dirais a priori que c'est
mort, sauf s'il y a qq chose à récupérer dans le fichier LOG.

Alex

Bonjour Joel,

Bonsoir, Alex,

Le 16/02/11 23:05, joel tarlao a écrit :Rien :

> [joel@localhost ~ 16-02-2011 23:03] $ ls /documents/discours/database/
> log properties script
>
C'est mauvais signe s'il n'y a pas de fichier DATA :-/
Dans le log, il y a quoi, peut-être le moyen de récupérer les données ?

[joel@localhost ~ 17-02-2011 19:18] $ cat /documents/discours/database/log
/*C1*/SET WRITE_DELAY 0
SET AUTOCOMMIT FALSE
SET AUTOCOMMIT TRUE

>> - vois tu également un fichier "script" ?
> En voici le contenu :
> [joel@localhost ~ 16-02-2011 23:01] $ cat /documents/discours/database/script
> SET DATABASE COLLATION "French"
> CREATE SCHEMA PUBLIC AUTHORIZATION DBA
> CREATE USER SA PASSWORD ""
> GRANT DBA TO SA
> SET WRITE_DELAY 60

Ça non plus, ce n'est pas bon signe parce qu'il n'indique aucune
instruction SQL sur la création de tables...je dirais a priori que c'est
mort, sauf s'il y a qq chose à récupérer dans le fichier LOG.

Je n'ai pourtant aucun problème sous OOo.
C'est uniquement avec LibO que ça coince...

Ta base, elle est privée, ou on peut en faire un rapport de bug avec?

Alex

Bonjour Joel,

Bonsoir, Alex,

Le 16/02/11 23:05, joel tarlao a écrit :Rien :

> [joel@localhost ~ 16-02-2011 23:03] $ ...

[joel@localhost ~ 17-02-2011 19:18] $ cat /documents/discours/database/log
/*C1*/SET WRITE_DELAY 0
SET AUTOCOMMIT FALSE
SET AUTOCOMMIT TRUE

>> - vois tu également un fichier "script" ?
> En voici le contenu :
> [joel@localhost ~ ...

Je n'ai pourtant aucun problème sous OOo.
C'est uniquement avec LibO que ça coince...

Ah non, désolé, elle est privée...

Maintenant, je pourrai en faire une copie et remplacer les données par du texte quelconque...
Qu'en penses-tu ?

Bonne idée, si tu peux, comme ça je peux tester et éventuellement faire
remonter le bug.

Alex

Ta base, elle est privée, ou on peut en faire un rapport de bug avec?

Ah non, désolé, elle est privée...

Maintenant, je pourrai en faire une copie et remplacer les données par du
texte quelconque...
Qu'en penses-tu ?

Attends, je suis vraiment désolé, mais je viens de voir que j'avais dézippé un autre fichier qui portait le même nom, dans un autre dossier :frowning:
Certainement le résultat de mes premiers pas avec les BDD... Je viens de l'effacer...

Je reprends tout :

- cat /documents/b/discours/database/properties
#HSQL Database Engine 1.8.0.10
#Thu Feb 17 20:37:29 CET 2011
hsqldb.script_format=0
runtime.gc_interval=0
sql.enforce_strict_size=true
hsqldb.cache_size_scale=8
readonly=false
hsqldb.nio_data_file=false
hsqldb.cache_scale=13
version=1.8.0
hsqldb.default_table_type=cached
hsqldb.cache_file_scale=1
hsqldb.log_size=10
modified=no
hsqldb.cache_version=1.7.0
hsqldb.original_version=1.8.0
hsqldb.compatible_version=1.8.0
[joel@localhost ~ 17-02-2011 22:51] $

- Dans le fichier "data", j'ai effectivement les données de ma base

- cat /documents/b/discours/database/backup
x��y���}�YՔeY�!�r"+�����ͨ�����}(�b��&�"%ʎgbUWWwU]ժ�E*@�`� etc

- cat /documents/b/discours/database/script
SET DATABASE COLLATION "French"
CREATE SCHEMA PUBLIC AUTHORIZATION DBA
CREATE CACHED TABLE "liste_discours"("ID" INTEGER GENERATED BY DEFAULT AS IDENTITY(START WITH 0) NOT NULL PRIMARY KEY,"N_" DECIMAL(4),"TH_ME" VARCHAR(62),"D_J__FAIT" BOOLEAN,"JAMAIS_FAI" BOOLEAN,"N5" LONGVARCHAR,"N6" LONGVARCHAR,"N7" LONGVARCHAR,"N8" LONGVARCHAR,"N9" LONGVARCHAR,"N1_" LONGVARCHAR,"N11" LONGVARCHAR,"REFERENCES" LONGVARCHAR)
SET TABLE "liste_discours" INDEX'86200 46'
ALTER TABLE "liste_discours" ALTER COLUMN "ID" RESTART WITH 46
CREATE USER SA PASSWORD ""
GRANT DBA TO SA
SET WRITE_DELAY 60

Bonjour Joel,

Bonjour Joel,

Bonjour, Alex,

C'est déjà mieux :slight_smile: et me rassure, je commençais à être un peu perdu.

Je comprends ça. Je te trouve très aimable de ne pas m'avoir demandé si ma tête allait bien...

Si tu renommes ton fichier, cela rend les tables visibles à nouveau dans
LibO ? Je dis ça parce que je suis tombé sur ce comportement étrange il
y a quelques jours, où j'avais un fichier ODB de test d'un rapport de
bug qui ne voulait pas montrer les tables. Comme je voulais regarder à
l'intérieur, j'avais dans un premier temps renommé le fichier en
changeant juste l'extension en .zip à la place de .odb. Après, lorsque
j'ai remis l'extension d'origine, le fichier s'est ouvert normalement.
En réalité, je n'avais fait que changer le nom du fichier. Peux-tu
essayer et nous dire ce qu'il en est ?

C'est ce que j'ai fait hier soir pour extraire les infos demandées (j'étais sous Mandriva). Et j'avais effectivement pu le réouvrir avec OOo.

Aujourd'hui, je suis sous Arch.
Je viens de réouvrir LibO : il a, comme d'habitude, d'abord restauré la BDD et le formulaire que j'avais dû killer la dernière fois...
Et tout à l'heure, je vais à nouveau devoir le killer pour quitter LibO...

A ce sujet, comment faire pour que LibO ne veuille plus le restaurer au démarrage ?

J'ai fait une capture d'écran de ce formulaire : http://www.cijoint.fr/cjlink.php?file=cj201102/cij948ZUiW.png
Tu peux y voir que tous les outils de la barre d'outil "navigation pour formulaires" sont grisés. Je ne peux absolument rien faire...

Bonjour,

Ça n'a peut-être rien à voir, mais je constate sur cette capture d'écran, qu'il y a beaucoup de caractères spéciaux qui ont été remplacés.

Du coup, je me demande si ça n'aurait pas qque chose à voir ; est-ce que les noms de tables, de requêtes ou de champs ne comporteraient pas des caractères spéciaux (caractères accentués, espaces,...) dont on sait qu'ils affectent profondément la portabilité d'une base entre deux systèmes, même lorsque les deux systèmes opèrent le même logiciel ; alors, entre deux systèmes opérant des logiciels différents (bien que "frères"...), je me demande...

A+

Si tu renommes ton fichier, cela rend les tables visibles à nouveau dans
LibO ? Je dis ça parce que je suis tombé sur ce comportement étrange il
y a quelques jours, où j'avais un fichier ODB de test d'un rapport de
bug qui ne voulait pas montrer les tables. Comme je voulais regarder à
l'intérieur, j'avais dans un premier temps renommé le fichier en
changeant juste l'extension en .zip à la place de .odb. Après, lorsque
j'ai remis l'extension d'origine, le fichier s'est ouvert normalement.
En réalité, je n'avais fait que changer le nom du fichier. Peux-tu
essayer et nous dire ce qu'il en est ?

C'est ce que j'ai fait hier soir pour extraire les infos demandées (j'étais sous Mandriva). Et j'avais effectivement pu le réouvrir avec OOo.

Aujourd'hui, je suis sous Arch.
Je viens de réouvrir LibO : il a, comme d'habitude, d'abord restauré la BDD et le formulaire que j'avais dû killer la dernière fois...
Et tout à l'heure, je vais à nouveau devoir le killer pour quitter LibO...

A ce sujet, comment faire pour que LibO ne veuille plus le restaurer au démarrage ?

J'ai fait une capture d'écran de ce formulaire : http://www.cijoint.fr/cjlink.php?file=cj201102/cij948ZUiW.png
Tu peux y voir que tous les outils de la barre d'outil "navigation pour formulaires" sont grisés. Je ne peux absolument rien faire...

Je n'a pas tout suivi, en particulier, je ne sais pas si tu as mis ta base en ligne pour tester.
Je me demandais s'il y avait une clé primaire dans la table correspondant au formulaire qui s'affiche ?
J.M

Je n'a pas tout suivi, en particulier, je ne sais pas si tu as mis ta base en ligne pour tester.

Non, pas encore. Pour cela, il faudrait que j'en fasse une copie où je remplacerai le texte par du texte quelconque. Je le ferai si cela est nécessaire...

Je me demandais s'il y avait une clé primaire dans la table correspondant au formulaire qui s'affiche ?

Oui, c'est le premier champ 'ID"

Bonjour,

Bonjour, Docgranville,

Ça n'a peut-être rien à voir, mais je constate sur cette capture
d'écran, qu'il y a beaucoup de caractères spéciaux qui ont été remplacés.

Du coup, je me demande si ça n'aurait pas qque chose à voir ; est-ce que
les noms de tables, de requêtes ou de champs ne comporteraient pas des
caractères spéciaux (caractères accentués, espaces,...) dont on sait
qu'ils affectent profondément la portabilité d'une base entre deux
systèmes, même lorsque les deux systèmes opèrent le même logiciel ;
alors, entre deux systèmes opérant des logiciels différents (bien que
"frères"...), je me demande...

Oui, il y a 3 champs avec des caractères accentués.
Il faut que je retrouve comment changer les noms de champs (cela fait 6 ans que j'ai créé cette base...) et je ferai les modifs...

Là, je viens de parcourir les différents menus, et je ne trouve pas comment accéder à la structure de la base...