locked
CursorAdapter RRS feed

  • Question

  • Bonjour,

     

    Je suis entrain de migrer une application Visual FoxPro 8.0 vers SQL Server 2000. J'ai remplacé les anciens curseurs par des curseurs CursorAdapter et j'ai utilisé ADO pour accéder à la base de données. L'ancien Code fonctionne bien sauf les index. Avez vous une idée comment utliser les index SQL Server dans FoxPro.

     

    Merci de votre aide.

    mercredi 9 mai 2007 17:10

Réponses

  • Bonjour,

     

    quand on migre ses données VFP vers SQL Server, il faut en effet reprendre le code qui utilise les index.

    Tu ne peux pas invoquer toi-même un index de SQL Server, mais par contre, VFP les utilisera quand tu requèteras sur des champs qui sont indexés coté SQL (quel que soit ton outil de requète, vue, cursoradapter, ou SQL Pass-Through).

     

    Quand on est en client-serveur, on n'a en principe pas à se déplacer dans des gros jeux de données - ceux qui justifiaient par exemple des index et des SEEK, SEEK( ), ou INDEXSEEK( ). On ne ramène que les données dont on a besoin (clause WHERE, jointures, clause HAVING). Si tu dois faire des recherches dans les données du curseur local (celles de ton cursoradapter, qui ont été récupérées depuis SQL Server), tu peux donc utiliser LOCATE sans que tes perfs n'en soient affectées.

     

    Et si jamais tu avais quand même besoin, rien ne t'empèche de mettre des index sur ces curseurs, et d'utiliser la syntaxe VFP qui va avec (mais ça ne sera pas les index de SQL Server) ; il te faut tester pour vérifier les performances.

     

    Celà dit, toujours en terme de performances, tu aurais eu intéret à utiliser SQL Pass-through sur des connexions via l'ODBC ; c'est un peu plus lourd à coder (il faut modifer plus de code), mais c'est le plus performant, même si c'est moins souple que les CursorAdapter.

    mercredi 9 mai 2007 19:44

Toutes les réponses

  • Bonjour,

     

    quand on migre ses données VFP vers SQL Server, il faut en effet reprendre le code qui utilise les index.

    Tu ne peux pas invoquer toi-même un index de SQL Server, mais par contre, VFP les utilisera quand tu requèteras sur des champs qui sont indexés coté SQL (quel que soit ton outil de requète, vue, cursoradapter, ou SQL Pass-Through).

     

    Quand on est en client-serveur, on n'a en principe pas à se déplacer dans des gros jeux de données - ceux qui justifiaient par exemple des index et des SEEK, SEEK( ), ou INDEXSEEK( ). On ne ramène que les données dont on a besoin (clause WHERE, jointures, clause HAVING). Si tu dois faire des recherches dans les données du curseur local (celles de ton cursoradapter, qui ont été récupérées depuis SQL Server), tu peux donc utiliser LOCATE sans que tes perfs n'en soient affectées.

     

    Et si jamais tu avais quand même besoin, rien ne t'empèche de mettre des index sur ces curseurs, et d'utiliser la syntaxe VFP qui va avec (mais ça ne sera pas les index de SQL Server) ; il te faut tester pour vérifier les performances.

     

    Celà dit, toujours en terme de performances, tu aurais eu intéret à utiliser SQL Pass-through sur des connexions via l'ODBC ; c'est un peu plus lourd à coder (il faut modifer plus de code), mais c'est le plus performant, même si c'est moins souple que les CursorAdapter.

    mercredi 9 mai 2007 19:44
  • Bonjour,

     

    Merci Michel pour ton précieux aide. En faite, avant de poser ma question dans le forum, et pour ne pas modifier le code (seek, set order to, set Key to ...), j'ai  essayé la solution qui consiste à créer des index locaux sur les cursoradapter et ça a bien fonctionné. Mais, je crains que cette solution sera moins performante si on récupère une quantité volumineuse des données sutout qu'il y a des formulaires qui charge la table au complet.

    A propos de SQL Pass-through, c'est vrai que c'est plus performant mais le problème est qu'on ne peut pas l'utiliser comme datasource pour les contrôles (et surtout les grilles).

     

    Merci encore une fois

     

     

    jeudi 10 mai 2007 17:30
  • Mais si, on peut parfaitement utiliser SQL Pass-through pour "alimenter" des controles, et des grids entre autres.

     

    Quand tu fais ton SLEXEC, tu peux indiquer le nom du curseur de résultat, et tu utiliseras ce nom d'alias comme source de données. Et si tu utilises la classe DataEnvironment (en l'ayant sous-classée), et la classe Cursor (sous-classée elle aussi), tu les surcharges avec des méthodes et propriétés qui vont récupérer le curseur résultat de ton SL Pass Through et l'affecter à la propriété cursorsource de tes objets Cursor.

     

    jeudi 10 mai 2007 18:20
  • En faite je n'ai jamais utilisé SQL pass-through. Dans le help ils disent qu'on ne peut pas le lier à des contrôles (Can't be used as a data source for controls). Je vais essayer de découvrir cette technologie et voir les possibilités qu'elle offre. D'autre part, je viens de passer à la version 8 de Foxpro. J'ai déjà travaillé avant avec la version 5 (ça fais 2 ans et demi que je n'ai pas touché Foxpro). Je n'ai jamais sous-classé la classe DataEnvironment ou Cursor. Est ce que tu peux me dire qu'ils sont les avantages d'une telle opération ?

     

    Merci

    jeudi 10 mai 2007 18:43