Bien mal m'en a pris, j'ai voulu utiliser Windev 10 fois plus vite ;)
J'ai commencé un projet Windev 8 + Oracle 8 (+accès natif) et j'ai
voulu utiliser pour simplifier les combos auto alimentées, les ordres
hlit, hajoute etc...
Bon ça marche à peu près (tant qu'on se repositionne avant
d'enregistrer), mais maintenant que c'est en prod et que l'utilisation
est plus intensive, régulièrement, paf, nombre maximum de curseurs
ouverts!
et pour cause, j'ai vérifié dans oracle, à chaque ordre différent sur
les tables, windev ouvre un curseur tout neuf, et ne le referme pas
(dans le cas d'un insert par exemple, aucun interêt de garder le
curseur), et au bout d'un moment, on atteint le nombre max de curseurs
ouvrables...
Evidemment le support technique n'a aucune solution à m'apporter en
dehors de "envoyez nous les tables et le code", ce qui ne changera
rien, ya pas besoin de 150 tables différentes pour tester ça...
Bref, avez vous une idée avant que je doive tout réécrire en SQL (et
perdre des semaines)...
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
Emmanuel Lecoester
"Gilles G." a écrit dans le message de news:
Hello!
Bien mal m'en a pris, j'ai voulu utiliser Windev 10 fois plus vite ;)
J'ai commencé un projet Windev 8 + Oracle 8 (+accès natif) et j'ai voulu utiliser pour simplifier les combos auto alimentées, les ordres hlit, hajoute etc...
Bon ça marche à peu près (tant qu'on se repositionne avant d'enregistrer), mais maintenant que c'est en prod et que l'utilisation est plus intensive, régulièrement, paf, nombre maximum de curseurs ouverts!
solution simple, tu passes le max_open_cursors à 50000 :-)
"Gilles G." <debians@gmail.com> a écrit dans le message de
news:mn.24eb7d51607955ff.21586@gmail.com...
Hello!
Bien mal m'en a pris, j'ai voulu utiliser Windev 10 fois plus vite ;)
J'ai commencé un projet Windev 8 + Oracle 8 (+accès natif) et j'ai
voulu utiliser pour simplifier les combos auto alimentées, les ordres
hlit, hajoute etc...
Bon ça marche à peu près (tant qu'on se repositionne avant
d'enregistrer), mais maintenant que c'est en prod et que l'utilisation
est plus intensive, régulièrement, paf, nombre maximum de curseurs
ouverts!
solution simple, tu passes le max_open_cursors à 50000 :-)
Bien mal m'en a pris, j'ai voulu utiliser Windev 10 fois plus vite ;)
J'ai commencé un projet Windev 8 + Oracle 8 (+accès natif) et j'ai voulu utiliser pour simplifier les combos auto alimentées, les ordres hlit, hajoute etc...
Bon ça marche à peu près (tant qu'on se repositionne avant d'enregistrer), mais maintenant que c'est en prod et que l'utilisation est plus intensive, régulièrement, paf, nombre maximum de curseurs ouverts!
solution simple, tu passes le max_open_cursors à 50000 :-)
tjfromparis
hum.... il me semble qu'un paramètre de la base Oracle permet de fermer les curseurs.
Le probleme est tjs d'actu ? si oui je poserai la question a qq DBA.
"Emmanuel Lecoester" a écrit dans le message de news: 41dafc6b$0$10274$
"Gilles G." a écrit dans le message de news:
Hello!
Bien mal m'en a pris, j'ai voulu utiliser Windev 10 fois plus vite ;)
J'ai commencé un projet Windev 8 + Oracle 8 (+accès natif) et j'ai voulu utiliser pour simplifier les combos auto alimentées, les ordres hlit, hajoute etc...
Bon ça marche à peu près (tant qu'on se repositionne avant d'enregistrer), mais maintenant que c'est en prod et que l'utilisation est plus intensive, régulièrement, paf, nombre maximum de curseurs ouverts!
solution simple, tu passes le max_open_cursors à 50000 :-)
hum.... il me semble qu'un paramètre de la base Oracle permet de fermer les
curseurs.
Le probleme est tjs d'actu ?
si oui je poserai la question a qq DBA.
"Emmanuel Lecoester" <elecoest@netcourrier.com> a écrit dans le message de
news: 41dafc6b$0$10274$626a14ce@news.free.fr...
"Gilles G." <debians@gmail.com> a écrit dans le message de
news:mn.24eb7d51607955ff.21586@gmail.com...
Hello!
Bien mal m'en a pris, j'ai voulu utiliser Windev 10 fois plus vite ;)
J'ai commencé un projet Windev 8 + Oracle 8 (+accès natif) et j'ai
voulu utiliser pour simplifier les combos auto alimentées, les ordres
hlit, hajoute etc...
Bon ça marche à peu près (tant qu'on se repositionne avant
d'enregistrer), mais maintenant que c'est en prod et que l'utilisation
est plus intensive, régulièrement, paf, nombre maximum de curseurs
ouverts!
solution simple, tu passes le max_open_cursors à 50000 :-)
hum.... il me semble qu'un paramètre de la base Oracle permet de fermer les curseurs.
Le probleme est tjs d'actu ? si oui je poserai la question a qq DBA.
"Emmanuel Lecoester" a écrit dans le message de news: 41dafc6b$0$10274$
"Gilles G." a écrit dans le message de news:
Hello!
Bien mal m'en a pris, j'ai voulu utiliser Windev 10 fois plus vite ;)
J'ai commencé un projet Windev 8 + Oracle 8 (+accès natif) et j'ai voulu utiliser pour simplifier les combos auto alimentées, les ordres hlit, hajoute etc...
Bon ça marche à peu près (tant qu'on se repositionne avant d'enregistrer), mais maintenant que c'est en prod et que l'utilisation est plus intensive, régulièrement, paf, nombre maximum de curseurs ouverts!
solution simple, tu passes le max_open_cursors à 50000 :-)
Manu
"tjfromparis" wrote in message news:41db082a$0$385$
hum.... il me semble qu'un paramètre de la base Oracle permet de fermer
les
curseurs.
Le probleme est tjs d'actu ? si oui je poserai la question a qq DBA.
désolé, je ne connais pas. La seule chose que je connaisse la dessus ce sont les paramètres de compilation en pro*c pour que les curseurs se ferment en automatique.
sinon le max_open_cursors fonctionne bien
"tjfromparis" <tjfromparis@ifrance.com> wrote in message
news:41db082a$0$385$636a15ce@news.free.fr...
hum.... il me semble qu'un paramètre de la base Oracle permet de fermer
les
curseurs.
Le probleme est tjs d'actu ?
si oui je poserai la question a qq DBA.
désolé, je ne connais pas. La seule chose que je connaisse la dessus ce sont
les paramètres de compilation en pro*c pour que les curseurs se ferment en
automatique.
"tjfromparis" wrote in message news:41db082a$0$385$
hum.... il me semble qu'un paramètre de la base Oracle permet de fermer
les
curseurs.
Le probleme est tjs d'actu ? si oui je poserai la question a qq DBA.
désolé, je ne connais pas. La seule chose que je connaisse la dessus ce sont les paramètres de compilation en pro*c pour que les curseurs se ferment en automatique.
sinon le max_open_cursors fonctionne bien
Ted
Gilles G. écrivait news:mn.24eb7d51607955ff.21586 @gmail.com:
Bref, avez vous une id‚e avant que je doive tout r‚‚crire en SQL
Salut,
Fait régulièrement des HFerme() sur les tables plus utilisées, des HAnnuleDéclaration sur les requêtes plus utilisées, cela devrait libérer les curseurs associés.
-- En esperant t'avoir aidé.
Gilles G. <debians@gmail.com> écrivait news:mn.24eb7d51607955ff.21586
@gmail.com:
Bref, avez vous une id‚e avant que je doive tout r‚‚crire en SQL
Salut,
Fait régulièrement des HFerme() sur les tables plus utilisées, des
HAnnuleDéclaration sur les requêtes plus utilisées, cela devrait libérer
les curseurs associés.
Gilles G. écrivait news:mn.24eb7d51607955ff.21586 @gmail.com:
Bref, avez vous une id‚e avant que je doive tout r‚‚crire en SQL
Salut,
Fait régulièrement des HFerme() sur les tables plus utilisées, des HAnnuleDéclaration sur les requêtes plus utilisées, cela devrait libérer les curseurs associés.
-- En esperant t'avoir aidé.
Gilles G.
tjfromparis a présenté l'énoncé suivant :
hum.... il me semble qu'un paramètre de la base Oracle permet de fermer les curseurs.
Le probleme est tjs d'actu ? si oui je poserai la question a qq DBA.
Il est méchemment d'actu
J'ai viré TOUTES les tables autoalimentées pour tout passer en tables mémoires, et périodiquement je vais une requête sur les vues systèmes et si le nombre de curseur atteint une valeur critique je ferme et rouvre la connexion...
Mais ca me gonfle que PCSoft soit incapable de faire la différence entre Hyperfile et une vraie base de données avec les contraintes associées!
tjfromparis a présenté l'énoncé suivant :
hum.... il me semble qu'un paramètre de la base Oracle permet de fermer les
curseurs.
Le probleme est tjs d'actu ?
si oui je poserai la question a qq DBA.
Il est méchemment d'actu
J'ai viré TOUTES les tables autoalimentées pour tout passer en tables
mémoires, et périodiquement je vais une requête sur les vues systèmes
et si le nombre de curseur atteint une valeur critique je ferme et
rouvre la connexion...
Mais ca me gonfle que PCSoft soit incapable de faire la différence
entre Hyperfile et une vraie base de données avec les contraintes
associées!
hum.... il me semble qu'un paramètre de la base Oracle permet de fermer les curseurs.
Le probleme est tjs d'actu ? si oui je poserai la question a qq DBA.
Il est méchemment d'actu
J'ai viré TOUTES les tables autoalimentées pour tout passer en tables mémoires, et périodiquement je vais une requête sur les vues systèmes et si le nombre de curseur atteint une valeur critique je ferme et rouvre la connexion...
Mais ca me gonfle que PCSoft soit incapable de faire la différence entre Hyperfile et une vraie base de données avec les contraintes associées!
Gilles G.
Il se trouve que Manu a formulé :
"tjfromparis" wrote in message news:41db082a$0$385$
hum.... il me semble qu'un paramètre de la base Oracle permet de fermer les curseurs.
Le probleme est tjs d'actu ? si oui je poserai la question a qq DBA.
désolé, je ne connais pas. La seule chose que je connaisse la dessus ce sont les paramètres de compilation en pro*c pour que les curseurs se ferment en automatique.
sinon le max_open_cursors fonctionne bien
oui mais ca n'a aucune incidence sur la conso mémoire de la base? Le serveur ne va pas finir par exploser?
Il se trouve que Manu a formulé :
"tjfromparis" <tjfromparis@ifrance.com> wrote in message
news:41db082a$0$385$636a15ce@news.free.fr...
hum.... il me semble qu'un paramètre de la base Oracle permet de fermer les
curseurs.
Le probleme est tjs d'actu ?
si oui je poserai la question a qq DBA.
désolé, je ne connais pas. La seule chose que je connaisse la dessus ce sont
les paramètres de compilation en pro*c pour que les curseurs se ferment en
automatique.
sinon le max_open_cursors fonctionne bien
oui mais ca n'a aucune incidence sur la conso mémoire de la base?
Le serveur ne va pas finir par exploser?
"tjfromparis" wrote in message news:41db082a$0$385$
hum.... il me semble qu'un paramètre de la base Oracle permet de fermer les curseurs.
Le probleme est tjs d'actu ? si oui je poserai la question a qq DBA.
désolé, je ne connais pas. La seule chose que je connaisse la dessus ce sont les paramètres de compilation en pro*c pour que les curseurs se ferment en automatique.
sinon le max_open_cursors fonctionne bien
oui mais ca n'a aucune incidence sur la conso mémoire de la base? Le serveur ne va pas finir par exploser?
