Libreoffice. Module Base, syntax MySQL

Le
Dominique
Bonjour,

J'utilise le module Base de Libreoffice.

Je sais très bien trouver les enregistrements communs à 2 tables. J'ai
oublié comment on fait pour chercher les enregistrements de table1 qui
ne sont pas dans table2 :

Ma base est très simple, j'ai 2 tables : 2009 et 2010 avec chacune 3
champs : Compte, deb, cred

Compte est de type texte (VARCHAR).

Trouver tous les enregistrements de 2010 dont Compte n'a pas
d'équivalent dans Compte de 2009

Une réponse m'a été donnée sur un autre forum mais LIBO trébuche dessus :
SELECT * FROM table1
WHERE table1.champs11 NOT IN (SELECT champ21 FROM table2);

adaptée à mon cas :

SELECT * FROM 2010
WHERE 2010.Compte NOT IN (SELECT Compte FROM 2009);

J'ai systématiquement cette erreur :

Statut SQL: HY000
Code d'erreur: 1000

syntax error, unexpected $end, expecting BETWEEN or IN or SQL_TOKEN_LIKE

Je ne sais pas lire cette erreur et, surtout, je ne sais pas la résoudre.

Merci et bonne journée à tous,
--
Dominique
Courriel : dominique point sextant ate orange en France
Esto quod es
Vidéos High-Tech et Jeu Vidéo
Téléchargements
Vos réponses Page 1 / 2
Gagnez chaque mois un abonnement Premium avec GNT : Inscrivez-vous !
Trier par : date / pertinence
Benoit Izac
Le #24706192
Bonjour,

le 15/08/2012 à 10:22, Dominique a écrit dans le message

J'utilise le module Base de Libreoffice.

Je sais très bien trouver les enregistrements communs à 2 tables. J'ai
oublié comment on fait pour chercher les enregistrements de table1 qui
ne sont pas dans table2 :

Ma base est très simple, j'ai 2 tables : 2009 et 2010 avec chacune 3
champs : Compte, deb, cred

Compte est de type texte (VARCHAR).

Trouver tous les enregistrements de 2010 dont Compte n'a pas
d'équivalent dans Compte de 2009

Une réponse m'a été donnée sur un autre forum mais LIBO trébuche dessus :
SELECT * FROM table1
WHERE table1.champs11 NOT IN (SELECT champ21 FROM table2);

adaptée à mon cas :

SELECT * FROM 2010
WHERE 2010.Compte NOT IN (SELECT Compte FROM 2009);

J'ai systématiquement cette erreur :

Statut SQL: HY000
Code d'erreur: 1000

syntax error, unexpected $end, expecting BETWEEN or IN or SQL_TOKEN_LIKE

Je ne sais pas lire cette erreur et, surtout, je ne sais pas la résoudre.



Tu peux essayer une jointure :
SELECT 2009.Compte, 2009.deb, 2009.cred
FROM 2009 LEFT JOIN 2010
ON 2009.Compte = 2010.Compte
WHERE 2010.Compte IS NULL;

Personnellement, j'utilise
pour m'y retrouver.

--
Benoit Izac
Dominique
Le #24706982
Le 15/08/2012 14:43, Benoit Izac a écrit :

Tu peux essayer une jointure :
SELECT 2009.Compte, 2009.deb, 2009.cred
FROM 2009 LEFT JOIN 2010
ON 2009.Compte = 2010.Compte
WHERE 2010.Compte IS NULL;

Personnellement, j'utilise
pour m'y retrouver.




Il est bien présenté, ton graphique.

J'ai testé ta formule et j'ai toujours la même réponse :

Statut SQL: HY000
Code d'erreur: 1000

syntax error, unexpected $end, expecting BETWEEN or IN or SQL_TOKEN_LIKE

Je me demande si ça ne viendrait pas d'un bug de Libreoffice... Je vais
poser la question sur un forum spécialisé.

Je te remercie et te souhaite une bonne fin de journée,


--
Dominique
Courriel : dominique point sextant ate orange en France
Esto quod es
Ph. B.
Le #24708362
Dominique a écrit :
Bonjour,

J'utilise le module Base de Libreoffice.

