Les étapes de l'importation

1. Lancez l'éditeur d'analyses : cliquez sur parmi les boutons d'accès rapide.
2. Sous le volet "Analyse", dans le groupe "Création", déroulez "Importer" et sélectionnez "Importer des descriptions de fichiers/tables".
3. L'assistant se lance. Une connexion à la base de données SQL Server est automatiquement créée et associée aux fichiers importés dans l'analyse. Cette connexion devra être utilisée pour manipuler le fichier de données SQL Server par programmation.

• Type de base de données : SQL Server.
• Caractéristiques de la connexion : Serveur de données, Utilisateur et mot de passe, base de données.
• L'application accédera aux données dans le format actuel.
• Lorsque la connexion est établie, il suffit de sélectionner les tables à importer dans l'analyse WINDEV ou WEBDEV. Ces tables pourront être manipulées par programmation grâce aux fonctions HFSQL du WLangage. Ces tables apparaîtront en bleu sous l'éditeur d'analyses.

Prendre en compte les évolutions de la base de données SQL Server

• soit d'analyser les différences pour les tables importées.
• soit d'analyser les différences pour toutes les tables SQL Server.

1. Ouverture de la connexion

• Si vous tentez de lire directement le fichier (fonction HLitPremier, ...), la connexion associée à la description du fichier dans l'analyse sera automatiquement ouverte.
• Les informations optionnelles de connexion permettent de configurer le comportement du Connecteur Natif (format des dates, résultat des concaténations, ...).
• Par défaut, la version installée du Connecteur Natif SQL Server est utilisée. Si vous avez installé à la fois le Connecteur Natif SQL Server via OLE DB et via ODBC, le Connecteur Natif via OLE DB est utilisé. Il est possible de sélectionner la version à utiliser. La variable H.ModeSQLServer permet de forcer un mode grâce aux valeurs suivantes :
  • 0 pour forcer le Connecteur Natif SQL Server via OLE DB.
  • 3 pour forcer le Connecteur Natif SQL Server via ODBC.
  Cette variable doit être modifiée avant l'utilisation des fonctions HDécritConnexion et/ou HOuvreConnexion.
• Il est possible d'utiliser des informations étendues spécifiques (dans la fonction HOuvreConnexion ou dans la fonction HDécritConnexion) :
  • WD Cache Size : Fixe le nombre d'enregistrements à lire en une seule fois avec un curseur serveur. Par défaut, cette valeur vaut 100.
  • WD Cursor Location : Si "WD Cursor Location = SERVER", permet de demander l'utilisation d'un curseur serveur pour tous les parcours effectués sur cette connexion. Les curseurs serveur utilisés sont du type FAST_FORWARD. Pour plus de détails, consultez la documentation de SQL Server. Ce type de curseur peut être utilisé pour :
    - Limiter les ressources réservées sur le serveur pendant les parcours.
    - Limiter le nombre de connexions ouvertes par l'accès natif pour gérer des parcours multiples en parallèle.
    Attention :
    • Les parcours effectués avec des curseurs serveur sont généralement plus lents que dans le mode par défaut.
    • Les curseurs serveur peuvent être incompatibles avec certains types de requête.
    • Les performances sont sensibles à la taille du cache.
      Remarque : Lorsqu'une connexion est en transaction, les curseurs serveur sont automatiquement utilisés.
• SQL Azure : Si le nom du serveur est de type : NomServeur.database.windows.net, le login doit être de la forme : login@NomServeur.

2. Exécution de requêtes

• HExécuteRequête : permet d'exécuter une requête prédéfinie avec l'éditeur de requêtes.
• HExécuteRequêteSQL : permet d'exécuter une requête en précisant directement le code SQL de la requête, et le nom qui sera attribué à ce code SQL.

// Initialisation de la requête "Client_84"
HExécuteRequête(CLIENT_84, "BaseSQLSERVER", hRequêteSansCorrection)
HExécuteRequêteSQL(ReqClient, "BaseSQLSERVER", hRequêteSansCorrection, ...
		"SELECT NOM FROM CLIENT")

3. Récupération du résultat

4. Fermeture de la connexion

Optimisation

• Les champs de type "Table fichier" basés sur des requêtes sont optimisés : il est possible de trier le contenu du champ Table en cliquant sur une de ses colonnes.
• Pour éviter de ré-exécuter plusieurs fois la même requête lors du parcours de son résultat, il est conseillé d'utiliser la constante hSansRafraîchir (par exemple si un seul poste modifie les données).
• Chaque parcours sur une clé nécessite la création d'un "cursor". Ce "cursor" est exécuté dans une "task" SQL SERVER. Afin de ne pas conserver des processus inutiles sur le serveur, il est conseillé d'utiliser :
  • la fonction HFerme sur les tables une fois le parcours achevé,
  • la fonction HAnnuleDéclaration dans le cas de parcours de requêtes.