Bonjour,
 
Alors attention, voilà la requête :
 

 
Ne rigolez pas, mais ça plante !    
 
Qu'est ce que notre ami microsoft a encore inventé comme standard SQL ?    
 
J'ai "Syntax error in FROM clause". Qu'est ce qu'il faut faire ?    
 
Merci.

Voilà la requête générée avec le wizard :
 

 
faut vraiment donner cette requête à mon code Java ?    

La prochain coup que tu crées des tables sur un SGBD, renseigne toi sur les mots réservés avant.
 
Parameters est un mot réservé.
Normal donc que ça plante quand tu tentes de faire un SELECT sur un objet système.
 
Donc oui, la requête générée par le Wizard est doublement bonne car :
1/ Les [] sont le système d'échappement de Access et SQL Server. Sous MySql tu aurais eu par exemple `Parameters`
2/ Le * est à banir. J'attends avec impatience qu'un SGBD sorte un paramètre permettant de planter sauvagement lorsqu'on l'utilise autrement que via un requêteur "à la main".
 
Il y a 1000 raisons, et ces 1000 raisons ont chacune 1000 arguments abondant dans leurs sens, donc cherche pas à discuter, n'utilise pas le * dans tes programmes !
 
PS : Le prochain coup, tu crées une table "toto" et "select * from toto" marche parfaitement
C'est toi qu'est pas standard, à pas respecter les mots réservés des outils que tu utilises (et toc )

Merci .

J'vois pas pourquoi on utiliserais pas le *. Parfois c'est plus rapide de faire * que d'avoir que les champs qu'on veut (ca depends du ratio bande passante entre le SGBD et le client et puissance CPU du SGBD).

C'est plus rapide à taper (et encore...).
 
C'est bien le seul cas où c'est plus rapide, et quel que soit la BP, la puissance CPU ou la mémoire disponible.
 
Mais surtout, je ne parle pas des problèmes de maintenance.
 
Combien de connecteurs BDD utilisent un index numérique pour adresser une colonne ? Il se passe quoi alors si tu inserres une colonee plutôt que de l'ajouter à la fin de la définition ?
 
Mais aussi et surtout...
T'as une belle table produit, avec un champ numérique pour son ID, un champ numeric pour son prix, et un petit varchar pour son nom.
 
Allez, un petit * c'est bien, j'ai mes trois petits champs pour faire ma petite tambouille, je suis content.
 
Maintenant, "ah ben oui, mais avec une photo ça serait vachement mieux".
Allez, on rajoute un champ de type BLOB.
 
Ah pis avec un joli texte explicatif ça serait vachement plus joli sur le site web.
Allez, on va rajouter un CLOB.
 
Ah, merde, la répression des fraudes m'oblige à mettre à disposition une copie numérique de la documentation de mes produits aux clients... Pas de problème, je vais rajouter encore un BLOB pour y coller un PDF.
 
Ah ben voilà, maintenant quand dans une page tu listes 50 produits sous forme de liste (donc le nom, le prix, et un lien pour accéder à la page de détail) qui n'utilise que tes 3 premiers champs, tu t'amuses juste à récupérer 5 ou 6 Mo de données par produit.
Faut pas venir pleurer après si l'appli tiens pas la charge et qu'Access c'est de la merde parceque c'est lent...
 
Plutôt le développeur qui au lieu de faire confiance aux personnes qui ont déjà fait les frais de ce genre de pratiques, se trouvent plus malin que tout le monde "parceque sur mon PC avec deux lignes dand la base et moi tout seul qui consulte, c'est plus rapide à écrire qu'en énumérant uniquement les champs dont j'ai besoin".
 

 
PS : Et y'a encore d'autres raison. Mais celles-ci me semble quand même de loin suffisantes pour se faire une raison : *, tu le tapes dans TOAD, jamais dans ton code. Pour ça les ERP c'est très bien d'ailleurs. Une table ça fait systématiquement 50 champs, donc de toute façon avec un * tu passes plus de temps à trouver l'info dans les 800 colonnes de résultat qu'à taper le nom des champs lors de la requête

Un bon pilote SGBD/SGBD ne renvoi qu'une reference pour le BLOB et il est chargé quand on fait MaQuery.GetColonne("MON_BLOB" ).AsBlob.
 
(Aujourd'hui on utilise des Gestionnaire de persistance (mapping objet-relationel) et tu verrais les requetes que ça balance )
 
Apres le BLOB à la base c'est le mal.
Puis quand t'as une table avec 50-60 colonnes, listes les 30 colonnes dont t'as besoin c'est pas cool non plus.

Un bon pilote va récupérer en vitesse la page en cours de lecture, puis va préparer son cache pour tout le reste.
Notamment, sur le serveur, il va charger en arrière plan toutes les données, y compris le BLOB, afin de ne pas pas surcharger le SGBD au moment où tu vas commencer à lire dedans.
 
Donc non, il ne faut jamais récupérer ce qu'on ne veut pas lire.
 
http://dotnetjunkies.com/Article/8 [...] C11BE.dcik
Point 6.
 
N'importe quelle doc SQL indiquant ce qu'il ne faut pas faire indiquera SYSTEMATIQUEMENT le select * parmis les 10 trucs à surtout pas faire

Par curiosité, MagicBuzz, tu es DBA...tu m'as d'être pas mal cultivé en BDD .

non, je ne suis pas dba du tout, simple développeur
(d'ailleurs ne me demande pas comment faire une reconstruction "propre" d'index, je sais pas faire )
 
mais vu que je dois souvent taper dans de grosses bases d'ERP sous divers SGBD, j'ai pas mal potassé les mécanismes d'interrogation des bases de données.

OK très bien.
 
Bon une autre question "access" . Ma requête update marche pas . Ca peut venir d'où ?
 

 
N.B. : les 25 colonnes de la table History sont de type texte.

Bon déjà y'a l'erreur des 'and' dans le WHERE à la places des virgules...mais ça plantait encore et j'ai trouvé d'où ça vient !
 
Currency est un mot clé !              
 
Faut vraiment que j'écoute MagicBuzz, sinon jvé finir par tous les utiliser.        

Y'a une technique qui existe, c'est de prefixer les champs.
 
Par exemple tu prefixe tout par HIS_ ...

C'est exactement ce que j'ai fait !...non mais jvé pas changer le nom de toutes mes colonnes à cause d'Access ! .

Sinon, tu mets simplement les colonnes qui ont un nom réserver entre crochets...
 
[Currency] sera compris par access comme le champ "currency".
 
Autre élément, tu utilises la syntaxe complète :
 
History.Currency = ...
 
=> "logiquement" Access devrait comprendre qu'il s'agit d'un champ (c'est à tester, parcequ'Access ça reste Access quand même )