Acce bdd distante
TRAX44
Messages postés
93
Date d'inscription
mercredi 18 septembre 2002
Statut
Membre
Dernière intervention
20 juillet 2006
-
24 août 2004 à 19:01
cs_frop01 Messages postés 1352 Date d'inscription lundi 27 octobre 2003 Statut Membre Dernière intervention 19 novembre 2008 - 24 août 2004 à 21:26
cs_frop01 Messages postés 1352 Date d'inscription lundi 27 octobre 2003 Statut Membre Dernière intervention 19 novembre 2008 - 24 août 2004 à 21:26
1 réponse
cs_frop01
Messages postés
1352
Date d'inscription
lundi 27 octobre 2003
Statut
Membre
Dernière intervention
19 novembre 2008
2
24 août 2004 à 21:26
24 août 2004 à 21:26
Je penses que RDO sera plus approprié Voici un ptit extrait de MSDN :
Le modèle RDO et le contrôle RemoteData peuvent vous aider à répondre à des exigences particulières d'un environnement client-serveur. Grâce à ces caractéristiques d'accès aux données à distance, vous pouvez :
Accéder très rapidement aux données de sources de données ODBC distantes. La possibilité de récupérer rapidement les résultats de requêtes complexes constitue un des buts de toute application d'accès aux données. Le modèle RDO atteint un niveau de performances qui n'est égalé que par les modèles de programmation API VBSQL et ODBC. Grâce au moteur de données à distance, le RDO améliore considérablement les temps de réponse et la productivité des utilisateurs.
Gérer les codes renvoyés ainsi que les paramètres d'entrée et de sortie des procédures stockées. Les paramètres de sortie constituent la seule manière d'extraire des informations d'une procédure stockée Oracle et sont largement utilisés pour les requêtes ainsi que pour de nombreuses fonctions d'administration. Généralement, vous ne pouvez vous assurer du bon achèvement d'une procédure stockée qu'en accédant à sa valeur renvoyée. Le RDO permet d'accéder à chacun de ces paramètres par l'entremise de l'objet rdoParameter.
Gérer des jeux de résultats multiples. En recourant à une requête unique qui renvoie plusieurs jeux de résultats, vous pouvez mieux exploiter les possibilités du processeur de requête et les ressources du système. Vous pouvez aussi améliorer les performances en exécutant une requête unique qui se chargera de rassembler les données nécessaires pour remplir plusieurs menus et zones de liste. En outre, en combinant une requête de comptage de lignes et une requête SELECT, vous pouvez configurer avec précision des barres de défilement et des barres de progression.
Soumettre des requêtes Action multiples en un seul lot. Généralement, votre application peut soumettre un jeu d'opérations INSERT, DELETE ou UPDATE sous la forme d'une seule instruction SQL. Vous augmentez ainsi les performances puisque vous réduisez l'importance du traitement réseau et du traitement distant, tout en facilitant la gestion des transactions.
Limiter le nombre de lignes renvoyées ou traitées. Lorsque les utilisateurs peuvent vouloir sélectionner un nombre de lignes trop important, le RDO met en œuvre un contrôleur de requêtes de façon à limiter le nombre de lignes renvoyées par une source de données quelconque. Vous pouvez ainsi prévoir le temps de réponse des requêtes et gérer plus facilement les ressources dont le serveur et la station de travail ont besoin pour traiter les ensembles de valeurs clés des curseurs. En appliquant ce mécanisme, vous pouvez limiter le nombre de lignes affectées par une requête de modification des données.
Utiliser les curseurs côté serveur. Certains serveurs, notamment Microsoft SQL Server, prennent en charge les ensembles de valeurs clés des curseurs créés sur le serveur, plutôt que sur la station de travail. Lorsque les conditions requises sont réunies, ce type de gestion des curseurs peut améliorer sensiblement les performances, réduire la charge du réseau et les ressources exigées de la station de travail.
Exécuter des requêtes de manière asynchrone. Si l'exécution d'une requête se prolonge au-delà du temps prévu, vous devez avoir la possibilité d'annuler la requête ou d'exécuter du code pendant que son traitement est en cours. Le RDO permet d'exécuter une requête de manière asynchrone et de l'annuler. Il fournit en outre une interface de programmation asynchrone événementielle unique qui rend superflues les boucles d'interrogation. Le traitement asynchrone s'étend à l'ouverture des connexions et à l'utilisation de la méthode MoveLast.
Poursuivre les requêtes au-delà du délai initial. Lorsque l'exécution d'une requête n'est pas terminée au terme de la période définie dans la propriété QueryTimeout, le RDO vous permet d'outrepasser l'annulation de la requête et de poursuivre pendant un délai supplémentaire.
Prendre en charge le polymorphisme amélioré et la création d'objets « autonomes ». Le RDO prend désormais en charge la création d'objets rdoConnection et rdoQuery à l'aide de l'instruction Dim. Ces objets autonomes peuvent être associés à n'importe quels autres objets en vue d'exécuter des actions. Vous pouvez, par exemple, créer un objet rdoQuery indépendant de tout objet rdoConnection et l'associer ultérieurement à une connexion ouverte.
Prendre en charge des jeux de résultats dissociés. Le RDO vous permet de créer un curseur statique en lecture-écriture et de rompre la connexion avec le serveur distant. Les données contenues dans l'objet rdoResultset demeurent accessibles ou modifiables. Une fois que vous associez de nouveau le jeu de résultats à un autre objet rdoConnection, vous pouvez utiliser la méthode BatchUpdate pour inclure dans la base de données ces modifications opérées hors ligne.
Créer et gérer des mises à jour optimistes par lots. Les bibliothèques de curseurs ODBC reconnaissent le concept de mises à jour optimistes, mais ligne par ligne plutôt que par lots. Ce type de mise à jour sollicite considérablement le serveur et le réseau. Le RDO tire parti de la nouvelle bibliothèque client de curseurs par lots qui regroupe des jeux de lignes à insérer, mettre à jour ou supprimer. Il suffit ainsi d'effectuer un aller-retour jusqu'au serveur, ce qui accélère les mises à jour et réduit le trafic sur le réseau.
Faciliter l'utilisation des procédures stockées. Le RDO vous permet d'exprimer les requêtes paramétrées et les procédures stockées sous la forme de méthodes d'un objet rdoConnection parent. Vous pouvez passer des paramètres sans manipuler aucun objet rdoParameter, exactement comme vous le feriez pour n'importe quelle fonction Visual Basic.
Mettre à disposition les descripteurs ODBC sous-jacents. Si la souplesse ou le contrôle proposés par un modèle objet ne vous conviennent pas, vous devez pouvoir accéder directement à la source de données. Le RDO permet d'accéder aux descripteurs des instructions, des connexions et de l'environnement ODBC.
Réduire les exigences en mémoire. Très souvent, la mémoire vive du système qui héberge un frontal client-serveur est limitée. Il est donc important que les applications conçues pour ces systèmes ne sollicitent pas exagérément les ressources système de la station de travail et plus particulièrement sa mémoire vive. La configuration mémoire requise par le modèle RDO est considérablement inférieure à celle d'autres modèles de programmation et ses curseurs de très bas niveau ne nécessitent pas le recours à la mémoire ou au disque local.
:-p [mailto:cyberscorp2004@msn.com MSN] :big)
Le modèle RDO et le contrôle RemoteData peuvent vous aider à répondre à des exigences particulières d'un environnement client-serveur. Grâce à ces caractéristiques d'accès aux données à distance, vous pouvez :
Accéder très rapidement aux données de sources de données ODBC distantes. La possibilité de récupérer rapidement les résultats de requêtes complexes constitue un des buts de toute application d'accès aux données. Le modèle RDO atteint un niveau de performances qui n'est égalé que par les modèles de programmation API VBSQL et ODBC. Grâce au moteur de données à distance, le RDO améliore considérablement les temps de réponse et la productivité des utilisateurs.
Gérer les codes renvoyés ainsi que les paramètres d'entrée et de sortie des procédures stockées. Les paramètres de sortie constituent la seule manière d'extraire des informations d'une procédure stockée Oracle et sont largement utilisés pour les requêtes ainsi que pour de nombreuses fonctions d'administration. Généralement, vous ne pouvez vous assurer du bon achèvement d'une procédure stockée qu'en accédant à sa valeur renvoyée. Le RDO permet d'accéder à chacun de ces paramètres par l'entremise de l'objet rdoParameter.
Gérer des jeux de résultats multiples. En recourant à une requête unique qui renvoie plusieurs jeux de résultats, vous pouvez mieux exploiter les possibilités du processeur de requête et les ressources du système. Vous pouvez aussi améliorer les performances en exécutant une requête unique qui se chargera de rassembler les données nécessaires pour remplir plusieurs menus et zones de liste. En outre, en combinant une requête de comptage de lignes et une requête SELECT, vous pouvez configurer avec précision des barres de défilement et des barres de progression.
Soumettre des requêtes Action multiples en un seul lot. Généralement, votre application peut soumettre un jeu d'opérations INSERT, DELETE ou UPDATE sous la forme d'une seule instruction SQL. Vous augmentez ainsi les performances puisque vous réduisez l'importance du traitement réseau et du traitement distant, tout en facilitant la gestion des transactions.
Limiter le nombre de lignes renvoyées ou traitées. Lorsque les utilisateurs peuvent vouloir sélectionner un nombre de lignes trop important, le RDO met en œuvre un contrôleur de requêtes de façon à limiter le nombre de lignes renvoyées par une source de données quelconque. Vous pouvez ainsi prévoir le temps de réponse des requêtes et gérer plus facilement les ressources dont le serveur et la station de travail ont besoin pour traiter les ensembles de valeurs clés des curseurs. En appliquant ce mécanisme, vous pouvez limiter le nombre de lignes affectées par une requête de modification des données.
Utiliser les curseurs côté serveur. Certains serveurs, notamment Microsoft SQL Server, prennent en charge les ensembles de valeurs clés des curseurs créés sur le serveur, plutôt que sur la station de travail. Lorsque les conditions requises sont réunies, ce type de gestion des curseurs peut améliorer sensiblement les performances, réduire la charge du réseau et les ressources exigées de la station de travail.
Exécuter des requêtes de manière asynchrone. Si l'exécution d'une requête se prolonge au-delà du temps prévu, vous devez avoir la possibilité d'annuler la requête ou d'exécuter du code pendant que son traitement est en cours. Le RDO permet d'exécuter une requête de manière asynchrone et de l'annuler. Il fournit en outre une interface de programmation asynchrone événementielle unique qui rend superflues les boucles d'interrogation. Le traitement asynchrone s'étend à l'ouverture des connexions et à l'utilisation de la méthode MoveLast.
Poursuivre les requêtes au-delà du délai initial. Lorsque l'exécution d'une requête n'est pas terminée au terme de la période définie dans la propriété QueryTimeout, le RDO vous permet d'outrepasser l'annulation de la requête et de poursuivre pendant un délai supplémentaire.
Prendre en charge le polymorphisme amélioré et la création d'objets « autonomes ». Le RDO prend désormais en charge la création d'objets rdoConnection et rdoQuery à l'aide de l'instruction Dim. Ces objets autonomes peuvent être associés à n'importe quels autres objets en vue d'exécuter des actions. Vous pouvez, par exemple, créer un objet rdoQuery indépendant de tout objet rdoConnection et l'associer ultérieurement à une connexion ouverte.
Prendre en charge des jeux de résultats dissociés. Le RDO vous permet de créer un curseur statique en lecture-écriture et de rompre la connexion avec le serveur distant. Les données contenues dans l'objet rdoResultset demeurent accessibles ou modifiables. Une fois que vous associez de nouveau le jeu de résultats à un autre objet rdoConnection, vous pouvez utiliser la méthode BatchUpdate pour inclure dans la base de données ces modifications opérées hors ligne.
Créer et gérer des mises à jour optimistes par lots. Les bibliothèques de curseurs ODBC reconnaissent le concept de mises à jour optimistes, mais ligne par ligne plutôt que par lots. Ce type de mise à jour sollicite considérablement le serveur et le réseau. Le RDO tire parti de la nouvelle bibliothèque client de curseurs par lots qui regroupe des jeux de lignes à insérer, mettre à jour ou supprimer. Il suffit ainsi d'effectuer un aller-retour jusqu'au serveur, ce qui accélère les mises à jour et réduit le trafic sur le réseau.
Faciliter l'utilisation des procédures stockées. Le RDO vous permet d'exprimer les requêtes paramétrées et les procédures stockées sous la forme de méthodes d'un objet rdoConnection parent. Vous pouvez passer des paramètres sans manipuler aucun objet rdoParameter, exactement comme vous le feriez pour n'importe quelle fonction Visual Basic.
Mettre à disposition les descripteurs ODBC sous-jacents. Si la souplesse ou le contrôle proposés par un modèle objet ne vous conviennent pas, vous devez pouvoir accéder directement à la source de données. Le RDO permet d'accéder aux descripteurs des instructions, des connexions et de l'environnement ODBC.
Réduire les exigences en mémoire. Très souvent, la mémoire vive du système qui héberge un frontal client-serveur est limitée. Il est donc important que les applications conçues pour ces systèmes ne sollicitent pas exagérément les ressources système de la station de travail et plus particulièrement sa mémoire vive. La configuration mémoire requise par le modèle RDO est considérablement inférieure à celle d'autres modèles de programmation et ses curseurs de très bas niveau ne nécessitent pas le recours à la mémoire ou au disque local.
:-p [mailto:cyberscorp2004@msn.com MSN] :big)