LINQ

[adidas]

À tous les programmeurs de .NET, je suis en train de mettre au point un extender de LINQ pour accéder aux interfaces de Acomba. Le projet est basé sur LinqExtender, et le SDK de Acomba.

j'ai eu des résultats assez satisfaisants. Pour le moment, le projet ne comporte que 2 interfaces, mais l'ajout d'autres fiches est relativement simple, donc je devrais pouvoir en ajouter très bientôt.

Si vous êtes intéressés à participer au développement, envoyez-moi un message privé ou par le biais de cette discussion.

Merci.

Adresse du projet: http://linqtoacomba.codeplex.com

[Lartis]

Salut Adidas,

Peux-tu me dire un peu plus ce que ça fait exactement? C'est en VisualStudio .NET, est-ce que ça peut être appelé en C#.NET? VB.NET? ASP.NET?

Ça semble être un projet compilé, donc si on veut ajouter des interfaces, on doit passer par toi et te demander de le faire?

Merci!

[adidas]

Linq est une technologie de Microsoft qui est apparue avec la version 3.0 de Framework. C'est donc utilisable dans tous les langages .NET (C#, VB, ASP.NET). Ca permet de simplifier le code lors que vient le temps de faire des requêtes. On peut les exprimer avec un langage de style SQL. Ainsi pour chercher les clients qui sont dans le 514, on pourrait écrire:

var Clients514 = from c in clients
where c.tel.startWith("514")
select c

tout le code de recherche, les itérations, etc... sont implémentées dans le Linq Extender.

J'attends présentement de voir vers quoi se dirigera Acomba dans la prchaine version avant de mettre beaucoup d'efforts dans le projet, car si ils vont vers une plateforme de base de données, peut-être ces fonctions existeront-elles déjà. Dans le cas contraire, j'aimerais pouvoir faire progresser le projet dans un avenir rapproché.

Merci.

[Lartis]

Salut Adidas,

Je peux te confirmer qu'une nouvelle version d'Acomba est prévu dans environ 2 à 3 ans.

Cette nouvelle architecture utilisera SQL Server Express, et supportera SQL Server Standard et PostgreSQL pour les BD trop volumineuse pour la version SQL Server Express.

Le SDK actuel sera très fort probablement non fonctionnel avec la nouvelle version, et sera remplacé par un nouveau SDK complètement différent.

Le LINK pourra sans doute être adapté pour fonctionner quand même, mais une bonne partie du code sera à refaire. Donc, c'est une très bonne idée d'attendre la nouvelle architecture avant de trop mettre de temps la dessus. Si je comprend bien par contre, les programmes UTILISANT le link fonctionneront de façon transparente une fois le LINK adapté à la nouvelle version.

A+

[Jeremie]

Ouiap, de se que j'ai compris de la conférence que j'ai assisté.
La prochaine version d'Acomba sera faites avec Visual Studio 2010, donc il y a fort à parier que le SDK sera une sorte de Linq Extender.

Parce que le conférencier à parlé d'utilisé 100% des nouvelles technologie .net 3.5 alors ....
Ce qui avait fait rager une ou deux personnes qui devront eux aussi réécrire leur logiciel.

Hum ... avec mon .Net 1.1, je me sent bien en retard ... snif !

[PlanteG]

Acomba écrit avec Visual Studio 2010 . Actuellement, Acomba est écrit en Delphi. De ce que je comprends, Delphi peut faire du .Net - sous soute réserve, je ne suis pas un fan ou connaisseur de Delphi. Fortune 1000 était écrit en Turbo Pascal, la suite naturelle était Delphi. Si la prochaine version d'Acomba est écrite dans un langage de .Net 2010, ça va être un GROS changement.

Vous parlez d'une conférence, est-il possible d'avoir des détails sur sa nature et quelle entreprise la donnait ?

[Jeremie]

Heu !

C'est qu'elle date un peux, elle avait été donnée dans une salle à Laval, QC et je crois qu'on était 20 dans la salle. C'était le directeur technique avec un type de l'équipe de Dev qui fessait la présentation. Avec d'autres personnes de chez Fortsum.

Nous avions été invité à cause du Système de gestion que je suis en train de concevoir et oui.
Ils ont parlé de très gros changement, en faites ... à se stade ce n'est plus des changement, mais la réécriture total d'Acomba.

Les diapositives qui fut présenté montre que la nouvelle mouture d'Acomba va avoir une interface similaire à Office 2010.

Je me souviens clairement que le présentateur avais fièrement annoncé que c'était le premier gros projet fait avec VS 2010 au Québec et que Microsoft suivais le projet.

Donc, avant d'attaquer un gros module de se type vaudrait mieux attendre selon moi.

[PlanteG]

Les diapositives qui fut présenté montre que la nouvelle mouture d'Acomba va avoir une interface similaire à Office 2010.

Oh là là ! Il y a eu un choc culturel quand on est passé de Fortune 1000 à Acomba, j'ai l'impression qu'on va en avoir un autre .

Une standardisation de l'interface, ne ferait pas de tort. Je penses au fait que:

• dans les dialogues, Enter ne correspond pas au bouton par défaut parfois
  
• pas de sablier quand on doit attendre *ouch* c'est pourtant standard
  

[Jeremie]

Oui, va y avaoir pas mal de monde qui vont grincer des dents, mais je crois qu'il n'ont plus le choix.
Des technologie qui date des années 90, dois pas être joyeux à maintenir.

[Lartis]

Bonjour,

J'ai moi aussi participé à cette présentation.

C'était au sujet de la reprogrammation complète d'Acomba, en VisualStudio 2010 et avec des données sur SQL Server Express (ou PostGreSQL si le volume est trop gros pour SQL Server Express).

