Discussion :

[Zugg]

Bonjour,

j'ai un soucis avec la fermeture de Paradox.
J'ai une appli qui ouvre une base de données en Paradox via le BDE. Lorsque je ferme la base par :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

bdParadox.Connected := false;

j'ai encore des handles ouvert sur le répertoire de la base Paradox.(handles que j'ai vu par ProcessExplorer de Sysinternals)

Le problème c'est que je ne peux pas supprimer ce répertoire tant que mon appli est ouverte. Or il faut que mon appli reste ouverte et que je puisse supprimer le répertoire aussi.

donc j'aimerai savoir s'il n'y a pas un moyen de bien fermer tous les handles utilisés lors d'une connexion Paradox.

Merci.

[TicTacToe]

pb de verrouillage, je les ai eu aussi
notemment sur des rép. pour des tables temporaires.

Si c'est pour des tables temporaires également, voic comment je procède

je créé un dossier tempoaire nommé différement à chaque fois, pour pouvoir le supprimer lorsque mon appli se lance la fois suivante. C'est pas super propre, mais c'est efficace, pour vider régulierement les table tmp...

Je demarre session1
Dossier1 créé
je quitte session 1
Dossier1 reste (car toujours verouillé tant que l'appli est ouverte, meme database fermée)

Je démarre Session2 (éventuellement le lendemain)
Dossier2 créé
Destruction de tous les autres DossierX (donc de Dossier1)
...
ainsi de suite.

Ca a par contre l'avantage de pouvoir lancer plusieurs sessions de mon prog sur le même poste, avec bien sur des tables temporaires différentes et indépendantes...

Sinon, une autre solution, consisterait un prog [Vidage] à la fermeture de ton prog principal (mais attention a ce que [Vidage] attende bien la fin du prog principal avant destruction du rep...., bref pas forcément + facile et + joli...

Je ne sais pas si j'ai répondu à ta question finalement !

[Zugg]

Merci pour cette solution.
J'avais pensé faire qqch comme ça mais le soucis c'est que mon appli est un service donc pas d'arrêt facile . L'appli peut tourner très lentement avant qu'il y ait un redémarrage de la machine (pour libérer les verrous sur les répertoires) et donc je peux avoir bcp de répertoires...

Sinon j'ai l'impression que le verrouillage sur les répertoires n'a lieu que sur des bases paradox qui possèdent des index.

Autre remarque, pour la suppression de répertoire j'utilise le fonction RemoveDir qui appelle la fonction Windows RemoveDirectoryA et apparemment cette fonction ne supprime pas le répertoire mais le marque pour suppression et si aucun handle n'est ouvert sur ce répertoire alors il sera supprimé sinon il reste tant que des handles sont ouverts dessus.
Donc éxiste-t-il une fonction qui peut forcer la suppression d'un répertoire sur lequel des handles sont encore ouvert ?

En attentant je ne vais pas faire de suppression de ce répertoire je vais essayer de le réutiliser à chaque fois mais c'est pas très propre je trouve....

[TicTacToe]

Il existe des prog pour forcer la suppression de fichier lockés, mais il faut que les fichiers verrouillés en question soient en local / au progr qui verouille, ainsi que ton prog de déverouillage.

Par exemple, un client qui lance le prog, qui créé un dossier temp, ne pourra pas forcer le déverouillage car ce verouillage n'est pas géré par le client, mais par le serveur de fichier...

Donc dans ton cas, je ne vois que l'arret du service, l'appel a un prog [vidage], suppression des dossiers, puis redémarrage du service

Je ne sais pas comment ca se passe au niveau des services, mais théoriquement, l'arret du service, déchargera ton executable de la mémoire donc tous les verrous seront lachés... enfin je pense :

[Zugg]

Je ne sais pas comment ca se passe au niveau des services, mais théoriquement, l'arret du service, déchargera ton executable de la mémoire donc tous les verrous seront lachés... enfin je pense :

oui tout a fait seul l'arrêt du service permet de libérer les répertoires, mais on ne peut pas demander l'arrêt du service tout le temps. donc je ne vois qu'une solution pour l'instant : ne pas supprimer les répertoires et essayer de les réutiliser au maximum...

merci quand même....