babaluga

Wilco Bauer travaille à l’implémentation d’IronRuby. Il marche ainsi sur les traces d’IronPython qui est une implémentation de Python pour .NET supportée par M$ et qui est à un doigt de sortir sa version 1 (à l’heure où nous mettons sous presse 1.0 RC1).

Wilco Bauer a l’air de travailler assez vite et d’être impliqué, ce qui peut déboucher prochainement sur une version utilisable.

Microsoft s’amuse et tente de pallier à un inconvénient éternel, mais relatif, des SGBD : l’intégration dans le code client, en chaînes de caractères, du code d’interrogation de la base de donées, c’est-à-dire du SQL.
LINQ permet d’intégrer en .NET des requêtes de données qui sont intégrées dans le langage lui-même (C# ou VB), donc parsables, complétables par intellisense, etc. en se basant sur de nouvelles fonctionnalités des langages (parfois très nouvelles).

Certes. Cela oblige néanmoins, quand on attaque des bases externes à en intégrer les métadonnées dans des structures du langages (des classes, des tableaux), par exemple en utilisant du mapping relationnel-objet, afin de pouvoir parser les requêtes et de pouvoir correctement les traduire en SQL pour les envoyer au serveur. Ensuite se posent certainement des problèmes de performances, de couplage fort entre deux versions de métadonnées… La bonne manière jusqu’à maintenant, et encore pour un certain temps, de gérer ce problème, est d’encapsuler les requêtes sur le serveur dans des procédures stockées, et de les appeler depuis le client, à la rigueur avec des objets stored procedures qui reconnaissent les paramètres comme une collection d’objets.

L’initiative LINQ ressemble à une volonté de retrouver la souplesse de requêtage obtenue avec des applications de gestion de bases de données locales (type ISAM) comme Paradox, Foxpro ou Access, avec une intégration du langage procédural et de l’accès aux données. SQL Server 2005 tente l’action inverse : faire venir le langage procédural dans le moteur du SGBD. Avec toutefois, simplement une reproduction du problème, puisque même dans une procédure stockée en langage MSIL, tout accès aux données se fait à travers une connexion ADO et l’envoi de nos bonnes vieilles requêtes SQL.

Si vous voulez jouer avec ce qui pour l’instant ressemble à un joli gadget :
download de LINQ

… est en effet bien compromis. Quelques bruits de couloirs des vendeurs de chez Borland :
http://www.lemanix.com/nickblog/PermaLink,guid,c0ee055c-5c2e-44b4-ba7f-116f40d9d13b.aspx

En résumé, les vendeurs Borland ne reçoivent même plus de commission sur les ventes de Delphi, donc ils n’essaient même plus de le vendre. La proportion de grandes sociétés qui utilisent Delphi est trop faible pour que Borland continue à investir dans Delphi.

Merci pour les gens normaux.

Et une annonce de Borland :
http://blogs.borland.com/davidi/archive/2006/02/08/23013.aspx

Pour mon grand malheur, je dois travailler dans une base Ms Access. Voici quelques infos pratiques qe j’ai eu l’occasion de découvrir en essayant de faire du DDL dans Access.

La plupart de la syntaxe SQL ANSI est supportée à l’intérieur d’Access via le DAO. Un CurrentDb().Execute "SQL String" fonctionne correctement, donc la plupart des syntaxes utilisées par exemple dans SQL Server pour faire du DDL sont exportables telles quelles. Par exemple, un

strSQL = "CREATE INDEX MyIdx ON Table (Column)"
CurrentDb().Execute strSQL

sera parfaitement accepté. On peut créer la même chose via une syntaxe DAO, en utilisant la bibliothèque d’objets, qqch du genre Currentdb().CreateIndex

Un problème : la génération de clés étrangères. Essayé cette syntaxe :

strSQL = "ALTER TABLE Foreigntable ADD CONSTRAINT fk_Foreigntable_references_PrimaryTable FOREIGN KEY (Id) REFERENCES PrimaryTable (RefSejour) ON DELETE CASCADE, ON UPDATE CASCADE"
CurrentDb().Execute strSQL

sauf que, apparemment, le DAO ne supporte pas la syntaxe ON DELETE CASCADE…, dont je ne sais pas exactement si elle est ANSI92, mais elle me semble l’être. Bien, essayé de passer en ADO.

J’ai cru comprendre qu’en Access 2000, CurrentProject.Connection référence la connexion ADO liée au projet actuel, ce qui est assez pratique. Mais l’essai avec un

CurrentProject.Connection.Execute strSQL

ne donne pas beaucoup plus de succès. Quelqu’un dans un newsgroup suggère d’ajouter une option pour utiliser du SQL étendu avec ADO (??), mais je ne me suis pas amusé à tester tout ça. Passé à la syntaxe DAO suivante :

    Dim rel As DAO.Relation

    Set rel = CurrentDb().CreateRelation("fk_Foreigntable_references_PrimaryTable", _
         "PrimaryTable", "ForeignTable", dbRelationUpdateCascade + dbRelationDeleteCascade)

    rel.Fields.Append rel.CreateField("Id_OnPrimaryTable")
    rel.Fields!RefSejour.ForeignName = "Id_OnForeignTable"
    CurrentDb().Relations.Append rel