Il était question d'un projet d'environ 3 ans, donc ce n'est pas pour tout de suite, mais ce n'est pas non plus si loin. Il y a BEAUCOUP de changements prévus. Les programmes qui utilisent le SDK seront à adapter, c'est certain. Il est probable que ceux qui utilisent le driver ODBC seront aussi à adapter. Il existera encore un driver ODBC (celui de SQL Server), mais son utilisation sera certainement très différente.

L'interface sera drastiquement amélioré, et le fait de passer par une base de données relationnelle augmentera sans doute beaucoup la performance.

Une fois que ça sera prêt, c'est prévu comme un upgrade inclu dans le plan de service. Mais ceux qui ont des projets utilisant le SDK ou l'ODBC pourront rester à l'ancienne version pendant un certain temps (?) pour pouvoir adapter leurs projets.

Certains vont grincher des dents, comme le dit Jeremie, mais d'autres diront "Il était temps!". Car c'est nettement une amélioration. Mais pour toutes les améliorations, il y a toujours quand même de la résistance au changement...

[hench]

Qui dit Gros changement dit nouvelles possibilités de développement ! yay !
Ça va devenir puissant tout ce qui sera possible de faire !!



@adidas : Donc tu développes une coquille autour des fonctionnalités du SDK pour faciliter l'utilisation, c'est intéressant ..... serait-il d'en faire une DLL et de l'appeler a partir d'autres langages ?

[PlanteG]

Qui dit Gros changement dit nouvelles possibilités de développement ! yay !
Ça va devenir puissant tout ce qui sera possible de faire !!

Effectivement, avec un véritable SGBD, on va changer de ligue. Loin de moi l'idée de vouloir jouer les oiseaux de malheur, mais malgré son actuel SGBD archaïque, Acomba a un avantage majeur: impossible pour monsieur/madame tout le monde de gosser dans les données. J'ai déjà fait du support pour SAP Business One, le produit d'entrée de gamme de SAP qui stocke ses données en MS SQL. C'est facile de consulter les données directement avec les outils de MS SQL... et les modifier et effacer et foutre le bordel. Idem avec les procédures stockées. Ça apporte des problèmes au niveau du support. Toutefois je dois dire que l'architecture de la bd de SAP est pour le moins déficiente: en effet aucune relation n'est créée, et donc impossible de faire respecter les relations de-facto. Par exemple, on a 10 factures sur le dos d'un client et la fiche du client est détruite. À ce moment SAP capote.

J'espère de tout cœur que Fortsum trouvera un moyen de blinder le plus possible son implantation. Va falloir être patient, car le nouvel Acomba ne sera pas là avant un paquet de dodos .

[hench]

Ou bien une entreprise empêche ses employés de jouer dans ces dits outils SQL

Ah , donc il n'y a aucune contraintes d'intégrité dans SAP ?

[PlanteG]

Non, l'intégrité est appliquée dans les règles par programmation. J'ai demandé au support de SAP pourquoi les relations et règles d'intégrité n'étaient pas utilisées. Réponse: ce n'est pas performant . Et moi qui croyait qu'un avantage d'un SGBD, c'était la performance des fonctions intégérées. Il semble que j'étais dans le champ .

[Lartis]

Bonjour,

Il était très clair lors de la présentation que, même s'il s'agirait de SQL Serveur, le login/pw ne serait pas donné. Donc impossible de "jouer" dans les données. Il faudra passer par un layer qui forcera le respect de l'intégrité des données et empêchera de modifier ce qui ne peut pas être modifié par Acomba. Par exemple, c'est certain qu'il sera impossible d'effacer une facture!

Comment il vont faire ça? Je ne sais pas. Mais ça implique nécessairement de ne pas utiliser simplement le driver ODBC standard de SQL Server.

[PlanteG]

Lartis,

excellente nouvelle que celle-là . Le développeur de Fortune 1000/Acomba a toujours eu cette philosophie, à savoir « on ne joue pas avec les données comptables » et qui est strict sur les règles. Je connais un logiciel simple où l'on peut modifier une facture déjà sauvegardée - elle est contrepassée par dessous mais la version modifiée porte la même numéro - et qui permet de modifier les écritures n'importe quand. Bien sûr ça dépend des goûts de chacun, mais perso j'aime bien la rectitude d'Acomba.

Dans le cas de SAP, on refuse de donner du support si l'on se rend compte que quelqu'un a joué avec les données. Et il est fréquent que l'on doive expédier une bd à SAP pour investigation - imaginez un peu la taille des fichiers, même compressés !

[Carles]

YEAH!!!!! il était temps en effet!
Avec postgresql ça serait génial... enfin possible de coder en Linux.
Seulement cela nous amène passer 2012... ça craint héhéhé

[Jeremie]

Dépend, si tu es en SQLExpress, il ni a pas d'outil de gestion intégré ni rien.

Chez un client, il ont un logiciel comptable disparue il ya bel lurette, mais qui lui fonctionne avec SQLExpress ou Sqlserver.

Il y a juste trois personnes sont capable de jouer dans les données.

Moi, mon patron et notre administrateur.

Mon système de gestion que j'ai développé est lui aussi avec SQLExpress et pour jouer dans les tables faut passer par mon laptop ou par celui de mon patron.

Pour se qui est des mot de passe, suffit d'avoir une autre base de donnée pour avoir accès.

Pour brancher à une autre BD, j'ai juste eu à intégrer l'utilisateur SQL de mon logiciel pour que ça passe.

Donc, selon moi y devrait y avoir un moyen simple pour un programmeur de se bloguer directement dans la BD Acomba.

[Contenu sponsorisé]