Au travail, nous devons faire face à plusieurs fichiers MDB d'accès MS Access, nous utilisons donc le pilote JDBCodbcbridge par défaut fourni avec le Sun JVM et, pour la plupart des cas, cela fonctionne bien.
Le problème est que lorsque nous devons faire face à des fichiers plus grands, nous sommes confrontés plusieurs fois des exceptions avec le message "Impossible d'ouvrir plus de tables". Comment pouvons-nous éviter ça?
Nous fermons déjà tous nos instances de prépuissances et de recumettes, et même définir leurs variables à NULL, mais même cette exception continue de se produire. Que devrions nous faire? Comment pouvons-nous éviter ces mauvaises exceptions? Est-ce que quelqu'un ici sait comment?
Y a-t-il une configuration supplémentaire aux pilotes ODBC sous Windows que nous pouvons changer pour éviter ce problème?
5 Réponses :
Vous devez également fermer votre objet de connexion.
regarder dans une alternative pour le pilote JDBC ODBC serait également une bonne idée. Vous n'avez aucune expérience avec une alternative moi-même, mais ce serait un bon endroit pour commencer:
Existe-t-il une alternative à l'utilisation de Sun.JDBC .ODBC.JDBCODBCDRIVER?
Je conviens que le pilote JDBCODBC est loin d'être bon. Nous sommes confrontés à beaucoup de nombreux problèmes avec elle quotidiennement. Malheureusement, nous avons des restrictions budgétaires qui ne nous permettent pas d'acheter un autre pilote alternatif :( et nous fermons actuellement toutes les connexions. Qu'est-ce qui me fait chier à ce sujet, c'est que dans ce cas, nous faisons tout exactement comme tous les livres (nous J'espère que les marchandises :)) disent!
Il y a une chance extérieure que vous manquez simplement de connexions réseau gratuites. Nous avons eu ce problème sur un système occupé au travail.
Quelque chose à noter est que les connexions réseau, bien que fermées, ne peuvent pas libérer la prise avant le temps de la collecte des ordures. Vous pouvez vérifier cela avec netstat / A / N / P TCP . Si vous avez beaucoup de connexions dans l'état TIME_WAIT , vous pouvez essayer de forcer une collection à ordures sur la connexion se ferme ou peut-être des intervalles réguliers.
Très bon conseil! Je vais vérifier cela. En réalité, j'ai toujours défini mes instances de connexion, préparé et résultatsset tout en travaillant avec l'accès à NULL exactement parce que le JDBCODBCDRIVER ne les ferme pas si elles ne sont pas nulles. J'ai vérifié cela avec quelques expériences de notre société. Mais ce qui m'améliore, c'est le fait qu'aucun patch ne soit fait pour cette question.
"Impossible d'ouvrir plus de tables" est un meilleur message d'erreur que "Impossible d'ouvrir plus de bases de données", ce qui est plus fréquemment rencontré dans mon expérience. En fait, ce dernier message masquait presque toujours l'ancien.
Le moteur de base de données JET 4 a une limite de 2048 Table poignées em>. Ce n'est pas tout à fait clair pour moi si cela est simultané ou cumulatif dans la vie d'une connexion. J'ai toujours supposé que c'est cumulatif, car l'ouverture de moins de joints à une époque dans la pratique semble permettre d'éviter le problème. P> Le problème est que "Poignées de table" ne fait que référence à la table gère, mais à quelque chose de beaucoup plus. p> Considérez un queryDef sauvegardé avec ce SQL: p> exécuté que querydef utilise deux poignées de table. P> Quoi ?, Vous pourriez demander? Il utilise seulement une table! Mais Jet utilise une poignée de table pour la table et une poignée de table pour le queryDef sauvegardé. P> Ainsi, si vous avez un querydef comme ceci: p> ... Si chacune de vos requêtes de source a deux tables, vous utilisez ces poignées de table, une pour chacune: P> rs.Close ' closes the recordset
Set rs = Nothing ' clears the pointer to the memory formerly used by it
db.Close
Set db = Nothing
David, c'est une explication géniale sur cette question! Merci beaucoup!
En fait, JET4 fonctionne-t-il avec accès 97? Est-il possible de configurer le nombre de poignées de base de données que je peux utiliser avec Jet? Si oui, comment devrais-je faire ça?
A97 utilise uniquement Jet 3.5, mais aussi longtemps que vous avez la dernière version de service de Jet 3.5, elle a la même limite que JET 4.0. Ce n'est pas configurable par l'utilisateur - il s'agit d'une limite supérieure.
J'ai eu le même problème mais rien de ce qui précède ne fonctionnait. Je étant éventuellement sur la question. J'utilisais cela pour lire la valeur d'un formulaire pour remettre à une source d'enregistrement de liste de recherche.
LocationCode = Forms("Support")("LocationCode")
ContactCode = Forms("Support")("TakenFrom")
Récemment, j'ai essayé UcanAccess - un pilote PURE Java JDBC pour l'accès MS. Départ: http://sourceforge.net/projects/ucanaccess/ - fonctionne aussi sur Linux; - ) Pour charger les bibliothèques requises, un certain temps est nécessaire. Je ne l'ai pas testé pour plus que des fins en lecture seule.
Quoi qu'il en soit, j'ai eu des problèmes comme décrit ci-dessus avec le Sun.JDBC.ODBC.JDBCODBCDRIVER. Après avoir ajouté des relevés Fermer () après la création d'objets d'instruction (et des appels à exécuterUpdate sur ceux) ainsi que des états System.gc (), les messages d'erreur ont cessé; -)