Ouvrir un fichier sans le "locker" avec les FSO

**kacedda** · 28/05/2008, 09h58

Bonjour,

J'ecris(mode append) dans un fichier en utilisant les FSO.
Jusque la pas de probleme, je l'ouvre, je rajoute mes lignes et je le ferme.

Le soucis c'est que parfois, je quitte mon script sans refermer le fichier, du coup quand je relance mon script je n'arrive plus à l'ouvrir car forcement quelqu'un l'a ouvert et ne la pas rendu.

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
Const ForAppend = 8
Dim fso, f
 
Set fso = CreateObject("Scripting.FileSystemObject")
Set f = fso.OpenTextFile("c:\temp\ecr.txt", ForAppend,true)
 
Do While MaCondition
 
f.write("quelque chose")
' traitement sur MaCondition
 
Loop
 
f.Close()

Et donc mon script tourne "sans arret (assez longtemp en fait)" et parfois il est tué (kill) donc impossible de refermer le fichier, et donc de le rouvrir plus tard.
D'ou m'a question est-il possible d'ouvrir le fichier sans le bloquer en sachant que je gere moi meme le fait qu'il n'y aura pas 2 acces simultané (le script ne sera jamais lancé 2 fois)?

Merci

**ced600** · 28/05/2008, 10h31

D'ou m'a question est-il possible d'ouvrir le fichier sans le bloquer

Non.

**kacedda** · 28/05/2008, 11h17

ca a le merite d'etre clair!

Alors par hasard quelqu'un connaitrait-il un moyen pour contourner, changer des paramètres utiliser d'autre type d'objet, une piste meme petite...
Existe-t-il d'autre moyen d'ecrire dans un fichier (autre que le echo >> (cette solution semble correcte mais pas tres optimisé))?

Merci

**ced600** · 28/05/2008, 11h54

Non, c'est windows qui bloque l'ouverture du fichier en mode lecture, ecriture, à une seule personne lorsque tu l'ouvres. Personne d'autre ne peut l'utiliser tant qu'il n'est pas fermé. C'est ainsi.

**kacedda** · 28/05/2008, 12h28

Pas d'accord!

Le mécanisme ne bloque pas. On peut ouvrir plein de fois un fichier sous notepad meme user ou user different, de la meme machine ou d'une machine distante. Alors je suis d'accord pour dire que notepad charge le texte en memoire(donc lecture) et n'ecrit dans le fichier que lors de l'enregistrement et que du coup c'est le dernier enregistrement qui prend la main, mais bon ca c'est comprehensible.
Donc plusieurs notepad ouvre le fichier avec les droits en ecriture(pas de lock).

**ced600** · 28/05/2008, 13h47

Notepad comme tu dis charge le fichier en mémoire -> puis le ferme.

Il le rouvre lorsque tu sauvegarde, et le referme.

Tu peux faire pareil dans un programme, mais si lors du chargement en mémoire ton script est killé, le fichier reste locké.

Au bout d'un moment windows comprends que le fichier n'est plus ouvert par personne et le ferme tout seul.

**kacedda** · 28/05/2008, 14h49

Bien vu!
Bon tant pis, vais essayer de contourner autrement.
Merci pour les infos!

**omen999** · 28/05/2008, 15h57

ou peut-être en gérant le fichier ecr.txt avec l'objet ado.stream en l'ouvrant avec le mode approprié (adModeShareDenyNone) ?

**kacedda** · 28/05/2008, 17h45

Je connais pas ado, le peu que je sais il me semblait que c'etait destiné au base de donnees non?
M'enfin vais voir, ca pourrait etre interessant.
Par contre si t'as plus de précision, je suis preneur, car la j'ai regardé rapidement, j'ai pas trouvé comment l'utiliser avec des fichiers et rien dans ma MSDN.

Merci pour la piste!

J'ai déja trouvé ca, je fouille pour voir

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
Function SaveTextData(FileName, Text, CharSet)
  Const adTypeText = 2
  Const adSaveCreateOverWrite = 2
 
  'Create Stream object
  Dim BinaryStream
  Set BinaryStream = CreateObject("ADODB.Stream")
 
  'Specify stream type - we want To save text/string data.
  BinaryStream.Type = adTypeText
 
  'Specify charset For the source text (unicode) data.
  If Len(CharSet) > 0 Then
    BinaryStream.CharSet = CharSet
  End If
 
  'Open the stream And write binary data To the object
  BinaryStream.Open
  BinaryStream.WriteText Text
 
  'Save binary data To disk
  BinaryStream.SaveToFile FileName, adSaveCreateOverWrite
End Function

**ced600** · 28/05/2008, 18h04

Et pourquoi n'écris tu pas en mémoire ce que tu veux ecrire dans le fichier.
Et tu n'ouvres le fichier qu'à la toute fin, pour écrire le contenu de la mémoire, et tu fermes le fichier. A moins que l'écriture dure plusieurs seconde, il est difficille de killer le script au mauvais moment.

Sinon à chaque tour de boucle tu ouvres le fichier, ecrit dedans, et fermes le fichier.

Et puis tu peux faire un mixe des deux. Tu stockes en mémoire, et toutes les heures du enregistre les données dans le fichier.

Bref tu fais comme tu veux, mais l'idée est de ne pas mettre une longue attente entre l'ouverture, l'écriture et la fermeture.

Normalement pour ecrire dans un fichier : tu ouvres, tu ecris, tu fermes dans la foulée.
Si tu veux y écrire des données qui arrivent toutes les secondes, mais faire cela toutes les 5 minutes, tu stockes les données dans une pile, et au bout de 5 minutes, tu ouvres le fichier, tu vides la pile en écrivant son contenu dans le fichier, et tu fermes le fichier.

**kacedda** · 28/05/2008, 18h27

Oui je suis d'accord avec toi!
J'ai encapsulé l'ecriture dans un open/close et ca marche a moins d'avoir vraiment pas de bol et de killer au bon moment.
Le seul soucis c'est question perf, j'ai un truc qui marche mais je voudrais l'optimiser au max donc deja essayer de limiter les appels open/close.
Quand a la mise en memoire dans mon cas c'est encore un peu chaud

, je suis plutot C++ que VBScript en fait.
Du coup j'explore un max pour voir les possibilite/contrainte.

Merci pour les idées!

**ced600** · 29/05/2008, 09h35

Heu ... Quand je parlais de mise en mémoire, je ne pensais pas forcement d'alouer une zone mémoire à ton écriture.
Tu peux stocker les lignes de textes à écrire dans un tableau par exemple. Il est stocké en mémoire le tableau

En plus son parcour est facile à l'aide de foreach

Et puis après il y a d'autre structure comme les dictionnaires ...