Discussion :

[stanley1415]

Bonjour,

Je suis amené en ce moment à gérer une bdd informix (7.25.UC6) et je suis loin d'être expert

Je voulais commencer par un petit dbexport mais la impossible j'ai une erreur, je test un dbschema complet mais même chose 201: A syntax error has occurred.
Du coup j'y vais table par table et je vois une table inutilisé qui se nomme " test"

Je tente un

drop table test

puis un

drop table " test"

mais aucune des solutions ne fonctionnent

J'ai fait pas mal de recherche sur le net mais je ne trouve rien donc me voila..

help?
Je confirme que je souhaite juste la supprimer (format et données) , elle n'est pas utilisé du tout aujourd'hui

Merci d'avance pour votre aide

Stan

[Invité]

A tout hasard, tu n’exécuterais pas ton « drop table » depuis le shell à l’instar des commandes dbshema et dbexport alors que c’est une commande sql ?

Syntaxe : drop table test;

Sinon, pour les commandes dbshema et dbexpport, je m’étais écrit deux petits mémos sous forme de requêtes sql pratiques à lire sous isql :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
 
{------------------------------------------------------------------------------}
{
Dbschema.sql
 
1. -> Shell à exécuter :
 
cd /mabase/mabase
dbschema -d /mabase/mabase mabase.sql
 
2. -> Les tables systables.tabtype = "T" sont traitées dans l'ordre suivant : 
 
- systables.tabid,
- systables.tabname
 
Lorsque dbschema s'interrompt en signalant une erreur comme :
 
"Item en double pour un index unique"
 
Il y a lieu de :
 
1. Lister les tables dans l'ordre où elles sont traitées
   pour repérer la table à traiter qui pose problème c'est-à-dire,
   celle qui suit la dernière table du fichier SQL créée par dbschema
 
   unload to systables.out
   select    systables.tabid,
             systables.tabname
   from      systables
   where     systables.tabtype = "T"
   order by  systables.tabid;
 
2. - Faire un unload de la table incriminée
   - Droper la table
   - Créer la  table à partir du sql "create_bdd.sql
   - Créer ses index à partir du sql "create_idx.sql
   - Loader depuis le fichier unload précédemment créé
}
{------------------------------------------------------------------------------}
{
cd /mabase/mabase
 
dbschema -d /mabase/mabase mabase.sql
}
{------------------------------------------------------------------------------}

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
 
{------------------------------------------------------------------------------}
{
dbexport.sql
 
-> Shell à exécuter 
 
Il y a lieu de :
 
1. Etre seul utilisateur
 
2. Paramétrer éventuellement DBDATE=DMY4/
 
3. Se positionner sur le répertoire où doit être créé le fichier d'exportation
   ../tmp
 
4. Supprimer le fichier mabase.out s'il existe
 
5. Supprimer le répertoire ../tmp/dbexport.exp s'il existe
 
6. Taper la commande : dbexport mabase
 
   -> Le fichier mabase.out sera créé
      Les deux dernières lignes de ce fichier sont les suivantes :
      - dbexport completed
      - une ligne vierge
 
   -> Le répertoire ../tmp/dbexport.exp sera créé
      Ce répertoire contiendra :
      - toutes les tables "unloadées" et suffixées ".unl"
      - le fichier "mabase.sql"
        identique au fichier ../tmp/mabase.out sans ses deux dernières lignes
}
{------------------------------------------------------------------------------}
{
DBDATE=DMY4/
export DBDATE
 
cd /mabase/mqbase/tmp
 
dbexport mabase
}
{------------------------------------------------------------------------------}

… Mais tout cela, c’était il y a bien longtemps. Je passais dans le coin par erreur. Mon discours est probablement obsolète. En tout cas, ça fait du bien de revoir Informix. Je retourne à mes activités de retraité, bonne continuation…

[stanley1415]

Bonjour,

Merci pour la réponse, les éléments que tu fournis ne sont pas obsolète, pas sur ma version en tout cas amis ne m'aide en rien sur ce problème.

Pour ce qui est du drop, je confirme que je passe bien par dbaccess pour lancer la commande. C'est surement le nom de la table (avec un espace ou caractère non identifié) qui génère l'erreur à l’exécution et je ne sais pas comment le contourner.
Il faudrait une commande pour supprimer une table via son tabid ou alors modifier en direct les tables systèmes pour supprimer la table concernés mais je ne sais pas exactement ce qu'il faut faire et je ne veut surtout pas foiré la base donc...

[Invité]

Ne connaissant pas DBACCESS, j’ai cherché sur internet et j’ai trouvé des informations qui pourraient bien t’intéresser, notamment ce site concernant DBACCESS et ses options:

IBM Knowledge Center

Démarrer DB-Access avec l’option –q devrait certainement résoudre ton problème :

-q (Démarre au niveau du menu Query-language (menu SQL) en tant que menu de niveau supérieur)

Mais il y a d'autres solutions... c'est du copier-coller du site en question :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
Exemple : exécution d'un fichier de commandes

Cet exemple explique comment démarrer DB-Access et exécuter un fichier de commandes contenant des instructions SQL.
L'exemple de commande suivant exécute les instructions SQL dans un fichier nommé sel_stock.sql sur la base de données mystores : 

dbaccess mystores sel_stock

