drop table sans nom

[heretik25]

Bonour,

J'ai un souci, j'ai des tables sans noms et je n'arrive pas à les supprimer avec pgadmin.

Auriez vous une astuce ?

merci.

[alassanediakite]

Salut
Comment savoir qu'il y a des tables sans nom?
@+

[heretik25]

Dans pgadmin, j'ai des lignes de tables mais qui ne possèdent pas de nom. Je ne sais pas quelle requête m'a généré de telles aberrations mais j'aimerais les supprimer.

CF PJ.

Merci et @+.

[estofilo]

En principe il n'y a pas de table sans nom mais il y peut y avoir des noms bizarres, par exemple constitués d'espaces uniquement.

Qu'est ce que donne en sql:

Code :

1
2
SELECT chr(34) || schemaname || '.' || tablename || chr(34) FROM pg_tables
WHERE schemaname NOT IN ('information_schema','pg_catalog')

[alassanediakite]

Salut
C'est vraiment étrange, mais je suis arrivé à faire...

Code :

ALTER TABLE T1 RENAME TO " ";

Mais ensuite je l'ais supprimer avec pgadmin (version 1.16.1). Même le ...

Code :

DROP TABLE " ";

passe!
N'est-il pas mieux que PostgreSQL (censé respecter les normes) empêche de telles dérives.
@+

[estofilo]

Et c'est quelle norme qui interdit un nom de table avec seulement des espaces?

[alassanediakite]

Salut estofilo
Ceci n'est pas pour vous contredire. Juste une argumentation.

• Envoyé par heretik25

  ...Je ne sais pas quelle requête m'a généré de telles aberrations mais j'aimerais les supprimer.

• Envoyé par estofilo

  En principe il n'y a pas de table sans nom...

• de sqlpro
• du même auteur
• et une discussion qui donne d'ailleurs les liens cités.

J'ai essayé avec:

• MySQL : refusé
• SQL server: accepté
• ACCESS: refusé
• Firebird (avec flamerobin ou dbeaver): refusé

Avec ORACLE je pense que c'est sera refusé.
Je m'arrête là. Mais recevrais vos arguments avec intérêts.
@+

[estofilo]

Avec Oracle on peut faire CREATE TABLE " " (...), ça ne provoque pas d'erreur. C'est biensûr ridicule comme nom de table mais c'est le choix de l'utilisateur.

Grosso-modo le standard sql dit qu'on peut utiliser des espaces ou n'importe quel autre caractère dans les identifiants tant qu'on met des guillemets autour. Avoir uniquement des espaces est juste un cas particulier de cette règle.

Les SGBDs qui appliquent des règles différentes sont justement ceux qui ont choisi de ne pas suivre le standard. Ce n'est pas étonnant que ça concerne MySQL ou Access (je ne dirais rien pour firebird, jamais utilisé). Ceux-là ont comme par hasard leur propre syntaxe SQL avec des backquotes pour MySQL et des crochets pour Access pour entourer les identifiants.

[alassanediakite]

Salut estofilo
Dans l'ouvrage de Frédéric BROUARD, Rudi BRUCHEZ et Christian SOUTOU (livre censé enseigner le SQL standard),on lit (4ème édition page 60):

SQL impose un certain nombre de règles concernant les noms des objets d'une base de données. Un nom d'objet (table, colonne, contrainte, vue, etc.) doit avoir les caractéristiques suivantes:

• ne pas dépasser 128 caractères;
• commencer par une lettre;
• être composé de lettres, de chiffres et du caractère blanc souligné;
• ne pas être un mot réservé de SQL, à moins d'être mis entre guillemets.
  ...

Maintenant j'ai un bon argument pour ceux qui disent "ACCESS n'est pas sérieux en permettant l'espace dans les noms des objets..."
Pour le cas de ORACLE je suis vraiment étonné car je crois avoir lu "ORACLE n'accepte pas d'espace dans les noms d'objets"
J'étudie ORACLE par simple curiosité (en fait, je lis tout ce qui concerne les bases de données et qui me tombe sous la main)
@+

[heretik25]

Merci pour toutes vos réponses.

En fait je ne vois pas les noms car les tables ont un accent... En faisant un

Code :

DROP TABLE nom_table;

ça marche...

P.S : Ce n'est pas moi qui ai donné le nom à ces tables.

Peut-on configurer PGADMIN III pour voir le nom des tables ?

[alassanediakite]

Salut
Je pense que c'est un problème d'encodage.
Clique sur la base (dans l'arborescence) et regarde les propriétés à droite. Que te donne "codage"?
Comment avez-vous reçu la base?
@+

[estofilo]

SQL impose un certain nombre de règles concernant les noms des objets d'une base de données. Un nom d'objet (table, colonne, contrainte, vue, etc.) doit avoir les caractéristiques suivantes:

• ne pas dépasser 128 caractères;
• commencer par une lettre;
• être composé de lettres, de chiffres et du caractère blanc souligné;
• ne pas être un mot réservé de SQL, à moins d'être mis entre guillemets.
  ...

Les deux règles au milieu ne concernent qu'un sous-cas de la grammaire SQL.
La grammaire complète et toutes les règles associées (il y en a des pages) est lisible ici pour SQL-92:
http://www.contrib.andrew.cmu.edu/~s...ql/sql1992.txt

Voir l'élément lexical nommé <delimited identifier> ds le chapitre 5.2 <token> and <separator>. C'est ça qui fait que la grammaire SQL permet des espaces et plus généralement n'importe quel caractère dans un idenfiant entre guillemets.

[heretik25]

Envoyé par alassanediakite

Salut
Je pense que c'est un problème d'encodage.
Clique sur la base (dans l'arborescence) et regarde les propriétés à droite. Que te donne "codage"?
Comment avez-vous reçu la base?
@+

Codage : UTF8 !

[heretik25]

Envoyé par estofilo

Les deux règles au milieu ne concernent qu'un sous-cas de la grammaire SQL.
La grammaire complète et toutes les règles associées (il y en a des pages) est lisible ici pour SQL-92:
http://www.contrib.andrew.cmu.edu/~s...ql/sql1992.txt

Voir l'élément lexical nommé <delimited identifier> ds le chapitre 5.2 <token> and <separator>. C'est ça qui fait que la grammaire SQL permet des espaces et plus généralement n'importe quel caractère dans un idenfiant entre guillemets.

Effectivement, merci pour le rappel seulement, il ne s'agit pas de mes tables mais celles d'un prestataire qui utilise ces tables dans l'application développée. bref, hallucinant.