La Voie Du Code

Je suis content d’avoir réussi à mettre en oeuvre un lien ODBC vers SQL Server à partir d’ORACLE, cela va me faire gagner des heures voire des jours de boulot! En effet j’ai besoin de comparer une base de données ORACLE et une base de données SQL Server en utilisant de préférence du SQL. Ne connaissant pas Oracle Heterogeneous Services, j’avais d’abord mis en place une procédure compliquée d’extraction et de chargement de base de SQL Server vers ORACLE. La base de données ne fait que 300 Mo mais vu qu’une table tape dans le million de lignes, le chargement prend facilement de 20 à 30 minutes! A raison de 10 fois par jour, ce n’est pas humain. J’ai donc googlé "sql server oracle database link" et je suis tombé directement sur la doc ORACLE et d’autres trucs. Si j’avais su j’aurais googlé directement "hsodbc"!

Les explications trouvées dans ces différentes sources sont toutes assez claires. Il y a juste un piège dans lequel il ne faut pas tomber… Quand vous avez une config de développement ultra-simple sous Windows comme moi avec un seul listener, la seule chose à faire c’est d’ajouter dans listener.ora une entrée SID_DESC à l’unique SID_LIST existant. Ce n’est absolument pas la peine de créer un nouveau listener.

Les nerds se contentent de peu me direz-vous, mais c’est grisant de pouvoir taper:

   SELECT * FROM emp@sql2k A, emp B WHERE A.emp_id = B.emp_id

Décidément je commence a détester sérieusement la gestion des namespaces par Delphi.net. Dans le cas du paramétrage du remoting .net à travers par exemple, on peut déclarer des types distants dans un fichier de configuration XML. Cela se fait à travers des tags <activated> ou <wellknown> pour lesquels on donne dans l’attribut “type” le nom de la classe et de l’assembly. Ensuite un appel à RemotingConfiguration.Configure() suffit pour recenser le type.

Ainsi en Delphi.net lorsque votre classe TType est rangée dans l’unité Toto.MonModule et l’assembly Toto, voici ce qu’il faut écrire:

    <activated> type="MonUnité.TType, Toto" />

Il ne faut surtout pas inclure le nom de l’assembly dans le nom du type comme on serait tente de le faire si on suivait la logique pronée par Borland! Comme dans:

    <activated> type="Toto.MonUnité.TType, Toto" />

Ce niveau supplémentaire qu’est l’unité sent vraiment la verrue. Pour C# ou VB.net ou Chrome, cette notion d’unité n’existe pas et on aurait juste écrit:

    <activated> type="Toto.TType, Toto" />

Pour découvrir Delphi.net et avoir une vue d’ensemble d’ASP.net, j’ai porté le starter kit pour ASP.net appelé TimeTracker vers Delphi.net. Les starter kits sont des noyaux d’application créés par Microsoft pour donner un aperçu des possibilités d’ASP.net. Vous pouvez télécharger les versions originales pour le framework v1.1 sur le site www.asp.net.

Le résultat de mon portage est accessible ici.

Mes conclusions:

• .Net et ASP.Net, c’est cool.
• C# c’est pas mal du tout.
• Delphi.net ce n’est pas génial.

Pas grand chose à dire si ce n’est que j’ai réussi à reproduire dans Delphi.net 100% des fonctionnalités implémentées en C#, mais j’ai bien senti que le coeur n’y était pas du côté Delphien.

La mise en oeuvre des namespaces par exemple est réellement calamiteuse. En gros, dans Delphi.net un namespace n’est rien d’autre qu’un nom d’unité avec des points dedans! Par exemple vous définissez un type TToto dans une unité Toto dans le namespace VoieDuCode.Machin. Eh bien, pour pouvoir référencer ce type dans une autre unité il n’est pas possible d’écrire:

    uses VoieDuCode.Machin ...

Il faut absolument faire référence à l’unité:

    uses VoieDuCode.Machin.Toto ...

A travers ce genre de choses, on sent bien que .Net n’est pas un citoyen de première classe dans le monde Delphi…

Notez que l’Object Pascal concurrent pour .Net appelé Chrome propose un mécanisme de gestion des namespaces rigoureusement équivalent à celui de C#. Mais ceci sera le sujet d’un autre post…

Si j’avais le choix, je n’utiliserais pas Delphi comme langage dans le monde .Net. C# ou Chrome sont bien plus élégants et adaptés. Pour Win32 cependant, Delphi reste la meilleure solution, surtout que Borland propose un chemin de migration de Win32 a .Net à travers VCL.net.