Comment peut-on reconnaitre d'une manière générique qu'une connection a
une base de données est fermée ? Si par exemple le serveur de base de
données a redémarré...
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
bruno at modulix
William Dode wrote:
slt,
Comment peut-on reconnaitre d'une manière générique qu'une connection a une base de données est fermée ? Si par exemple le serveur de base de données a redémarré...
Que se passe-t'il si on tente de faire une requête dans ce cas ?
-- bruno desthuilliers python -c "print '@'.join(['.'.join([w[::-1] for w in p.split('.')]) for p in ''.split('@')])"
William Dode wrote:
slt,
Comment peut-on reconnaitre d'une manière générique qu'une connection a
une base de données est fermée ? Si par exemple le serveur de base de
données a redémarré...
Que se passe-t'il si on tente de faire une requête dans ce cas ?
--
bruno desthuilliers
python -c "print '@'.join(['.'.join([w[::-1] for w in p.split('.')]) for
p in 'onurb@xiludom.gro'.split('@')])"
Comment peut-on reconnaitre d'une manière générique qu'une connection a une base de données est fermée ? Si par exemple le serveur de base de données a redémarré...
Que se passe-t'il si on tente de faire une requête dans ce cas ?
-- bruno desthuilliers python -c "print '@'.join(['.'.join([w[::-1] for w in p.split('.')]) for p in ''.split('@')])"
William Dode
On 24-04-2006, bruno at modulix wrote:
William Dode wrote:
slt,
Comment peut-on reconnaitre d'une manière générique qu'une connection a une base de données est fermée ? Si par exemple le serveur de base de données a redémarré...
Que se passe-t'il si on tente de faire une requête dans ce cas ?
Une exception est levée, mais ça ne me dit pas si je dois redemander une connexion et relancer la requete.
-- William Dodé - http://flibuste.net
On 24-04-2006, bruno at modulix wrote:
William Dode wrote:
slt,
Comment peut-on reconnaitre d'une manière générique qu'une connection a
une base de données est fermée ? Si par exemple le serveur de base de
données a redémarré...
Que se passe-t'il si on tente de faire une requête dans ce cas ?
Une exception est levée, mais ça ne me dit pas si je dois redemander une
connexion et relancer la requete.
Comment peut-on reconnaitre d'une manière générique qu'une connection a une base de données est fermée ? Si par exemple le serveur de base de données a redémarré...
Que se passe-t'il si on tente de faire une requête dans ce cas ?
Une exception est levée, mais ça ne me dit pas si je dois redemander une connexion et relancer la requete.
-- William Dodé - http://flibuste.net
Méta-MCI
Bonsoir !
Il y a tellement de cas possible, qu'une solution générique semble difficile.
Par exemple, une fois une connexion établie, débranche la prise réseau, alors que le serveur continue de fonctionner normalement...
@+
MCI
Bonsoir !
Il y a tellement de cas possible, qu'une solution générique semble
difficile.
Par exemple, une fois une connexion établie, débranche la prise réseau,
alors que le serveur continue de fonctionner normalement...
Il y a tellement de cas possible, qu'une solution générique semble difficile.
Par exemple, une fois une connexion établie, débranche la prise réseau, alors que le serveur continue de fonctionner normalement...
@+
MCI
Bruno Desthuilliers
On 24-04-2006, bruno at modulix wrote:
William Dode wrote:
slt,
Comment peut-on reconnaitre d'une manière générique qu'une connection a une base de données est fermée ? Si par exemple le serveur de base de données a redémarré...
Que se passe-t'il si on tente de faire une requête dans ce cas ?
Une exception est levée,
Donc, il suffit de tenter d'exécuter une requête, et de regarder si ça lève une exception, non ?-)
NB: si je jette un coup d'oeil dans le pep 249, je trouve ça:
""" OperationalError
Exception raised for errors that are related to the database's operation and not necessarily under the control of the programmer, e.g. *an unexpected disconnect occurs*, the data source name is not found, a transaction could not be processed, a memory allocation error occurred during processing, etc. It must be a subclass of DatabaseError.
InternalError
Exception raised when the database encounters an internal error, e.g. *the cursor is not valid anymore*, the transaction is out of sync, etc. It must be a subclass of DatabaseError. """
mais ça ne me dit pas si je dois redemander une connexion et relancer la requete.
Bin, ça, c'est à ton programme de gérer le problème.
Plus sérieusement: si je comprend bien, ton problème est de déterminer si l'exception qui est levée est bien liée à une coupure momentanée de la connection, ou à un autre problème. Je viens de parcourir le pep 249 sans trouver grand chose à ce propos. Bref, à part retenter une connection + requête, et regarder si tu a une exception similaire (même type et même message), je ne vois pas trop...
Désolé.
On 24-04-2006, bruno at modulix wrote:
William Dode wrote:
slt,
Comment peut-on reconnaitre d'une manière générique qu'une connection a
une base de données est fermée ? Si par exemple le serveur de base de
données a redémarré...
Que se passe-t'il si on tente de faire une requête dans ce cas ?
Une exception est levée,
Donc, il suffit de tenter d'exécuter une requête, et de regarder si ça
lève une exception, non ?-)
NB: si je jette un coup d'oeil dans le pep 249, je trouve ça:
"""
OperationalError
Exception raised for errors that are related to the
database's operation and not necessarily under the control
of the programmer, e.g. *an unexpected disconnect occurs*,
the data source name is not found, a transaction could not
be processed, a memory allocation error occurred during
processing, etc. It must be a subclass of DatabaseError.
InternalError
Exception raised when the database encounters an internal
error, e.g. *the cursor is not valid anymore*, the
transaction is out of sync, etc. It must be a subclass of
DatabaseError.
"""
mais ça ne me dit pas si je dois redemander une
connexion et relancer la requete.
Bin, ça, c'est à ton programme de gérer le problème.
Plus sérieusement: si je comprend bien, ton problème est de déterminer
si l'exception qui est levée est bien liée à une coupure momentanée de
la connection, ou à un autre problème. Je viens de parcourir le pep 249
sans trouver grand chose à ce propos. Bref, à part retenter une
connection + requête, et regarder si tu a une exception similaire (même
type et même message), je ne vois pas trop...
Comment peut-on reconnaitre d'une manière générique qu'une connection a une base de données est fermée ? Si par exemple le serveur de base de données a redémarré...
Que se passe-t'il si on tente de faire une requête dans ce cas ?
Une exception est levée,
Donc, il suffit de tenter d'exécuter une requête, et de regarder si ça lève une exception, non ?-)
NB: si je jette un coup d'oeil dans le pep 249, je trouve ça:
""" OperationalError
Exception raised for errors that are related to the database's operation and not necessarily under the control of the programmer, e.g. *an unexpected disconnect occurs*, the data source name is not found, a transaction could not be processed, a memory allocation error occurred during processing, etc. It must be a subclass of DatabaseError.
InternalError
Exception raised when the database encounters an internal error, e.g. *the cursor is not valid anymore*, the transaction is out of sync, etc. It must be a subclass of DatabaseError. """
mais ça ne me dit pas si je dois redemander une connexion et relancer la requete.
Bin, ça, c'est à ton programme de gérer le problème.
Plus sérieusement: si je comprend bien, ton problème est de déterminer si l'exception qui est levée est bien liée à une coupure momentanée de la connection, ou à un autre problème. Je viens de parcourir le pep 249 sans trouver grand chose à ce propos. Bref, à part retenter une connection + requête, et regarder si tu a une exception similaire (même type et même message), je ne vois pas trop...
Désolé.
William Dode
On 25-04-2006, Bruno Desthuilliers wrote:
On 24-04-2006, bruno at modulix wrote:
William Dode wrote:
slt,
Comment peut-on reconnaitre d'une manière générique qu'une connection a une base de données est fermée ? Si par exemple le serveur de base de données a redémarré...
Que se passe-t'il si on tente de faire une requête dans ce cas ?
Une exception est levée,
Donc, il suffit de tenter d'exécuter une requête, et de regarder si ça lève une exception, non ?-)
NB: si je jette un coup d'oeil dans le pep 249, je trouve ça:
""" OperationalError
Exception raised for errors that are related to the database's operation and not necessarily under the control of the programmer, e.g. *an unexpected disconnect occurs*, the data source name is not found, a transaction could not be processed, a memory allocation error occurred during processing, etc. It must be a subclass of DatabaseError.
InternalError
Exception raised when the database encounters an internal error, e.g. *the cursor is not valid anymore*, the transaction is out of sync, etc. It must be a subclass of DatabaseError. """
mais ça ne me dit pas si je dois redemander une connexion et relancer la requete.
Bin, ça, c'est à ton programme de gérer le problème.
Plus sérieusement: si je comprend bien, ton problème est de déterminer si l'exception qui est levée est bien liée à une coupure momentanée de la connection, ou à un autre problème. Je viens de parcourir le pep 249 sans trouver grand chose à ce propos. Bref, à part retenter une connection + requête, et regarder si tu a une exception similaire (même type et même message), je ne vois pas trop...
Ce qui est dommage c'est que quand l'exception est levée, dans pyscopg, il m'indique bien "la connection est fermée"... Je vais peut-être aller fouiller dans le source pour voir si je ne peux pas retrouver cette info quelque part...
Désolé.
Ce que je trouve curieux c'est qu'il ne semble pas que d'autres personnes se préocupent de ça, alors que ça me parait assez classique comme problème non ?
-- William Dodé - http://flibuste.net
On 25-04-2006, Bruno Desthuilliers wrote:
On 24-04-2006, bruno at modulix wrote:
William Dode wrote:
slt,
Comment peut-on reconnaitre d'une manière générique qu'une connection a
une base de données est fermée ? Si par exemple le serveur de base de
données a redémarré...
Que se passe-t'il si on tente de faire une requête dans ce cas ?
Une exception est levée,
Donc, il suffit de tenter d'exécuter une requête, et de regarder si ça
lève une exception, non ?-)
NB: si je jette un coup d'oeil dans le pep 249, je trouve ça:
"""
OperationalError
Exception raised for errors that are related to the
database's operation and not necessarily under the control
of the programmer, e.g. *an unexpected disconnect occurs*,
the data source name is not found, a transaction could not
be processed, a memory allocation error occurred during
processing, etc. It must be a subclass of DatabaseError.
InternalError
Exception raised when the database encounters an internal
error, e.g. *the cursor is not valid anymore*, the
transaction is out of sync, etc. It must be a subclass of
DatabaseError.
"""
mais ça ne me dit pas si je dois redemander une
connexion et relancer la requete.
Bin, ça, c'est à ton programme de gérer le problème.
Plus sérieusement: si je comprend bien, ton problème est de déterminer
si l'exception qui est levée est bien liée à une coupure momentanée de
la connection, ou à un autre problème. Je viens de parcourir le pep 249
sans trouver grand chose à ce propos. Bref, à part retenter une
connection + requête, et regarder si tu a une exception similaire (même
type et même message), je ne vois pas trop...
Ce qui est dommage c'est que quand l'exception est levée, dans pyscopg,
il m'indique bien "la connection est fermée"... Je vais peut-être aller
fouiller dans le source pour voir si je ne peux pas retrouver cette info
quelque part...
Désolé.
Ce que je trouve curieux c'est qu'il ne semble pas que d'autres
personnes se préocupent de ça, alors que ça me parait assez classique
comme problème non ?
Comment peut-on reconnaitre d'une manière générique qu'une connection a une base de données est fermée ? Si par exemple le serveur de base de données a redémarré...
Que se passe-t'il si on tente de faire une requête dans ce cas ?
Une exception est levée,
Donc, il suffit de tenter d'exécuter une requête, et de regarder si ça lève une exception, non ?-)
NB: si je jette un coup d'oeil dans le pep 249, je trouve ça:
""" OperationalError
Exception raised for errors that are related to the database's operation and not necessarily under the control of the programmer, e.g. *an unexpected disconnect occurs*, the data source name is not found, a transaction could not be processed, a memory allocation error occurred during processing, etc. It must be a subclass of DatabaseError.
InternalError
Exception raised when the database encounters an internal error, e.g. *the cursor is not valid anymore*, the transaction is out of sync, etc. It must be a subclass of DatabaseError. """
mais ça ne me dit pas si je dois redemander une connexion et relancer la requete.
Bin, ça, c'est à ton programme de gérer le problème.
Plus sérieusement: si je comprend bien, ton problème est de déterminer si l'exception qui est levée est bien liée à une coupure momentanée de la connection, ou à un autre problème. Je viens de parcourir le pep 249 sans trouver grand chose à ce propos. Bref, à part retenter une connection + requête, et regarder si tu a une exception similaire (même type et même message), je ne vois pas trop...
Ce qui est dommage c'est que quand l'exception est levée, dans pyscopg, il m'indique bien "la connection est fermée"... Je vais peut-être aller fouiller dans le source pour voir si je ne peux pas retrouver cette info quelque part...
Désolé.
Ce que je trouve curieux c'est qu'il ne semble pas que d'autres personnes se préocupent de ça, alors que ça me parait assez classique comme problème non ?
-- William Dodé - http://flibuste.net
Méta-MCI
Bonjour !
Ce que je trouve curieux c'est qu'il ne semble pas que d'autres personnes se préoccupent de ça, alors que ça me parait assez classique comme problème non ?
Effectivement. Mais, il y a tellement de cas différents...
Déjà, tu supposes ignorer le mode "déconnecté". Or cette façon de travailler est assez à la mode. Dans le mode déconnecté, la connexion est coupée, entre chaque requête, et rétablie au besoin. Dans ce cas une coupure ponctuelle peut très bien être sans effets, si elle est restaurée à temps. A contrario, dans le mode connecté, la connexion est permanente. En cas de coupure, cela provoque une erreur, même si le système client ne fait rien.
Par exemple, DAO travaille en mode déconnecté. Les connections ODBC peuvent travailler dans les deux modes, selon le driver. Perso, je travaille souvent avec un connecteur peu connu, appelé SQL-link. Ce connecteur travaille en mode connecté, ce qui a pour résultat d'être quatre ou cinq fois plus rapide qu'ODBC, mais est plus sensible aux ruptures de connexion. Du coup, je gère par programme les déconnections/reconnections.
Un autre aspect, c'est de savoir si le système SGBD utilisé supporte ou non le transactionnel (avec persistance des transactions), et/ou la journalisation.
Cependant, je suis assez d'accord avec le manque d'intérêt manifesté pour ce domaine, dans les newsgroups et autres forums. Il faut croire qu'il n'y a pas beaucoup de monde qui travaille dans les projets de gestion en entreprise...
@-salutations
Michel Claveau
Bonjour !
Ce que je trouve curieux c'est qu'il ne semble pas que d'autres
personnes se préoccupent de ça, alors que ça me parait assez classique
comme problème non ?
Effectivement. Mais, il y a tellement de cas différents...
Déjà, tu supposes ignorer le mode "déconnecté". Or cette façon de travailler
est assez à la mode. Dans le mode déconnecté, la connexion est coupée, entre
chaque requête, et rétablie au besoin. Dans ce cas une coupure ponctuelle
peut très bien être sans effets, si elle est restaurée à temps.
A contrario, dans le mode connecté, la connexion est permanente. En cas de
coupure, cela provoque une erreur, même si le système client ne fait rien.
Par exemple, DAO travaille en mode déconnecté. Les connections ODBC peuvent
travailler dans les deux modes, selon le driver. Perso, je travaille souvent
avec un connecteur peu connu, appelé SQL-link. Ce connecteur travaille en
mode connecté, ce qui a pour résultat d'être quatre ou cinq fois plus rapide
qu'ODBC, mais est plus sensible aux ruptures de connexion. Du coup, je gère
par programme les déconnections/reconnections.
Un autre aspect, c'est de savoir si le système SGBD utilisé supporte ou non
le transactionnel (avec persistance des transactions), et/ou la
journalisation.
Cependant, je suis assez d'accord avec le manque d'intérêt manifesté pour ce
domaine, dans les newsgroups et autres forums. Il faut croire qu'il n'y a
pas beaucoup de monde qui travaille dans les projets de gestion en
entreprise...
Ce que je trouve curieux c'est qu'il ne semble pas que d'autres personnes se préoccupent de ça, alors que ça me parait assez classique comme problème non ?
Effectivement. Mais, il y a tellement de cas différents...
Déjà, tu supposes ignorer le mode "déconnecté". Or cette façon de travailler est assez à la mode. Dans le mode déconnecté, la connexion est coupée, entre chaque requête, et rétablie au besoin. Dans ce cas une coupure ponctuelle peut très bien être sans effets, si elle est restaurée à temps. A contrario, dans le mode connecté, la connexion est permanente. En cas de coupure, cela provoque une erreur, même si le système client ne fait rien.
Par exemple, DAO travaille en mode déconnecté. Les connections ODBC peuvent travailler dans les deux modes, selon le driver. Perso, je travaille souvent avec un connecteur peu connu, appelé SQL-link. Ce connecteur travaille en mode connecté, ce qui a pour résultat d'être quatre ou cinq fois plus rapide qu'ODBC, mais est plus sensible aux ruptures de connexion. Du coup, je gère par programme les déconnections/reconnections.
Un autre aspect, c'est de savoir si le système SGBD utilisé supporte ou non le transactionnel (avec persistance des transactions), et/ou la journalisation.
Cependant, je suis assez d'accord avec le manque d'intérêt manifesté pour ce domaine, dans les newsgroups et autres forums. Il faut croire qu'il n'y a pas beaucoup de monde qui travaille dans les projets de gestion en entreprise...
@-salutations
Michel Claveau
William Dode
On 27-04-2006, Méta-MCI wrote:
Bonjour !
Ce que je trouve curieux c'est qu'il ne semble pas que d'autres personnes se préoccupent de ça, alors que ça me parait assez classique comme problème non ?
Effectivement. Mais, il y a tellement de cas différents...
Déjà, tu supposes ignorer le mode "déconnecté". Or cette façon de travailler est assez à la mode. Dans le mode déconnecté, la connexion est coupée, entre chaque requête, et rétablie au besoin. Dans ce cas une coupure ponctuelle peut très bien être sans effets, si elle est restaurée à temps.
Je ne l'ignore pas, justement je cherche à le reconaitre ! Mais je ne veux pas non plus fermer la connexion entre chaque requetes ça serait beaucoup trop couteux.
A contrario, dans le mode connecté, la connexion est permanente. En cas de coupure, cela provoque une erreur, même si le système client ne fait rien.
Par exemple, DAO travaille en mode déconnecté. Les connections ODBC peuvent travailler dans les deux modes, selon le driver. Perso, je travaille souvent avec un connecteur peu connu, appelé SQL-link. Ce connecteur travaille en mode connecté, ce qui a pour résultat d'être quatre ou cinq fois plus rapide qu'ODBC, mais est plus sensible aux ruptures de connexion. Du coup, je gère par programme les déconnections/reconnections.
Un autre aspect, c'est de savoir si le système SGBD utilisé supporte ou non le transactionnel (avec persistance des transactions), et/ou la journalisation.
Cependant, je suis assez d'accord avec le manque d'intérêt manifesté pour ce domaine, dans les newsgroups et autres forums. Il faut croire qu'il n'y a pas beaucoup de monde qui travaille dans les projets de gestion en entreprise...
@-salutations
Michel Claveau
-- William Dodé - http://flibuste.net
On 27-04-2006, Méta-MCI wrote:
Bonjour !
Ce que je trouve curieux c'est qu'il ne semble pas que d'autres
personnes se préoccupent de ça, alors que ça me parait assez classique
comme problème non ?
Effectivement. Mais, il y a tellement de cas différents...
Déjà, tu supposes ignorer le mode "déconnecté". Or cette façon de travailler
est assez à la mode. Dans le mode déconnecté, la connexion est coupée, entre
chaque requête, et rétablie au besoin. Dans ce cas une coupure ponctuelle
peut très bien être sans effets, si elle est restaurée à temps.
Je ne l'ignore pas, justement je cherche à le reconaitre ! Mais je ne
veux pas non plus fermer la connexion entre chaque requetes ça serait
beaucoup trop couteux.
A contrario, dans le mode connecté, la connexion est permanente. En cas de
coupure, cela provoque une erreur, même si le système client ne fait rien.
Par exemple, DAO travaille en mode déconnecté. Les connections ODBC peuvent
travailler dans les deux modes, selon le driver. Perso, je travaille souvent
avec un connecteur peu connu, appelé SQL-link. Ce connecteur travaille en
mode connecté, ce qui a pour résultat d'être quatre ou cinq fois plus rapide
qu'ODBC, mais est plus sensible aux ruptures de connexion. Du coup, je gère
par programme les déconnections/reconnections.
Un autre aspect, c'est de savoir si le système SGBD utilisé supporte ou non
le transactionnel (avec persistance des transactions), et/ou la
journalisation.
Cependant, je suis assez d'accord avec le manque d'intérêt manifesté pour ce
domaine, dans les newsgroups et autres forums. Il faut croire qu'il n'y a
pas beaucoup de monde qui travaille dans les projets de gestion en
entreprise...
Ce que je trouve curieux c'est qu'il ne semble pas que d'autres personnes se préoccupent de ça, alors que ça me parait assez classique comme problème non ?
Effectivement. Mais, il y a tellement de cas différents...
Déjà, tu supposes ignorer le mode "déconnecté". Or cette façon de travailler est assez à la mode. Dans le mode déconnecté, la connexion est coupée, entre chaque requête, et rétablie au besoin. Dans ce cas une coupure ponctuelle peut très bien être sans effets, si elle est restaurée à temps.
Je ne l'ignore pas, justement je cherche à le reconaitre ! Mais je ne veux pas non plus fermer la connexion entre chaque requetes ça serait beaucoup trop couteux.
A contrario, dans le mode connecté, la connexion est permanente. En cas de coupure, cela provoque une erreur, même si le système client ne fait rien.
Par exemple, DAO travaille en mode déconnecté. Les connections ODBC peuvent travailler dans les deux modes, selon le driver. Perso, je travaille souvent avec un connecteur peu connu, appelé SQL-link. Ce connecteur travaille en mode connecté, ce qui a pour résultat d'être quatre ou cinq fois plus rapide qu'ODBC, mais est plus sensible aux ruptures de connexion. Du coup, je gère par programme les déconnections/reconnections.
Un autre aspect, c'est de savoir si le système SGBD utilisé supporte ou non le transactionnel (avec persistance des transactions), et/ou la journalisation.
Cependant, je suis assez d'accord avec le manque d'intérêt manifesté pour ce domaine, dans les newsgroups et autres forums. Il faut croire qu'il n'y a pas beaucoup de monde qui travaille dans les projets de gestion en entreprise...
