J'ai besoin dans une appli d'accéder à des bases de données. J'utilise
donc le package java.sql et ses interfaces génériques (Connection,
ResultSet, ...) pour y accéder.
C'est l'utilisateur qui choisit le driver en fonction des bases de
données accédées (actuellement, MySQL et Informix).
Je viens de remarquer que chaque driver implémente les interfaces de
java.sql en classes concrètes. Il doit certainement y avoir un avantage
à utiliser les classes spécifiquement définies par chaque driver, mais
ça me pose un problème évident d'universalité de mon code, qui doit
pouvoir fonctionner quelque soit le driver utilisé.
Quelqu'un pourrait-il me donner plus d'infos sur l'utilité d'utiliser
ces classes spécifiques plutôt que les interfaces génériques (Rapidité ?
Fonctionnalités nouvelles ? ...) ?
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire
Veuillez sélectionner un problème
Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
Serval2412
Hello !
J'ai besoin dans une appli d'accéder à des bases de données. J'utilise donc le package java.sql et ses interfaces génériques (Connection, ResultSet, ...) pour y accéder. C'est l'utilisateur qui choisit le driver en fonction des bases de données accédées (actuellement, MySQL et Informix).
Je viens de remarquer que chaque driver implémente les interfaces de java.sql en classes concrètes. Il doit certainement y avoir un avantage à utiliser les classes spécifiquement définies par chaque driver, mais ça me pose un problème évident d'universalité de mon code, qui doit pouvoir fonctionner quelque soit le driver utilisé.
Quelqu'un pourrait-il me donner plus d'infos sur l'utilité d'utiliser ces classes spécifiques plutôt que les interfaces génériques (Rapidité ? Fonctionnalités nouvelles ? ...) ? Sur Oracle avec Websphere, on est obligé de récupérer la connexion
physique attachée à la connexion logique (gérée par le pool) afin de pouvoir utiliser passer des tableaux dans les procédures stockées.
En effet, le passage de tableau n'est pas présent dans la norme JDBC 2.0 (quid de la 3.0 à venir ?)
Hello !
J'ai besoin dans une appli d'accéder à des bases de données. J'utilise
donc le package java.sql et ses interfaces génériques (Connection,
ResultSet, ...) pour y accéder.
C'est l'utilisateur qui choisit le driver en fonction des bases de
données accédées (actuellement, MySQL et Informix).
Je viens de remarquer que chaque driver implémente les interfaces de
java.sql en classes concrètes. Il doit certainement y avoir un avantage
à utiliser les classes spécifiquement définies par chaque driver, mais
ça me pose un problème évident d'universalité de mon code, qui doit
pouvoir fonctionner quelque soit le driver utilisé.
Quelqu'un pourrait-il me donner plus d'infos sur l'utilité d'utiliser
ces classes spécifiques plutôt que les interfaces génériques (Rapidité ?
Fonctionnalités nouvelles ? ...) ?
Sur Oracle avec Websphere, on est obligé de récupérer la connexion
physique attachée à la connexion logique (gérée par le pool) afin de
pouvoir utiliser passer des tableaux dans les procédures stockées.
En effet, le passage de tableau n'est pas présent dans la norme JDBC 2.0
(quid de la 3.0 à venir ?)
J'ai besoin dans une appli d'accéder à des bases de données. J'utilise donc le package java.sql et ses interfaces génériques (Connection, ResultSet, ...) pour y accéder. C'est l'utilisateur qui choisit le driver en fonction des bases de données accédées (actuellement, MySQL et Informix).
Je viens de remarquer que chaque driver implémente les interfaces de java.sql en classes concrètes. Il doit certainement y avoir un avantage à utiliser les classes spécifiquement définies par chaque driver, mais ça me pose un problème évident d'universalité de mon code, qui doit pouvoir fonctionner quelque soit le driver utilisé.
Quelqu'un pourrait-il me donner plus d'infos sur l'utilité d'utiliser ces classes spécifiques plutôt que les interfaces génériques (Rapidité ? Fonctionnalités nouvelles ? ...) ? Sur Oracle avec Websphere, on est obligé de récupérer la connexion
physique attachée à la connexion logique (gérée par le pool) afin de pouvoir utiliser passer des tableaux dans les procédures stockées.
En effet, le passage de tableau n'est pas présent dans la norme JDBC 2.0 (quid de la 3.0 à venir ?)
Thomas Cornet
Tous les drivers JDBC implémentent les mêmes interfaces de JDBC. Cela assure que quelque soit le driver utilisé (et quelque soit la base de données derrière), tu programmes de la même manière et que les résultats restent les mêmes.
En usilisant JDBC, la bonne manière de faire est de n'utiliser que les interfaces du package java.sql et de laisser les drivers spécifiques faire leur travail.
Et que tu switcheras de base, il suffit juste que ton programme utilise une connexion et un driver différent, cela n'implique aucune modification de ton code.
Hello !
J'ai besoin dans une appli d'accéder à des bases de données. J'utilise donc le package java.sql et ses interfaces génériques (Connection, ResultSet, ...) pour y accéder. C'est l'utilisateur qui choisit le driver en fonction des bases de données accédées (actuellement, MySQL et Informix).
Je viens de remarquer que chaque driver implémente les interfaces de java.sql en classes concrètes. Il doit certainement y avoir un avantage à utiliser les classes spécifiquement définies par chaque driver, mais ça me pose un problème évident d'universalité de mon code, qui doit pouvoir fonctionner quelque soit le driver utilisé.
Quelqu'un pourrait-il me donner plus d'infos sur l'utilité d'utiliser ces classes spécifiques plutôt que les interfaces génériques (Rapidité ? Fonctionnalités nouvelles ? ...) ?
Merci d'avance,
Tous les drivers JDBC implémentent les mêmes interfaces de JDBC. Cela
assure que quelque soit le driver utilisé (et quelque soit la base de
données derrière), tu programmes de la même manière et que les résultats
restent les mêmes.
En usilisant JDBC, la bonne manière de faire est de n'utiliser que les
interfaces du package java.sql et de laisser les drivers spécifiques faire
leur travail.
Et que tu switcheras de base, il suffit juste que ton programme utilise
une connexion et un driver différent, cela n'implique aucune modification
de ton code.
Hello !
J'ai besoin dans une appli d'accéder à des bases de données. J'utilise
donc le package java.sql et ses interfaces génériques (Connection,
ResultSet, ...) pour y accéder.
C'est l'utilisateur qui choisit le driver en fonction des bases de
données accédées (actuellement, MySQL et Informix).
Je viens de remarquer que chaque driver implémente les interfaces de
java.sql en classes concrètes. Il doit certainement y avoir un avantage
à utiliser les classes spécifiquement définies par chaque driver, mais
ça me pose un problème évident d'universalité de mon code, qui doit
pouvoir fonctionner quelque soit le driver utilisé.
Quelqu'un pourrait-il me donner plus d'infos sur l'utilité d'utiliser
ces classes spécifiques plutôt que les interfaces génériques (Rapidité ?
Fonctionnalités nouvelles ? ...) ?
Tous les drivers JDBC implémentent les mêmes interfaces de JDBC. Cela assure que quelque soit le driver utilisé (et quelque soit la base de données derrière), tu programmes de la même manière et que les résultats restent les mêmes.
En usilisant JDBC, la bonne manière de faire est de n'utiliser que les interfaces du package java.sql et de laisser les drivers spécifiques faire leur travail.
Et que tu switcheras de base, il suffit juste que ton programme utilise une connexion et un driver différent, cela n'implique aucune modification de ton code.
Hello !
J'ai besoin dans une appli d'accéder à des bases de données. J'utilise donc le package java.sql et ses interfaces génériques (Connection, ResultSet, ...) pour y accéder. C'est l'utilisateur qui choisit le driver en fonction des bases de données accédées (actuellement, MySQL et Informix).
Je viens de remarquer que chaque driver implémente les interfaces de java.sql en classes concrètes. Il doit certainement y avoir un avantage à utiliser les classes spécifiquement définies par chaque driver, mais ça me pose un problème évident d'universalité de mon code, qui doit pouvoir fonctionner quelque soit le driver utilisé.
Quelqu'un pourrait-il me donner plus d'infos sur l'utilité d'utiliser ces classes spécifiques plutôt que les interfaces génériques (Rapidité ? Fonctionnalités nouvelles ? ...) ?
J'ai besoin dans une appli d'accéder à des bases de données. J'utilise donc le package java.sql et ses interfaces génériques (Connection, ResultSet, ...) pour y accéder. C'est l'utilisateur qui choisit le driver en fonction des bases de données accédées (actuellement, MySQL et Informix).
Je viens de remarquer que chaque driver implémente les interfaces de java.sql en classes concrètes. Il doit certainement y avoir un avantage à utiliser les classes spécifiquement définies par chaque driver, mais ça me pose un problème évident d'universalité de mon code, qui doit pouvoir fonctionner quelque soit le driver utilisé.
Quelqu'un pourrait-il me donner plus d'infos sur l'utilité d'utiliser ces classes spécifiques plutôt que les interfaces génériques (Rapidité ? Fonctionnalités nouvelles ? ...) ? Sur Oracle avec Websphere, on est obligé de récupérer la connexion
physique attachée à la connexion logique (gérée par le pool) afin de pouvoir utiliser passer des tableaux dans les procédures stockées.
En effet, le passage de tableau n'est pas présent dans la norme JDBC 2.0 (quid de la 3.0 à venir ?)
Yep, pour acceder au blobs dans postgres par j2ee j'ai du faire le même type de 'bidouille', sinon cela ne fonctionnait pas.
-- Cordialement,
Patrice Trognon http://wwW.javadevel.com
Serval2412 wrote:
Hello !
J'ai besoin dans une appli d'accéder à des bases de données. J'utilise
donc le package java.sql et ses interfaces génériques (Connection,
ResultSet, ...) pour y accéder.
C'est l'utilisateur qui choisit le driver en fonction des bases de
données accédées (actuellement, MySQL et Informix).
Je viens de remarquer que chaque driver implémente les interfaces de
java.sql en classes concrètes. Il doit certainement y avoir un avantage
à utiliser les classes spécifiquement définies par chaque driver, mais
ça me pose un problème évident d'universalité de mon code, qui doit
pouvoir fonctionner quelque soit le driver utilisé.
Quelqu'un pourrait-il me donner plus d'infos sur l'utilité d'utiliser
ces classes spécifiques plutôt que les interfaces génériques (Rapidité ?
Fonctionnalités nouvelles ? ...) ?
Sur Oracle avec Websphere, on est obligé de récupérer la connexion
physique attachée à la connexion logique (gérée par le pool) afin de
pouvoir utiliser passer des tableaux dans les procédures stockées.
En effet, le passage de tableau n'est pas présent dans la norme JDBC 2.0
(quid de la 3.0 à venir ?)
Yep, pour acceder au blobs dans postgres par j2ee j'ai du faire le même
type de 'bidouille', sinon cela ne fonctionnait pas.
J'ai besoin dans une appli d'accéder à des bases de données. J'utilise donc le package java.sql et ses interfaces génériques (Connection, ResultSet, ...) pour y accéder. C'est l'utilisateur qui choisit le driver en fonction des bases de données accédées (actuellement, MySQL et Informix).
Je viens de remarquer que chaque driver implémente les interfaces de java.sql en classes concrètes. Il doit certainement y avoir un avantage à utiliser les classes spécifiquement définies par chaque driver, mais ça me pose un problème évident d'universalité de mon code, qui doit pouvoir fonctionner quelque soit le driver utilisé.
Quelqu'un pourrait-il me donner plus d'infos sur l'utilité d'utiliser ces classes spécifiques plutôt que les interfaces génériques (Rapidité ? Fonctionnalités nouvelles ? ...) ? Sur Oracle avec Websphere, on est obligé de récupérer la connexion
physique attachée à la connexion logique (gérée par le pool) afin de pouvoir utiliser passer des tableaux dans les procédures stockées.
En effet, le passage de tableau n'est pas présent dans la norme JDBC 2.0 (quid de la 3.0 à venir ?)
Yep, pour acceder au blobs dans postgres par j2ee j'ai du faire le même type de 'bidouille', sinon cela ne fonctionnait pas.
-- Cordialement,
Patrice Trognon http://wwW.javadevel.com
Fabien Bergeret
Thomas Cornet wrote:
Tous les drivers JDBC implémentent les mêmes interfaces de JDBC. Cela assure que quelque soit le driver utilisé (et quelque soit la base de données derrière), tu programmes de la même manière et que les résultats restent les mêmes.
En usilisant JDBC, la bonne manière de faire est de n'utiliser que les interfaces du package java.sql et de laisser les drivers spécifiques faire leur travail.
Et que tu switcheras de base, il suffit juste que ton programme utilise une connexion et un driver différent, cela n'implique aucune modification de ton code.
A condition de n'utiliser que du SQL standard et portable, ce qui n'est
pas gagne !
Thomas Cornet wrote:
Tous les drivers JDBC implémentent les mêmes interfaces de JDBC. Cela
assure que quelque soit le driver utilisé (et quelque soit la base de
données derrière), tu programmes de la même manière et que les résultats
restent les mêmes.
En usilisant JDBC, la bonne manière de faire est de n'utiliser que les
interfaces du package java.sql et de laisser les drivers spécifiques faire
leur travail.
Et que tu switcheras de base, il suffit juste que ton programme utilise
une connexion et un driver différent, cela n'implique aucune modification
de ton code.
A condition de n'utiliser que du SQL standard et portable, ce qui n'est
Tous les drivers JDBC implémentent les mêmes interfaces de JDBC. Cela assure que quelque soit le driver utilisé (et quelque soit la base de données derrière), tu programmes de la même manière et que les résultats restent les mêmes.
En usilisant JDBC, la bonne manière de faire est de n'utiliser que les interfaces du package java.sql et de laisser les drivers spécifiques faire leur travail.
Et que tu switcheras de base, il suffit juste que ton programme utilise une connexion et un driver différent, cela n'implique aucune modification de ton code.
A condition de n'utiliser que du SQL standard et portable, ce qui n'est
