Sauvegarde amputée ?

Je viens juste de rejoindre la communauté PANORAMIC ... Bonjour à tous !
Il y a qq mois que je me réinitie à la programmation à l'aide de ce nouvel outil qui nous est mis gratuitement à disposition par son auteur, à qui j'adresse mes compliments pour la qualité de l'énorme travail fourni.
Dernièrement, je me suis heurté, autodidacte, à un problème de sauvegarde qui ne s'effectue dans son intégralité.
Vous trouverez ci-dessous mon source, très simplifié, qui néanmoins présente la même situation :

*************************************************************

Code:

DIM z,z$
Label Sauvegarde
FILE_OPEN_WRITE 1,TESTsavePANO

for z= 1 to 3     

    cls

    z$ = "Ligne N° " + str$(z)+ chr$ (13)
    FILE_WRITE 1,z$
    print z$
   
    gosub Sauvegarde
   

next z

    z$ = chr$(13)

    z$ = z$ + "Fin de la sauvegarde du fichier de " + str$(z-1) + " lignes." + chr$ (13)

    z$ = z$ +  " = ok = "

FILE_WRITE 1,z$

print z$


END

REM *****************************************************

REM SAUVEGARDE DANS LE FICHIER

Sauvegarde:

z$ =  " ====> Sauvegarde  " + str$(z) + " = ok = "
print z$
z$ = z$ + " ... "+ CHR$ (13)

FILE_WRITE 1,z$

RETURN

END

*************************************************************

La "dernière" boucle "z" (que j'ai testé avec 1500) n'est pas toujours sauvegardée dans son intégralité dans le fichier.txt prévu, et par suite la dernière instruction FILE_WRITE 1,z$ (pour contrôle) ne semble pas effectuée.
Par ailleurs CHR$(13) ne semble pas pris en compte.

Ce défaut se présente-t-il sur vos bécanes ? Est-ce dû à PANORAMIC ?
Ou quelquechose m'échappe ?

Quelqu'un a-t-il une idée du pourquoi ?

Je vous précise que mon joujou est un QUAD 6600 iNTEL sous VISTA pas encore SP1.

Je vous remercie par avance de vos remarques ou solutions.

Je vais examiner ton source dans le détail, mais, à première vue, il manque une commande importante:
je ne trouve pas de FILE_CLOSE dans ton source.

En effet, lorsqu'un FILE_WRITE est exécuté, il n'y a pas forcément un enregistrement correspondant sur le support (le disque dur par exemple), car les écritures s'effectuent en fait dans un buffer mémoire, et au fur et à mesure de l'exécution des FILE_WRITE, ce buffer se remplit. Dès qu'il atteint une certaine taille, il est alors physiquement enregistré sur le support.
Cependant, lors de l'exécution d'une commande FILE_CLOSE, ce buffer est systématiquement enregistré sur le support pour que le fichier écrit soit complet.
Ce procédé permet de limiter les accès en écriture sur le support (disque dur) et donc de gagner en vitesse d'exécution.

Ce qui semble se passer, c'est qu'après le dernier FILE_WRITE, ce buffer est rempli, mais pas assez pour être enregistré. Il reste indéfiniment en mémoire et le fichier utilisé n'est jamais fermé, ce qui explique qu'il ne contienne pas tout.

Il faut toujours fermer un fichier en écriture, quand les écritures sont terminées, par une commande FILE_CLOSE pour qu'il soit complet.

Essaye d'introduire un FILE_CLOSE 1 avant le END du programme principal:

Code:

FILE_WRITE 1,z$

print z$

FILE_CLOSE 1

END

Remarque : le END après le RETURN du sous-programme est inutile, mais ne gène pas.

Une petite remarque au passage: je suppose que TESTsavePANO est le nom du fichier de sauvegarde. Il n'est donc pas obligatoire que ce nom soit mis entre guillemets, pour désigner une chaîne, s'il n'est pas déclaré préalablement comme telle ?

De la discussion jaillit l'étincelle !!!
Merci à Panoramic pour sa réponse dans un délai défiant toute concurrence et de plus efficace car je viens de la tester...
Elémentaire mon cher, et erreur, par économie, de ma part : je ne ferme pas la porte en sortant !
Enfin ça tourne maintenant comme je le voulais, et de plus le ch$(13) était effectivement pris en compte sous "Wordpad" mais pas sous "Ooo - calc " ou "Ooo - writer" , et cela sans doute dû au nom de fichier retenu comme TESTsavePANO plutôt que "TESTsavePANO.txt" comme me le fait remarquer JL35 que je remercie également au passage.
J'ai bien noté tout cela, l'expérience est la somme des erreurs...
La suite au prochain numéro !