Forum d'entraide PHPFrance

Bonjour.

Je viens de constater un détail bizarre dans SQLiteManager : quand on crée ou quand on modifie une table, la clef primaire (si on en met une) tombe inévitablement sur le premier champ ??? Même si on demande à ce qu'elle soit affectée à un autre champ, quelle que soit la méthode, c'est le premier que la récupère.
Ce qui est encore plus étonnant, c'est que quand on regarde la requête qui est générée automatiquement lors de la manipulation d'affectation de la clef primaire, on voit bien que cette dernière est affectée au champ qu'on a demandé. Et pourtant, c'est toujours le premier qui devient clef primaire.

Est-ce un bug (ça en a tout l'air) ? Est-ce que ça ne fait ça que chez moi ?

la clef primaire (si on en met une)

T'arrives à faire des bases sans clé primaire ?

Sinon, j'arrive pas à comprendre ta question.. Tu te demandes pourquoi ta clé primaire est en premier ?

Ok, je repose le problème différemment.

D'abord, je ne parle pas de faire une base mais juste une table. Dans SQLite comme dans beaucoup d'autres SGBD, on n'est pas du tout obligé de créer une table directement avec sa clef primaire : on peut la définir après coup.
Deuxièmement, quand je parle de "premier champ", je veux dire par là que les champs d'une table sont toujours présentés dans un certain ordre : l'ordre dans lequel on les a définis lors de la création de la table.
Maintenant, ce que je constate, c'est que je ne peux pas demander à SQLiteManager de placer la clef primaire sur un autre champ que celui qui a été défini en premier. Et je ne vois vraiment pas pourquoi je devrais forcément choisir ce champ là comme clef primaire. D'ailleurs, dans ce cas, pourquoi l'interface de SQLiteManager semble-t-elle proposer que n'importe quel champ devienne clef primaire ?
Quand on crée une table, on peut bien cocher n'importe quel champ comme clef primaire, non ? Et on peut bien à tout moment modifier un champ et le cocher comme clef primaire, non ? Donc ma question est : pourquoi ça ne marche pas, pourquoi est-ce qu'il m'oblige à utiliser le 1er champ de ma table comme clef primaire ? Est-ce un bug connu de SQLiteManager ou un problème de configuration chez moi ?

it's not a bug, it's a feature !!

Peut-être que c'est pour bien les mettre en évidence ? de toute façon, qu'importe l'ordre des colonnes..

Il y a un surement un rapport avec MERISE

it's not a bug, it's a feature !!

Peut-être que c'est pour bien les mettre en évidence ? de toute façon, qu'importe l'ordre des colonnes..

Oui, Berzemus, je suis bien d'accord que l'ordre des colonnes n'a pas d'importance, mais par contre, pouvoir définir celle qu'on veut comme clef primaire, ça, ça a un maximum d'importance. Je comprend l'idée que dans le classement des colonnes, SQLite préfère que la clef primaire soit en première position (encore que, si justement ça n'a aucune importance, à quoi ça sert ??? ), mais j'en conclu donc que si on se trompe par exemple dans le choix de la clef primaire d'une table, il faut donc changer l'ordre des colonnes pour mettre la bonne en première place (hyper pratique)... Et voici maintenant la question qui tue : comment fait-on pour changer l'ordre des colonnes dans SQLiteManager ? Ou dans SQLite tout court ???

D'autre part, je ne sais pas si vous avez bien compris de quoi je parle en fait, parce que quand je clique sur le petit bouton en forme de clef avec marqué "PK" dedans en face du champ "Troisieme" (que je veux donc mettre en clef primaire), SQLiteManager me génère la requête suivante :
Logique ce code, il recrée la table en appliquant la clef primaire là où je le lui demande. Mais à l'exécution, le résultat c'est que c'est le champ "Premier" qui se retrouve en clef primaire. On a beau dire que c'est pas un bug, moi je la trouve très louche cette "feature".

Pourquoi vouloir réinventer la poudre ?
Quand tu crée tes tables, ton premier champ sera ta clé primaire, car si tu suis une certaine logique c'est bien le champ le plus important de ta table.. Bref, ça c'est une chose, ensuite le fait que SQLlite te mette obligatoirement ton premier champ en PK et ce même si tu lui défini bien un autre, effectivement c'est emm****.