Je sais très bien trouver les enregistrements communs à 2 tables. J'ai
oublié comment on fait pour chercher les enregistrements de table1 qui
ne sont pas dans table2 :

Ma base est très simple, j'ai 2 tables : 2009 et 2010 avec chacune 3
champs : Compte, deb, cred

Compte est de type texte (VARCHAR).

Trouver tous les enregistrements de 2010 dont Compte n'a pas
d'équivalent dans Compte de 2009

Une réponse m'a été donnée sur un autre forum mais LIBO trébuche dessus :
SELECT * FROM table1
WHERE table1.champs11 NOT IN (SELECT champ21 FROM table2);

adaptée à mon cas :

SELECT * FROM 2010
WHERE 2010.Compte NOT IN (SELECT Compte FROM 2009);

J'ai systématiquement cette erreur :

Statut SQL: HY000
Code d'erreur: 1000

syntax error, unexpected $end, expecting BETWEEN or IN or SQL_TOKEN_LIKE

Je ne sais pas lire cette erreur et, surtout, je ne sais pas la résoudre.

Merci et bonne journée à tous,


Bonjour,

Le nom de la table est incorrect. Double-quotez la pour que LO puisse
l'analyser :

select * from "2009"

Sinon renommer les tables en T2009 et T2010. La requête fonctionnera :

select
*
from T2009
where Compte not in
(
select Compte
from T2010
)

Attention également à la casse des caractères sur les noms de colonne...
--
Philippe.
Dominique
Le #24709112
Le 16/08/2012 13:52, Ph. B. a écrit :

Le nom de la table est incorrect. Double-quotez la pour que LO puisse
l'analyser :

select * from "2009"

Sinon renommer les tables en T2009 et T2010. La requête fonctionnera :

select
*
from T2009
where Compte not in
(
select Compte
from T2010
)



En bien, c'était filou. J'ai renommé en T2009 et T2010 et ça fonctionne :-)

Merci beaucoup mais pourquoi LO est-il incapable d'analyser une table
avec juste des caractères numériques dans le nom d'une table ?

Bonne soirée,


--
Dominique
Courriel : dominique point sextant ate orange en France
Esto quod es
Benoit Izac
Le #24709172
Bonjour,

le 16/08/2012 à 19:39, Dominique a écrit dans le message

Merci beaucoup mais pourquoi LO est-il incapable d'analyser une table
avec juste des caractères numériques dans le nom d'une table ?



Je n'ai pas tiqué mais j'ai le même comportement avec postgresql (enfin
il ne me laisse pas la créer). Je pense que c'est comme la plupart des
noms de variable dans la majorité des langages de programmation : on ne
peut pas utiliser un caractère numérique au début du nom de la variable.

--
Benoit Izac
Ph. B.
Le #24709302
Dominique a écrit :
Le 16/08/2012 13:52, Ph. B. a écrit :

Le nom de la table est incorrect. Double-quotez la pour que LO puisse
l'analyser :

select * from "2009"

Sinon renommer les tables en T2009 et T2010. La requête fonctionnera :

select
*
from T2009
where Compte not in
(
select Compte
from T2010
)



En bien, c'était filou. J'ai renommé en T2009 et T2010 et ça fonctionne :-)

Merci beaucoup mais pourquoi LO est-il incapable d'analyser une table
avec juste des caractères numériques dans le nom d'une table ?

Bonne soirée,



Mais LO l'accepte, enfin au moins la version 3.5.5 ;-)

select
*
from "2009"
where Compte not in
(
select Compte
from "2010"
)

Cela étant, SQL "normalisé" ne permet pas le nommage des objets (table,
colonne, etc) commençant par un chiffre...
--
Philippe.
Dominique
Le #24709412
Le 16/08/2012 20:51, Ph. B. a écrit :


Mais LO l'accepte, enfin au moins la version 3.5.5 ;-)

select
*
from "2009"
where Compte not in
(
select Compte
from "2010"
)

Cela étant, SQL "normalisé" ne permet pas le nommage des objets (table,
colonne, etc) commençant par un chiffre...



Je ne savais pas. Un jour, à la retraite peut-être, j'essayerai de faire
autre chose que butiner avec MySQL... C'est fou ce que je me suis mis de
côté pour la retraite. Je ne pourrai jamais tout faire :-)

Merci et bonne soirée,

