locked
10 ans de foxpro, j'ai besoin de conseils sur le passage à SQL Express RRS feed

  • Question

  • Bonjour,

    Je développe depuis 10 ans des applications en Visual Foxpro 8 et 9. Et dans le cadre de mon nouveau travail je veux en profiter pour passer toute une application en .NET. Sachant que cette application est actuellement 'mal' développée en WinDEV je veux tout reprendre depuis le début.

    Je lis depuis plusieurs semaines des quantités de documentations concernant les interactions entre C# et SQL Express 2005 mais il y a certains points qui me turlupinent et j'aurais besoin d'un conseil vraiment personnalisé.

    Quand je développais en foxpro, chaque table était indépendante et enregistrée dans des fichiers DBF sur le disque. Lorsque je livrais une nouvelle version, un programme de modèle physique analysait les structures et mettait à jour les fichiers DBF (ajout d'un champ, changement du type d'un champ).

    En SQL je peux créer mes tables via l'interface utilisateur et y accéder via C# .NET sans trop de problème. Mais avant de développer toutes mes classes de bases j'aimerais être sûr de partir dans la bonne direction.

    Cette application sera installée sur un server 2003. Je vais donc définir une structure de base en fonction des besoins actuels de l'entreprise en local, sur mon poste de développement. Mais il est évident qu'à l'avenir les données et les tables vont évoluer et je ne comprends vraiment pas comment tout cela est géré dans SQL.

    Dois je prévoir le développement d'un système comme je faisais en foxpro ? C'est à dire que mon programme connaît toutes les base de données (dans une sorte de métatable) et s'occupe lorsque j'installe une nouvelle version de créer les tables manquantes avec CREATE TABLE ou de modifier les structures avec ALTER TABLE. Donc un outil qui contrôlerait la totalité de la base de données pour être sûr que le programme et la base de données soit toujours synchronisées.

    Où ya t'il quelque chose de déjà intégré en SQL pour faire cela. J'aimerais pouvoir commencer à créer ma structure relationnelle sans me trouver bloquer dans 3 mois parce que je dois faire de la maintenance manuelle sur les tables du serveur.

    J'espère avoir été assez clair. Tous vos conseils sont les bienvenus merci.

    Florent
    mercredi 24 février 2010 16:04

