Bonjour à tous,
est-il possible (et logique) d'exécuter une PreparedStatement avec une connexion qui n'est pas celle qui l'a créé ?
Merci :)
Version imprimable
Bonjour à tous,
est-il possible (et logique) d'exécuter une PreparedStatement avec une connexion qui n'est pas celle qui l'a créé ?
Merci :)
Non
Merci pour cette réponse (qui ne m'arrange pas :?)
Je reviens sur ma question ...
Est-il insensé de faire cela même si on utilise une autre connexion utilisant le même driver connectée à la même DB avec le même user ?
La question n'est pas insensé ou pas, le problème est que ce n'est pas possible... mais dans tous les cas, où est ton problème ?
Comme le PreparedStatement est lié à une connexion, quand on change de connexion, il faut refaire un PreparedStatement. Ensuite, ce qu'il se passe dans le SGBDR, c'est une autre histoire... il est fort probable qu'il réutilise une requête pré-compilée (précédente), mais ça risque de dépendre de la base.
Quel était le besoin exactement ?
Mon ""problème"" est que je dois exécuter les mêmes requêtes de façon répétée (toutes les heures durant plusieurs années :mouarf:). De ce fait, je pensais utiliser des PreparedStatement. Toutefois, il n'est pas recommandé que je reste connecté en permanence à la DB.
Quelle est ta base de donnée ?
Si tu dois faire une requête ou une procédure stockée toutes les heures, tu as probablement intérêt à te servir d'un outil conçu pour cela.
Par exemple dans SQL Server, c'est une tâche que je donne à SQL Agent qui est conçu pour lancer des requêtes ou procédures ou autres ... à intervalles réguliers.
Je suppose qu'il existe la même chose dans d'autres bases.
Du coup, tu ne te poses plus la question de la connexion.:P
Tu m'étonnes ! :mouarf:Citation:
Envoyé par brolon
Ceci dit, si tu fais un traitement toutes les heures, ce n'est certainement pas le temps de préparation de la requête qui posera problème...
Sinon, tu peux regarder du côté des procédures stockées, ça semble plus intéressant (si elle sont effectivement toujours identiques, aux paramètres près bien sûr...)