Reprise du message précédent :

Tous.

 
Ah si, enfin ça se met par défaut.
Par contre le système que j'ai donné marche même quand il y a ces champs là je viens de tester. ("INSERT INTO table VALUES();" )

Par défaut ya pas de rows NOT NULL si?

Je m'y attendais, MySQL wins again  
 
Et il met quoi comme merdes dans tes rows?
 
edit: t'es en MyISAM en plus non?

 
Il me met des 0 dans les int, des 0000-00-00 et cie dans les datetime, et rien dans les autres
 
Et oui je suis en MyISAM c'est mal ? Je t'avouerai que j'ai laissé car c'est par défaut, je connais pas les conséquences du choix du moteur SQL sur le reste. Ca change quoi en fait ?

Et rien dans les autre = chaîne vide dans les char, ou bien NULL dans les char?

Bah disons que c'est pas nécessairement si t'aimes tes données, ou si t'aimes écrire dans ta db, ou si t'aimes les comportements cohérents, ou si t'aimes les transactions.

Je vais te référer à la doc, parce que la liste est très longue, ne serait-ce qu'entre myisam et innodb.

rien d'autres = vide
MySQL te fait rêver, avoue  

Mais finalement la bonne méthode pour mon histoire, ce serait de faire comment ? buffering ?

 
non, mais ça n'a rien à voir avec le type de données.

1) stocker le contenu validé de ton formulaire dans une structure de données adaptée
2) Enregistrer ensuite cette structure dans la base dans une transaction.

J'pense que tu devrais une fois lire un bouquin sur SQL au lieu d'avancer à tâtons.

VIDE ÇA VEUT RIEN DIRE DU TOUT /FOU/
 
Sauf dans Oracle où NULL et une chaîne vide c'est pareil, mais c'est un autre problème.

Bon fait une table genre "ids" avec juste un champ id tout seul auto_increment. T'insère vide là-dedans, tu récupères ce qui vient d'être inséré avec last_insert_id_bidule, et après t'insert dans ton autre table tous les champs avec ton id flambant neuf. Et comme ça tu peux virer tous les NULL qui font chier    
 
C'est moche mais de toute manière à mon avis on n'est plus à ça près

Il a besoin de son id avant Je lui offre une solution pour générer un id avant De toute manière ça ne va pas être le truc le plus moche de son appli Y'a un moment faut être pragmatique

C'est plus que douteux, son "besoin" d'id avant vient probablement du foutoir du code autour.

Ça de toute manière

J'ai vu une technique similaire dans une boîte pour laquelle j'ai travaillé dans le passé mais je trouve ça dégueu (sauf que leur table stockait des compteurs, un pour chaque table ayant besoin de générer des IDs).
 
J'ai pas voulu le mentionner pour qu'il cherche plutôt à remettre en question ce qu'il a fait

Ils bossaient avec une db sans séquences?

 
O_o  
 
Tu fais exprès de proposer la méthode qui a l'air la plus crade possible ?
Au lieu juste de faire une insertion nulle dans un seul fichier de tout le projet, tu préfères doubler chaque table principale avec une table inutile. Genre t'as 20 tables principales, tu te retrouves avec 20 tables de plus qui contiennent juste des IDs O_o
 
Surtout que je proposais la solution du buffering qui me semble quand même totalement adapté à ma problématique...  

Moi je comprends pas ce que tu entends par buffering...
 
Tu stockerais les élements à créer au fur et à mesure avant de les insérer tous en mm tps dans la BDD c'est bien ça ?

 
Tous les éléments à créer dans les tables de liaison oui

Et pas ceux dans les table principales ?

 
mon foreach $_POST crée au fur et à mesure la chaine d'INSERT de la table principale, le souci était les insert de liaison car j'avais pas l'ID, donc le truc serait de mettre en buffer les insert de liaison, en attendant d'avoir l'ID. Ca me semble être la meilleure solution vu la problématique.

Mais pourquoi sacrebleu tu ne traites pas tes formulaires, rentre les infos dans des objets/tableaux propres dédiés, et seulement une fois que tout est traité tu effectues les INSERT, soit dans un bon ordre, soit éventuellement avec des UPDATE pour updater les clés étrangères après coup ?

Bah c'est ce que je fais
 
J'attends que tout soit traité, puis je fais l'insert principale et les insert secondaires dans les tables de liaison.

Je crois, plus certain, c'était il y a longtemps

C'est normal si en essayant d'importer du XLS ou du CSV dans une base MySQL, j'ai toujours des erreurs ? Pourtant c'est juste une colonne et 500 lignes. L'importation ne marche qu'avec des fichiers .sql ?

tu le charges comment ?

via PhpMyAdmin

c'est quoi l'erreur ?

Il me balance un problème dans la syntaxe, alors qu'il y a rien de particulier

ne donne surtout pas le message , ça aiderai

Je doute que ça aide mais bon dans le doute :  
 
"#1064 - You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near 'La Défense (M1 RA T2 SL SU)
Esplanade de la Défense (M1)
Pont de Neuilly (M1)
' at line 1 "

Le problème c'est qu'il attend une requête SQL, alors que mon fichier n'en contient pas. C'est ça le souci, d'où ma question "est-ce que le systèe d'importation ne fonctionne qu'avec des fichiers .sql ?"

ben s'il te lance une erreur c'est forcement qu'il y a un problème.

Ah oui je précise (au cas où) : phpMyAdmin - 2.10.3deb1ubuntu0.2
 
Edit : également, et c'est peut être ça la source de mon souci, j'ai importé à la racine de phpmyadmin sans avoir sélectionné de table, dans l'idée qu'il allait m'en créer une avec mon fichier, mais il faut peut être que je crée une table d'abord et que j'importe les données ensuite
 
Edit 2 : en effet c'était la source du souci C'est bon c'est réglé, merki

Tit probleme en SQL :
 

 
La jointure fonctionne sans souci, le problème c'est que comme j'ai le même nom de colonne dans les 2 tables (à savoir actualites_id), si une actu n'est relié à rien dans actupays, alors j'arrive pas à afficher son ['actualites_id'], j'ai bien essayé de faire un ['actualites.actualites_id'] pour préciser, mais ça marche pas, une idée ? (à part changer le nom )

SELECT actualites.actualites_id AS un_autre_nom

 
Ah oui pas con  
Une autre solution à connaître à part celle-ci ? au niveau de la jointure peut-être ?

Ne pas sélectionner l'autre champ.
 
C'est tout.

Ok, au moins c'est fixé