Réponses

  • Bonsoir Florent,

    pour ma part je n'ai jamais vu d'application utilisant le type de scénario que tu décris. En général comme l'a dit Thomas, les modifications sur la base de données sont effectuées par des scripts qui sont passées sur la base de données lors de la livraison d'une nouvelle version de l'application.

    Par ailleurs j'imagine plusieurs difficultés dans le type de scénario que tu décris :
    - la métatable doit être à jour chez le client pour que la comparaison puisse s'effectuer. Cela implique donc qu'un script soit passé sur la base avant d'utiliser l'application un peu comme dans le cas ou l'on met à jour directement la structure.
    - pour pouvoir modifier la structure d'une table cela nécessite de disposer de privilèges importants sur la base de données. En général on évite de donner ce genre de privilège à l'application pour des raisons de sécurité.
    - certains scénario de modifications de table peuvent nécessiter différentes opérations. Par exemple devoir mettre une valeur par défaut dans le cas ou une colonne n'accepte plus la valeur null.
    - le surcout éventuel en terme de performance ...
    - dans sqlserver toutes ces infos sont stockées dans la base master...quelque part tes tables de metadata seront en quelque sorte un clone de cette base...

    Néanmoins si tu as pu le faire en foxpro je ne vois pas de raison que tu ne puisses pas essayé avec sql server et si tu mets un tel système en place il sera intéressant d'avoir des retours de ta part.

    Cordialement



    • Marqué comme réponse Alex Petrescu mercredi 3 mars 2010 15:17
    mercredi 24 février 2010 18:39
  • Bonjour,

    Comme vous je suis éditeur.

    Pour bien faire :
    La mise à jour de la base de données doit être fait par un logiciel à part et par un administrateur (le plus souvent c'est le programme d'installation de la mise à jour du produit associé qui le fait).
    Ce n'est pas votre programme ni vos utilisateurs lambda qui doivent le faire !

    Oubliez le concept de méta données... Un avantage des scripts est de faire vous même les changements de structures et plus-tard les "moulinettes" correctives...
    Normalement, vous devez gérer des versions de base de données en même temps que votre application.
    La version 1.0.0 correspond au script de mise en place de la base de données initialise.
    A chaque version, correspond un script de mise à jour. (Par exemple, 1.0.1, 1.0.2 et 1.0.5. On suppose que la v1.0.3 et 1.0.4 ne nécessite pas de mise à jour de base de données).
    Lorsque vous installez pour première fois une base de données v1.0.5 chez un client, vous devez jouez les scripts : 1.0.0 -> 1.0.1 -> 1.0.2 et 1.0.5.
    Si vous mettez à jour une base de données v1.0.1 vers 1.0.5, alors jouez les scripts 1.0.2 et 1.0.5.
    Vous ne devez en aucun faire un script spécifique pour un client ou pour le passage d'une version à une version plus importante.

    Un produit qui peut vous aidez dans cette démarche (c'est le cas pour moi, mon DBA et mes confrères : L'édition Visual Studio Team System for DataBase Professional). Le tout couplé bien évidement avec un TFS (ou un SVN).

    Cordialement
    Gilles TOURREAU - MVP C# - Architecte .NET/Consultant/Formateur
    • Marqué comme réponse Alex Petrescu mercredi 3 mars 2010 15:17
    dimanche 28 février 2010 22:13
    Modérateur
  • Bonjour,

    je réponds (très) tardivement à ce message, que je découvre en même temps que ce forum.

    Je comprends bien ta problématique, développant en fox depuis 1984... et consacrant l'essentiel de mon activité depuis 5 ans à la migration vers SQL server et .Net.

    Pour ce besoin spécifique de mise à jour des structures de données, j'utilise Database Deployement Toolkit (DDT) de Microfour StrataFrame, qui me donne entière satisfaction (je ne vends rien, je suis seulement un utilisateur hyper-content de ce produit).
    En gros, avec leur DDT, tu modélises tes modifs en local (ajouts et modifs de tables, vues,  index, SP, triggers, fonctions, tout ce que tu peux imaginer...), tu génères ensuite avec un assistant un fichier package de déploiement (un xml crypté compressé), et tu utilises enfin leur classe DataBaseMigrator (C# ou VB .net au choix) pour intégrer tout ça à ton loader d'appli chez tes clients.

    J'ai écrit quelques contribs sur StrataFrame sur le site de l'association AtoutFox (Communauté Francophone des Professionnels FoxPro), tu les trouveras ici

    Espérant que ça t'aidera un peu

    Michel

    vendredi 28 mai 2010 12:10

Toutes les réponses

  • Bonjour Florent,

    Il existe peut-être des systèmes comme le tien qui à partir de meta données regardent si la base est bien comme il faut, et la mettent à jour dans le cas contraire.
    Neanmoins, nous concernant, lorsqu'on fait une modification de la base de données, on le fait à la main sur le serveur lors du déploiement d'une nouvelle version.

    Cordialement,

    Thomas
    Thomas Aimonetti - C# - Sharplog Engineering - http://www.sharplog.fr
    mercredi 24 février 2010 16:37
  • Bonjour Thomas, merci pour ta réponse.

    Mais comment fais-tu si ton application doit être déployée chez 10'000 clients l'utilisant au quotidien ?


    SQL n'inclut donc aucune fonction de mise à jour de BDD en se basant sur un modèle...?

    Merci :-]

    Je vais donc devoir développer entièrement ce système je pense.
    mercredi 24 février 2010 16:56
  • Bonjour Florent,

    Alors attention, j'ai peut-être, surement d'ailleurs, mal compris ta question.

    Si tu embarques une base de données sur ton application cliente, dans ce cas, il te faut t'intéresser à SQL Compact Edition:
    http://www.microsoft.com/Sqlserver/2005/en/us/compact.aspx

    Lorsque tu déploieras une nouvelle version, tu embarqueras la nouvelle verison de la base de données, et donc l'ancienne sera écrasée.

    Moi je parlais dans le cas où tu as un serveur de base de données pour X applications qui tapent dedans.

    Cordialement,

    Thomas
    Thomas Aimonetti - C# - Sharplog Engineering - http://www.sharplog.fr
    mercredi 24 février 2010 17:02
  • Non ce n'est pas tout à fait ça. Je prends un exemple ultra smiple

    Mon appli travaille avec une table adresses :
    Nom (text), Prénom (text) et NPA (integer).

    Après 2 mois de saisie par les utilisateurs je dois

    > Ajouter un champ numéro de téléphone
    > Modifier le type du champ NPA en text.



    En foxpro, j'avais créé une interface me permettant de saisir toutes ces informations dans des tables DBF (une qui contient les noms des tables, une autre avec les noms des champs, une relation entre les deux).

    Lorsqu'on mon application foxpro ouvre la table adresse. Il compare la structure de la table physique (chez le client) et la métatable et voit qu'il y a des différences. Dans ce cas :
    > il copie toute la table dans un fichier temporaire
    > il supprime la table et recréé la nouvelle structure
    > il importe les données de la table temporaire
    > il essaie si possible de ne pas perdre de données lors de la conversion de champ

    Avec cette fonctionnalité je n'avais qu'à saisir mes modifications dans mon interface et lors de l'installation de mise à jour chez mes clients les tables étaient automatiquement adaptées à la structure nécessaire au fonctionnement de l'application.

    Mais comme tu en parles dans ta première réponse, je pense que je vais devoir mettre en place le même type de système en SQL. Il doit bien exister des exemples ou des dév. qui se sont confrontés à ce problème.

    Ou alors peut-être devrais je conserver mon système foxpro et faire de l'ODBC mais les tables DBF étant limitée à 2GO je risque un jour d'être ennuyé.

    J'espère m'être expliqué un peu mieux...-)







    mercredi 24 février 2010 18:06
  • Bonsoir Florent,

    pour ma part je n'ai jamais vu d'application utilisant le type de scénario que tu décris. En général comme l'a dit Thomas, les modifications sur la base de données sont effectuées par des scripts qui sont passées sur la base de données lors de la livraison d'une nouvelle version de l'application.

    Par ailleurs j'imagine plusieurs difficultés dans le type de scénario que tu décris :
    - la métatable doit être à jour chez le client pour que la comparaison puisse s'effectuer. Cela implique donc qu'un script soit passé sur la base avant d'utiliser l'application un peu comme dans le cas ou l'on met à jour directement la structure.
    - pour pouvoir modifier la structure d'une table cela nécessite de disposer de privilèges importants sur la base de données. En général on évite de donner ce genre de privilège à l'application pour des raisons de sécurité.
    - certains scénario de modifications de table peuvent nécessiter différentes opérations. Par exemple devoir mettre une valeur par défaut dans le cas ou une colonne n'accepte plus la valeur null.
    - le surcout éventuel en terme de performance ...
    - dans sqlserver toutes ces infos sont stockées dans la base master...quelque part tes tables de metadata seront en quelque sorte un clone de cette base...

    Néanmoins si tu as pu le faire en foxpro je ne vois pas de raison que tu ne puisses pas essayé avec sql server et si tu mets un tel système en place il sera intéressant d'avoir des retours de ta part.

    Cordialement



    • Marqué comme réponse Alex Petrescu mercredi 3 mars 2010 15:17
    mercredi 24 février 2010 18:39
  • - la métatable doit être à jour chez le client pour que la comparaison puisse s'effectuer. Cela implique donc qu'un script soit passé sur la base avant d'utiliser l'application un peu comme dans le cas ou l'on met à jour directement la structure.

    Si la métatable est un fichier XML livré dans le package de l'application il contiendra toujours la dernière version de la BDD...
    Par contre c'est vrai qu'il faut des droits pour modifier les structures.

    Dans mon cas précis ça n'est pas trop compliqué car l'application est utilisée par une seule entreprise (celle pour laquelle je travaille). Mais l'idée est de pouvoir faire une application déployable et utilisable dans d'autres entreprises (comme mon application foxpro utilisée par plus de 10'000 personnes).


    J'ai testé il y a une année des solutions PHP pour blog/forum qui fonctionnent en MySQL. Ces outils en général nous demandent l'accès à la BDD et crééent automatiquement toutes les tables nécessaires. Comment font-ils pour maintenir ces tables par exemple si une nouvelle table est nécessaire pour l'ajout de fonctionnalité...

    Car maintenir tout ça à la main peut vite venir un travail de fou il me semble...et on ne peut pas décider au début d'une application.

    Je vais continuer de chercher dans mon idée de 'Modèle physique interne' ...

    Merci pour vos éclaircissements.







    mercredi 24 février 2010 19:35
  • Bonjour,

    Comme vous je suis éditeur.

    Pour bien faire :
    La mise à jour de la base de données doit être fait par un logiciel à part et par un administrateur (le plus souvent c'est le programme d'installation de la mise à jour du produit associé qui le fait).
    Ce n'est pas votre programme ni vos utilisateurs lambda qui doivent le faire !

    Oubliez le concept de méta données... Un avantage des scripts est de faire vous même les changements de structures et plus-tard les "moulinettes" correctives...
    Normalement, vous devez gérer des versions de base de données en même temps que votre application.
    La version 1.0.0 correspond au script de mise en place de la base de données initialise.
    A chaque version, correspond un script de mise à jour. (Par exemple, 1.0.1, 1.0.2 et 1.0.5. On suppose que la v1.0.3 et 1.0.4 ne nécessite pas de mise à jour de base de données).
    Lorsque vous installez pour première fois une base de données v1.0.5 chez un client, vous devez jouez les scripts : 1.0.0 -> 1.0.1 -> 1.0.2 et 1.0.5.
    Si vous mettez à jour une base de données v1.0.1 vers 1.0.5, alors jouez les scripts 1.0.2 et 1.0.5.
    Vous ne devez en aucun faire un script spécifique pour un client ou pour le passage d'une version à une version plus importante.

    Un produit qui peut vous aidez dans cette démarche (c'est le cas pour moi, mon DBA et mes confrères : L'édition Visual Studio Team System for DataBase Professional). Le tout couplé bien évidement avec un TFS (ou un SVN).

    Cordialement
    Gilles TOURREAU - MVP C# - Architecte .NET/Consultant/Formateur
    • Marqué comme réponse Alex Petrescu mercredi 3 mars 2010 15:17
    dimanche 28 février 2010 22:13
    Modérateur
  • Bonjour,

     

    Merci à tous pour les réponses. Florent, est-ce que les informations présentées ici vous sont utiles ?

     

    Cordialement,

    Alex


    Alex Petrescu - MSFT
    mardi 2 mars 2010 14:34
  • Bonjour,
    Oui merci pour vos réponses.

    Je comprends la notion de scripts...Il est vrai que pour une application installée sur un seule serveur c'est un moyen plutôt clair d'avoir une version de BDD liée à une version d'application et ça apporte une sécurité quant aux modifications effectuées...

    Toutefois...Vous parlez toujours d'installation CHEZ le client...
    Je ne vois vraiment pas comment faire tourner tout ça dans une application par exemple une application de comptabilité que vous désirez distribuer à des milliers de clients avec la possibilité de télécharger des mises à jour par patch successifs. Je ne vais pas m'introduire chez mes milliers de clients pour lancer mes scripts de mise à jour de base de données...
    Peut-être ai je mal compris et vous voulez me dire que c'est l'administrateur informatique de l'entreprise qui installera ce soft et exécutera les routines de mise à jour des BDD. Dans ce cas ça me paraît plausible mais somme toute assez rébarbatif si je veux livrer une nouvelle version avec des nouvelles fonctionnalités chaque mois.

    Je lance un peu le débat mais j'ai du malgré tout me retourner vers vFox car j'ai une bonne maîtrise du fonctionnement et des BDD en fox alors qu'en .NET je m'en sors mais je met des jours pour faire des choses que je fais en 10 minutes et malheureusement ma nouvelle entreprise n'a plus le temps d'attendre que je me forme...mais ça c'est mon problème :-] C'est dommage parce que je trouve l'orienté objet de .NET passionnant et le codage en C# vraiment génial...Peut-être y reviendrais-je pour des projets moins conséquents...

    Merci pour votre aide et bons développements.
    jeudi 4 mars 2010 20:44
  • Bonjour Florent,

     

    J'ai eu exactement la meme problematique que toi, avec quelleque probleme suplementaire, les base de donnée des clients peuvent varier pour la meme application,

    par exemple tu develope ta base sur access, et tes client on Sqlserveur ou MySql.

    perso j'ai developper un générateur de code qui fai la mise a jour de la base de donnée, il integre a l'executable la structure de la base de donnée qui ta servie au developpement, ensuite tu as juste a lancer quelleque fonction pour que chez le client la base de donnée soit mise a jour automatiquement.

    le logiciel ce trouve ici. www.database2code.com, la documentation est tres ancienne, et le code generer est pour VB.Net.

    je suis entrain de developper un nouveau moteur de scanne et d'integration de la structure, je pense qu'il sera dispo d'ici a septembre, il sera plus complet et sera compatible avec plus de type de donnée.

    Si sa peut t'aidé

    a++

    seb

     

    mardi 30 mars 2010 13:01
  • Bonjour,

    je réponds (très) tardivement à ce message, que je découvre en même temps que ce forum.

    Je comprends bien ta problématique, développant en fox depuis 1984... et consacrant l'essentiel de mon activité depuis 5 ans à la migration vers SQL server et .Net.

    Pour ce besoin spécifique de mise à jour des structures de données, j'utilise Database Deployement Toolkit (DDT) de Microfour StrataFrame, qui me donne entière satisfaction (je ne vends rien, je suis seulement un utilisateur hyper-content de ce produit).
    En gros, avec leur DDT, tu modélises tes modifs en local (ajouts et modifs de tables, vues,  index, SP, triggers, fonctions, tout ce que tu peux imaginer...), tu génères ensuite avec un assistant un fichier package de déploiement (un xml crypté compressé), et tu utilises enfin leur classe DataBaseMigrator (C# ou VB .net au choix) pour intégrer tout ça à ton loader d'appli chez tes clients.

    J'ai écrit quelques contribs sur StrataFrame sur le site de l'association AtoutFox (Communauté Francophone des Professionnels FoxPro), tu les trouveras ici

    Espérant que ça t'aidera un peu

    Michel

    vendredi 28 mai 2010 12:10
  • Bonjour,

    Toutefois...Vous parlez toujours d'installation CHEZ le client...
    Je ne vois vraiment pas comment faire tourner tout ça dans une application par exemple une application de comptabilité que vous désirez distribuer à des milliers de clients avec la possibilité de télécharger des mises à jour par patch successifs. Je ne vais pas m'introduire chez mes milliers de clients pour lancer mes scripts de mise à jour de base de données...
    Peut-être ai je mal compris et vous voulez me dire que c'est l'administrateur informatique de l'entreprise qui installera ce soft et exécutera les routines de mise à jour des BDD. Dans ce cas ça me paraît plausible mais somme toute assez rébarbatif si je veux livrer une nouvelle version avec des nouvelles fonctionnalités chaque mois.

    Le script de mise à jour peut-être fait par un administrateur ou en lançant une ligne de commande (le tout dans une belle application C#). J'ai travaillé avec un éditeur qui gérait 300 clients (structure de la BD identique) et cela toujours passé sans problème (le script de mise à jour était lancé via une application C# au moment de la mise à jour de l'application sur le serveur)... La méthodologie script de modification est beaucoup plus fine surtout au niveau des "moulinettes" mais nécessite un minimum d'organisation avec une bonne gestion des versions de votre base de données.

    Je lance un peu le débat mais j'ai du malgré tout me retourner vers vFox car j'ai une bonne maîtrise du fonctionnement et des BDD en fox alors qu'en .NET je m'en sors mais je met des jours pour faire des choses que je fais en 10 minutes et malheureusement ma nouvelle entreprise n'a plus le temps d'attendre que je me forme...mais ça c'est mon problème :-] C'est dommage parce que je trouve l'orienté objet de .NET passionnant et le codage en C# vraiment génial...Peut-être y reviendrais-je pour des projets moins conséquents...
    Comme pour l'orienté objet, les bases SQL nécessite une organisation à ne pas prendre à la légère... Si adopter une organisation vous parrait "lourd" oubliez .NET + SQL ! (Ce n'est nullement une critique... C'est juste que .NET + SQL ne conviendra pas à votre façon de travailler).

    Cordialement


    Gilles TOURREAU - MVP C# - MCP - Architecte .NET/Consultant/Formateur - http://gilles.tourreau.fr
    vendredi 28 mai 2010 20:31
    Modérateur
  • Bonjour,

    Merci M. Lévy pour votre retour sur Database Deployment Toolkit !

    Cordialement


    Gilles TOURREAU - MVP C# - MCP - Architecte .NET/Consultant/Formateur - http://gilles.tourreau.fr
    vendredi 28 mai 2010 20:32
    Modérateur
  • Bonjour Florent,

     

    J'ai le même problème que toi, sauf que moi je ne sais faire que des application monoposte avec VFP,

    je voudrais savoir s'il y a une personne qui pourrait m'aider sur ce point.

     

    Bon courage à vous tous.

    mardi 10 août 2010 15:12
  • Bonjour,

    Merci de bien vouloir poser votre question sur une nouvelle discussion !

    Cordialement


    Gilles TOURREAU - MVP C# - MCTS ADO .NET 3.5 - MCPD Windows Developper 3.5 - Architecte .NET/Consultant/Formateur - http://gilles.tourreau.fr
    mardi 10 août 2010 15:24
    Modérateur