Discussion :

[ctxnop]

Bonjour a tous !
Voila, je cherche un parser SQL comme le titre l'indique. Si possible gratuit (mais pas GPL, je dois pouvoir l'utiliser dans un produit commercial à source fermé .... c'est la patron qui décide )
Je suis tout de même preneur des payants, on sait jamais, s'ils sont vraiment mieux...

Mes contraintes sont les suivantes :
- La syntaxe parsable doit être celle de Sql Server (version 2005 pour être précis, au cas où il y aurait de grosses différences entres les version, je les connais pas).

- La syntaxe SQL Ansi 89 n'est pas du tout suffisante (il manque notemment, mais pas seulement, la gestion des schémas (select dbo.ma_table.ma_colonne FROM dbo.ma_table)

- Le parser comprendre la syntaxe a crochet de MS (select [dbo].[ma_table].[ma_colonne] FROM [dbo].[ma_table] )

- La problématique premiere que doit résoudre le parser est la suivante :
Notre soft fait beaucoup mumuse avec la base de donnée, et permet a l'utilisateur final d'ajouter de nouvelles tables et vues. Les tables sont créées via un assistant. Par contre les vues sont trop complexes pour pouvoir être crées de la même manière. En conséquence, l'utilisateur tape sa requête select (avec jointure, union, agrégation et tout les joyeusetés que permettent le SQL). Ensuite, il click sur un bouton, et ca modifie le scripte pour ajouter tout ce qu'il faut (les closes CREATE VIEW, les insertions/mises a jour de nos tables système pour renseigner notre soft de l'apparition de la nouvelle vue, le lancement des procédures, etc, etc, ...).
Je dois donc pouvoir analyser sa requête et connaitre :
- Les tables utilisées
- les jointures faites
- les noms des champs en entrée et sortie de la requête (champs avec alias, unions et tout le bordel)
- les champs entièrement calculés
- les champs utilisés dans le calcule d'autres champs (genre un champs qui serait COALLESCE(col1, col2, col3, 'robert') AS Prenom )
- ...

Voila, ca c'est le "minimum vital" dont j'ai besoin. Idéalement, j'aimerai pouvoir parser n'importe quel type de requête (insert, update, scripte multi-requête, ...).

J'ai évidemment fait quelques recherches avants et je suis tombé sur deux parsers :
- http://www.sqlparser.com/ (General Sql Parser)
- http://www.devincook.com/goldparser/

Le premier, mon patron l'a acheté. Il marche pas trop mal, mais c'est loin d'être la joie. Il ne gère pas les schéma, a tendance a planter sur des requêtes un brin complexes (genre un UNION ALL et pouf le parser meurt).
J'arrive plus ou moins a combler les défauts mais ca donne un code très bancale et pas propre du tout.

Le second est un "concepte" plus qu'un parser. On trouve en téléchargement des implémentations diverses et variées dans des langages tout aussi variés.
C'est un parser encore plus général puisqu'il se base sur un fichier de grammaire pour parser le texte fournis. On peux donc potentiellement obtenir un parser de n'importe quel language. J'ai trouvé la grammaire de la syntaxe Sql Ansi, mais pas celle de SqlServer. J'ai tenté de l'adapté un peu mais je galère grave. En plus, jusqu'ici, j'ai pas été foutu de réussir a parser un pauvre "select * from dbo.matable;". Mais bon ca c'est juste une question de persévérance et de temps pour bien prendre en main le bouzin (sauf que comme d'hab, le temps on l'a pas, ce devra être fini pour hier ...)

Donc voila, si vous connaissez des parser ou que vous possédez un fichier de grammaire correcte. Ou encore que vous avez des conseils sur comment palier aux différentes problématiques énoncées... D'ailleur je me demandait s'il n'y avait pas moyen de faire parser le scripte à SqlServer, sans qu'il exécute quoi que ce soit, et qu'il me retourne le résultat de manière exploitable (non parce que pour le moment il veux bien parser mes scripts mes il me répond juste "Ok" ou "tu as écris n'importe quoi, recommence ispice de noob"). Je pense notamment a Smo, Nmo et tout la suite.

Merci de votre aide, de votre temps et de vos conseils

Edit :
Petites précisions. Le scripte est entré dans un composant a coloration syntaxique. Ce sera soit ScintillaNet si j'arrive a faire comprendre a mon patron que c'est du LGPL, qu'on a le droit et que le libre n'est pas le mal incarné. Soit ca sera SyntaxEditor d'ActiproSoftware.
Le premier étant open source, je peux le modifier pour qu'il parse en même temps qu'il fait sa coloration syntaxique.
Le second est a base de plugin surchargeable pour créer les syntaxes. On pourrait donc imaginer l'étendre pour que lui aussi parse en même temps qu'il fait la coloration.
Le problème serait alors surtout la masse de boulot. Parce que l'un comme l'autre ne font que catégoriser quelques mots clefs. Autrement dit, ils ne savent absolument pas faire la différence entre "SELECT" et "INSERT", ils savent juste que ces deux mots doivent être coloriés. De plus, ca ne vérifie aucunement la syntaxe. Écrire

Code sql :

Sélectionner tout - Visualiser dans une fenêtre à part

SELECT INSERT; FROM UNION COALLESCE(CREATE, TABLE)

, ben ca les choques pas du tout.

[Pol63]

je ne comprends pas ce que veux dire parser du sql

par contre avec les dll d'sql server (smo) tu peux faire pas mal de chose
et créer son propre éditeur de requete (surtout avec smo) est faisable

[ctxnop]

C'est très simple. Je veux fournit une requête sous la forme d'un string a un parser.
Admettons :

Code sql :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
 
SELECT
    [dbo].[ma_table].[col_01] AS [Data]
FROM [dbo].[ma_table]
UNION ALL
SELECT
    COALLESCE(datas, 'rien') AS [Data]
FROM [dbo].[une_autre_table]

Je passe donc cette requête au parser, qui va me dire :
- Il y a une union de plusieures requêtes SELECT
- Dans la premiere requête, la selection se fait sur la table [dbo].[ma_table].
- Seul la colonne [col_01] de cette table est utilisée, et est aliasée en [Data]
...
etc ...
je veux donc pouvoir avoir accès a ce genre d'information sur la requête fournie, sans avoir a éxécuter la requête en question.

Tout ca dans le but d'avoir les informations nécéssaire à la création du scripte final.

Je me sert déjà pas mal de smo (pour faire un semblant d'intellisense notement, mais également récupérer le scripte ayant servit a la création d'une vue/d'un trigger/...

J'ai cherché un peu dedans, mais je n'ai rien trouvé qui me permettrait d'analyser une requête. Mais Smo c'est pas petit, je suis peut-être passé a coté. Si tu as des pistes/exemples/nom d'objets/liens de documentations ... je suis prenneur.

[Pol63]

je vais regarder dans smo, parce que ce genre de truc m'intéresserait peut etre aussi

sinon avec SET FMT_ONLY ON tu peux exécuter la requête instantanément sans retour de données à part la structure des champs (et au passage ca te dis si la requête et exécutable)

et merci je viens d'apprendre le mot "parser", qui en plus est français ...

[ctxnop]

Je regarderai de plus près le SET FMT_ONLY, mais si ca ne fait que retourner une table vide pour avoir les colonnes, ca ne sera pas suffisant malheureusement. J'ai besoin de savoir comment est faite la colonne (pour maintenir une table de lien de parenté/héritage).
Cependant, rien ne m'empêche de me servire de ca pour savoir si ma requête est exécutable et ce qu'elle retourne comme structure, pour macher le boulot du parser et orienter ma recherche d'information complémentaire par la suite.

Je ne savais pas que le mot "parser" était français. J'ai toujours cru qu'on avait pas vraiment d'équivalent mieux que "analyseur de syntaxe" ou quelque chose comme ca.

PS: Ah oui, une fonction que j'aimerai bien avoir (présente dans Gold parser) c'est quand il y a une erreure de syntax qu'il te dise ce qui était attendu pour valider la syntaxe.
Exemple :

Code sql :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
 
SELECT * WHERE a = 12;

Il devrait me dire "erreure près de '*', la clause FROM était attendue.

[Pol63]

on a fait un éditeur de requete, et on se sert de fmt_only pour savoir si la requete fonctionne
sachant que si elle fonctionne pas tu as les messages d'erreur comme tu le souhaites, ce qui aide à corriger


de plus sur l'execute tu peux passer un paramètre (qui vient d'une enum) pour dire que tu veux que ca remonte toutes les infos de structure

donc sur chaque colonne tu peux savoir si c'est une clé primaire, le nom de la table, le nom du champ, son alias, le type, la taille du champs ...

m'enfin dans un union t'as pas d'infos ...