--
Dominique
Courriel : dominique point sextant ate orange en France
Esto quod es
Denis Beauregard
Le #24709402
Le Thu, 16 Aug 2012 19:39:27 +0200, Dominique dans fr.comp.applications.sgbd:

Merci beaucoup mais pourquoi LO est-il incapable d'analyser une table
avec juste des caractères numériques dans le nom d'une table ?



Et comment il le sait que c'est une variable ?

Techniquement, il doit transformer les variables en constantes. Alors,
si 2011 est une constante comme un pointeur et qu'il cherche donc une
table à l'adresse 2011 et non une table appelée 2011...

M'enfin, il faut suivre la syntaxe du langage et c'est à peu près
partout la même chose : un chiffre indique une constante (sauf en
Cobol ?).


Denis
Dominique
Le #24709992
Le 16/08/2012 21:31, Denis Beauregard a écrit :
Le Thu, 16 Aug 2012 19:39:27 +0200, Dominique dans fr.comp.applications.sgbd:

Merci beaucoup mais pourquoi LO est-il incapable d'analyser une table
avec juste des caractères numériques dans le nom d'une table ?



Et comment il le sait que c'est une variable ?

Techniquement, il doit transformer les variables en constantes. Alors,
si 2011 est une constante comme un pointeur et qu'il cherche donc une
table à l'adresse 2011 et non une table appelée 2011...

M'enfin, il faut suivre la syntaxe du langage et c'est à peu près
partout la même chose : un chiffre indique une constante (sauf en
Cobol ?).



Du haut de mes 54 ans, je suis un pur produit du Basic (GWBasic plus
particulièrement gracieusement fournit avec le déjà bien ancien DOS et
le Locomotive Basic qui équipait les Amstrad CPC 464. Je ne sais plus
quel Basic a vu mes premières lignes de code avec un Sharp PC1211 que je
possède toujours) et, c'est vrai, je ne nommais jamais une variable avec
uniquement des chiffres.

Déjà, il y a trente ans...

Bon, c'est promis. Je mettrai toujours au moins un caractère
alphabétique dans mes noms de tables :-)

Merci et bonne journée,

--
Dominique
Courriel : dominique point sextant ate orange en France
Esto quod es
SQLpro
Le #24728342
Le 17/08/2012 05:45, Dominique a écrit :
Le 16/08/2012 21:31, Denis Beauregard a écrit :
Le Thu, 16 Aug 2012 19:39:27 +0200, Dominique dans fr.comp.applications.sgbd:

Merci beaucoup mais pourquoi LO est-il incapable d'analyser une table
avec juste des caractères numériques dans le nom d'une table ?



Et comment il le sait que c'est une variable ?

Techniquement, il doit transformer les variables en constantes. Alors,
si 2011 est une constante comme un pointeur et qu'il cherche donc une
table à l'adresse 2011 et non une table appelée 2011...

M'enfin, il faut suivre la syntaxe du langage et c'est à peu près
partout la même chose : un chiffre indique une constante (sauf en
Cobol ?).



Du haut de mes 54 ans, je suis un pur produit du Basic (GWBasic plus
particulièrement gracieusement fournit avec le déjà bien ancien DOS et
le Locomotive Basic qui équipait les Amstrad CPC 464. Je ne sais plus
quel Basic a vu mes premières lignes de code avec un Sharp PC1211 que je
possède toujours) et, c'est vrai, je ne nommais jamais une variable avec
uniquement des chiffres.

Déjà, il y a trente ans...

Bon, c'est promis. Je mettrai toujours au moins un caractère
alphabétique dans mes noms de tables :-)

Merci et bonne journée,




la norme sur les noms des objets SQL :
http://sqlpro.developpez.com/cours/sqlaz/ddl/?page=partie1#L1

A +



--
Frédéric BROUARD - expert SGBDR et SQL - MVP SQL Server - 06 11 86 40 66
Le site sur le langage SQL et les SGBDR : http://sqlpro.developpez.com
Enseignant Arts & Métiers PACA, ISEN Toulon et CESI/EXIA Aix en Provence
Audit, conseil, expertise, formation, modélisation, tuning, optimisation
*********************** http://www.sqlspot.com *************************
Publicité
Poster une réponse
Anonyme