La solution : prendre en compte cet aspect et réfléchir avant de construire tes tables (passe par papier)

Ok, donc conclusion : l'ergonomie de SQLiteManager n'est pas top, voir tend un peu vers le bug, mais quand on le sait, il suffit d'en tenir compte.

Perso j'utilise MySQL Query Browser, essaie le

_activmik, merci de ton implication, mais dans le cas présent, je pense que tu n'as pas saisie le problème ...

Louisss travaille avec SQLite, pas avec MySQL.
Ensuite, sache qu'il est possible de sortir des chemins tracés. J'ai eu à créer des tables sans clés primaires pour des besoins de performances et car l'unicité ne m'intéressait pas.
De plus, une clé primaire peut se trouver n'importe où dans la table, voir même sur plusieurs champs

Sinon, pour toi Louisss, à part un bug dans ton logiciel, je ne vois pas ... est-ce que tu peux essayer avec un autre logiciel ?

Quand elle se trouve sur plusieurs champ, ça devient une clé composite non ? Or il parle que de clé primaire... Bref ne jouons pas sur les mots, l'important c'est qu'il est trouvé une solution

une clé primaire composite reste une clé primaire ...

Je maitrise pas assez cette particularité pour débattre, je fais confiance à ton savoir

Hep hep, qui parle de clef primaire composite ? Ce n'est pas le problème que j'évoque (d'ailleurs, j'ai cru comprendre que SQLite ne permet pas les clefs primaires composées de plusieurs champs). Non, moi mon problème c'est juste de pouvoir changer la clef primaire d'une table : prendre un champ à la place d'un autre pour tenir ce rôle.

Donc, ce serait bien un bug d'après toi zeus ? Mais je suis vraiment très étonné que mon SQLiteManager soit buggé, car comme PHPMyAdmin, c'est une simple distribution d'un site Web que j'ouvre en local avec mon serveur Apache perso. Je serais très intéressé que quelqu'un puisse tester pour savoir si c'est un bug présent de façon générale dans SQLiteManager et qui sera (est ?) peut-être corrigé dans une nouvelle version, ou bien si c'est moi qui ai un problème non général. Pour info, j'utilise MAMP pour mes développements en PHP et c'est donc lui qui me fournit SQLiteManager en version 1.2.

De mon côté, j'ai essayé d'exécuter directement la requête de création de table dans une page PHP plutôt que dans SQLiteManager. Résultats :

Cette requête me colle la clef primaire sur le champ "Premier".

Cette requête me colle la clef primaire sur le champ "Second".

Donc, le problème ne vient visiblement pas de SQLiteManager, mais de l'interprétation de ma requête par SQLite lui-même.
Ma base est en version 2, et SQLite en version 2.8.17.

Il existe peut-être une version plus récente ?

Autre détail intéressant : j'ai fait un test sur un SQLiteManager mis à disposition en ligne à l'adresse : http://synd-mixte.rain.fr/sqlitemanager/
C'est exactement la même version que moi.
J'ai essayé de créer une table avec le troisième champ comme clef primaire : même résultat c'est le premier champ qui est retenu comme clef primaire. Le problème ne vient donc visiblement pas de chez moi, mais on dirait plutôt que c'est un bug de cette version de SQLite.
Alors si quelqu'un peut me dire où trouver une version plus récente qui corrige ce bug, ce serait génial, même si on est bien d'accord que ça n'a rien de fondamental.

De mon expérience avec SQLITE et ce qu'on peut trouver comme "manager": a éviter.

Le mieux, c'est de créer, gérer et administrer la table directement en php, ou sinon, par un pont ODBC depuis DBVisualiser ou quelque chose comme ça.

Ou trouver un semblable à phpmyadmin mais pour sqlite. Car la principale différence entre sqlitemanager et phpmyadmin, c'est que mysql est un serveur de données en tant que tel, alors que pour ouvrir une db sqlite, le logiciel doit fournir sa propre implentation de sqlite, qui diffère quasi tout le temps. Mieux vaut donc utiliser celle de php5 directement.

Sinon, pour examiner et étudier mes db sqlite, j'utilise plutôt sqliteadmin, mais jamais pour agir sur les données ou apporter des changements.