Je te laisse aller plus loin avec DB-Access... Je me fais du mal !

[stanley1415]

les options dbaccess ne changent absolument rien au problème, l'erreur est toujours présente et cette foutu table aussi.
le fait de lancer le sql via un .sql provoque la même erreur.. je déprime mais te remercie malgré tout pour tes recherches

[Zirak]

Bonjour,

La société où je travaille utilise un ERP fonctionnant sous Informix, mais sans que nous ayons un accès direct à l'administration de la BDD.

Pour outrepasser cela, vu que j'ai souvent beaucoup de données à traiter provenant des tableaux Excel d'utilisateurs, je me connecte via macro directement sur la BDD Informix via une connexion ODBC, et je lance mes requêtes via VBA directement, jamais eu de problème sur une commande DROP TABLE.

Peut-être une piste à creuser pour te dépanner si tu t'y connais un peu en VBA...

[Invité]

Une autre piste peut-être que tu as dû explorer : en démarrant DBACCESS avec l’option -t

-t (Démarre au niveau du menu Table en tant que menu de niveau supérieur)

Le menu Table doit bien proposer le DROP, non ?

Il existe aussi la commande sql « check table matable; » mais j’ai oublié ce qu’elle faisait.

Peux-tu au moins agir d’une quelconque façon sur cette table, droper le ou les index, supprimer les items ou les unloader ?

Un administrateur de BDD ne pouvant pas accéder directement à l’administration de sa BDD me laisse perplexe.

[stanley1415]

Bonjour,

le check table vérifie la cohérence entre les données et les index, j'ai tenté mais rien, même erreur que les autres commandes
sinon je confirme que je n'arrive à RIEN avec cette table, j'ai tout les droits, toutes les autorisations etc.. mais je ne peux rien faire, pas même un select
la seule fonction accessible, c'est la fonction "info" du menu dbaccess qui me permet de visualiser les champs de la table (le nom des champs et leurs types, index, droits etc.. mais pas les données)

toutes les autres tables de la base c'est ok. le seul problème à mon avis c'est le nom de la table qui contient un espace.. je ne sais pas comment mon prédécesseur a réussit à faire ça, normalement ce n'est pas possible...


je ne connais pas grand chose en vba mais je vais essayer cette technique, je vous tiens informé dans la journée

[Invité]

A force de réfléchir à ton problème, des bribes de souvenirs finissent par remonter à la surface…

C’était au siècle dernier, IBM n’avait pas encore repris Informix.

Entre-autres aventures, j’ai connu ce genre de souci. De ce qu’il me reste de mémoire, je ne m’en suis sorti qu’en recréant une nouvelle BDD à partir des tables saines et une reconstitution de la table altérée depuis une sauvegarde que j'ai dû actualiser.

[stanley1415]

Oui, j'ai passé pas mal de temps dessus hier encore et je crois avoir fait le tour des solutions possible sans résultat malheureusement.
Reconstruire la base va me gonfler... je n'ai pas de sauvegarde saine à priori et il y a beaucoup de tables et pas mal de données et je dois forcément le faire sans dbexport =) mais bon si il faut je le ferai

Avant cette ultime solutions je vais essayer de trouver un moyen de supprimer la table manuellement, ça doit pouvoir se faire en supprimer des éléments dans les tables systèmes et les fichiers idx, dat etc en direct... je vais essayer de trouver des infos sur ce genre d'opérations lundi (réunionnite aiguë aujourd'hui)

Merci pour cette info en tout cas, le fait que tu ai eu le problème va m'éviter de chercher, si tu n'as as trouver de solutions à l'époque, y a pas de raisons que j'en trouve une par miracle

[Invité]

Développant en électron libre, je m’étais constitué une sorte d’AGL simple mais suffisant, d’où les mémos que je t’ai proposés. Je ne pouvais compter que sur moi-même. On ne communiquait pas comme on le fait aujourd’hui. J’ai commencé à développer Unix-Informix en 1991.

Personnellement, je ne m’aventurerais pas trop à bidouiller les tables systèmes, il y aura toujours un doute sur la fiabilité de la Base. Pourtant, je les ai bien martyrisées, mes Bases. Je n’hésitais pas à intervenir dessus pendant que les gestionnaires travaillaient. Quand elles étaient bloquées, elles se doutaient que j’étais en train de bricoler, elles attendaient un peu et reprenaient leur travail. Si l’interruption durait un peu trop longtemps, elles venaient aux nouvelles.

Indépendamment des dbschema et dbexport , je gérais des sql qui me permettaient de recréer facilement mes BDD.

create_bdd.sql
create_idx.sql
unload_bdd.sql
load_bdd.sql

Ton prédécesseur doit bien avoir laissé quelque chose.

Je développais en ISQL, d’abord sur Unix SCO puis sur AIX, en mode caractères bien sûr. Si ça t’intéresse, je peux te proposer deux-trois programmes (écrans/ace) qui exploitent les tables système. Quand on développe, on néglige ses propres besoins. Les cordonniers sont toujours les plus mal chaussés.

J’avais fait une proposition il y a quelques années mais je n’y avais pas donné suite car les versions Informix récentes proposent l’équivalent (OPENADMINTOOL) : ICI.

Comme tu es en V7.25.UC6 comme je l’étais à l’époque, cela peut éventuellement te servir.

Bon courage !