Vidanger puis fermer un fichier ouvert en mode Output dans le cas d'un disque plein

Question bête

ces procédures d'écritures sont elles des "sauvegardes" ou équivalentes ?
je m'explique : ne pourrais tu pas écrire plus souvent tes fichiers et non
pas attendre un trop gros buffer ?
Bien cela doit ralentir le travail .. d'où ma première question : est ce que
le temps est imporant ou est ce fait par exemple la nuit ?

Driss

"Eric" <ericbellina@wanadoo.fr> a écrit dans le message de
news:OaKD43APFHA.2824@TK2MSFTNGP10.phx.gbl...

ok merci
je pense que je vais essayer de concevoir l'appli autrement.

Jean-Marc wrote:
> "Eric" <ericbellina@wanadoo.fr> a écrit dans le message de
> news:%23V2vMa4OFHA.3076@TK2MSFTNGP14.phx.gbl...
>
>>c'est impossible d'estimer la place qu'il faudrait... Et ca prendrait
>>inutilement du temps dans les cas (normaux) où il y a assez de place.
>>
>>ng wrote:
>>
>>>Eric wrote:
>>>
>>>
>>>
>>>>Mon programme génère pleins de fichiers contenant des données

récupérées

>>>>de la BDD avant de compresser le tout puis de les effacer.
>>>>Je dois donc envisager le cas d'un espace disque insuffisant! Et je

vais

>>>>pas demander au client d'effacer le contenu de son disque pour me

faire

>>>>plus de place hein ;)
>>>
>>>
>>>Dans ce cas il faut anticiper l'espace necessaire et afficher un

message

>>>d'erreur s'il y en a pas assez. De tte facon pour ce genre de manip le
>>>client doit bien savoir qu'il faut de la marge sur son disque, donc tu
>>>estimes large et tu affiches un messages si c'est pas bon.
>
>
> Hello,
>
> alors fais tes écritures en C. En C, il y a fflush(file_descriptor) qui
> force l'écriture sur le stream désigné. Ce n'est pas compliqué de faire
> une petite dll qui implémente juste une fonction d'écriture.
> Il ne te reste plus qu'à appeler cette fonction depuis ton prgramme VB.
>
> Ce n'est qu'une solution parmi d'autres, je pense qu'il y a beaucoup

plus

> secure avec un design différent de ton appli.
>

Non en fait il s'agit d'un export manuel de données issues de la BDD. Et
puis ca peut planter aussi bien sur l'écriture d'un petit fichier (1Ko)
que d'un gros. Quand le disque est plein, quelque soit la taille du
fichier à écrire ca ne passera pas :)


Driss HANIB wrote:

Question bête

ces procédures d'écritures sont elles des "sauvegardes" ou équivalentes ?
je m'explique : ne pourrais tu pas écrire plus souvent tes fichiers et non
pas attendre un trop gros buffer ?
Bien cela doit ralentir le travail .. d'où ma première question : est ce que
le temps est imporant ou est ce fait par exemple la nuit ?

Driss

"Eric" <ericbellina@wanadoo.fr> a écrit dans le message de
news:OaKD43APFHA.2824@TK2MSFTNGP10.phx.gbl...

ok merci
je pense que je vais essayer de concevoir l'appli autrement.

Jean-Marc wrote:

"Eric" <ericbellina@wanadoo.fr> a écrit dans le message de
news:%23V2vMa4OFHA.3076@TK2MSFTNGP14.phx.gbl...

c'est impossible d'estimer la place qu'il faudrait... Et ca prendrait
inutilement du temps dans les cas (normaux) où il y a assez de place.

ng wrote:

Eric wrote:

Mon programme génère pleins de fichiers contenant des données

récupérées

de la BDD avant de compresser le tout puis de les effacer.
Je dois donc envisager le cas d'un espace disque insuffisant! Et je

vais

pas demander au client d'effacer le contenu de son disque pour me

faire

plus de place hein ;)

Dans ce cas il faut anticiper l'espace necessaire et afficher un

message

d'erreur s'il y en a pas assez. De tte facon pour ce genre de manip le
client doit bien savoir qu'il faut de la marge sur son disque, donc tu
estimes large et tu affiches un messages si c'est pas bon.

Hello,

alors fais tes écritures en C. En C, il y a fflush(file_descriptor) qui
force l'écriture sur le stream désigné. Ce n'est pas compliqué de faire
une petite dll qui implémente juste une fonction d'écriture.
Il ne te reste plus qu'à appeler cette fonction depuis ton prgramme VB.

Ce n'est qu'une solution parmi d'autres, je pense qu'il y a beaucoup

plus

secure avec un design différent de ton appli.

est ce tu ne peux pas prévoir une gravure de tes données sur CD ROM au fur
et à mesure.
Il existe des classes VB pour Graver ou piloter NERO etc..

Driss
"Eric" <ericbellina@wanadoo.fr> a écrit dans le message de
news:eTG1ISCPFHA.2748@TK2MSFTNGP09.phx.gbl...

Non en fait il s'agit d'un export manuel de données issues de la BDD. Et
puis ca peut planter aussi bien sur l'écriture d'un petit fichier (1Ko)
que d'un gros. Quand le disque est plein, quelque soit la taille du
fichier à écrire ca ne passera pas :)


Driss HANIB wrote:
> Question bête
>
> ces procédures d'écritures sont elles des "sauvegardes" ou équivalentes

?

> je m'explique : ne pourrais tu pas écrire plus souvent tes fichiers et

non

> pas attendre un trop gros buffer ?
> Bien cela doit ralentir le travail .. d'où ma première question : est ce

que

> le temps est imporant ou est ce fait par exemple la nuit ?
>
> Driss
>
> "Eric" <ericbellina@wanadoo.fr> a écrit dans le message de
> news:OaKD43APFHA.2824@TK2MSFTNGP10.phx.gbl...
>
>>ok merci
>>je pense que je vais essayer de concevoir l'appli autrement.
>>
>>Jean-Marc wrote:
>>
>>>"Eric" <ericbellina@wanadoo.fr> a écrit dans le message de
>>>news:%23V2vMa4OFHA.3076@TK2MSFTNGP14.phx.gbl...
>>>
>>>
>>>>c'est impossible d'estimer la place qu'il faudrait... Et ca prendrait
>>>>inutilement du temps dans les cas (normaux) où il y a assez de place.
>>>>
>>>>ng wrote:
>>>>
>>>>
>>>>>Eric wrote:
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>>Mon programme génère pleins de fichiers contenant des données
>
> récupérées
>
>>>>>>de la BDD avant de compresser le tout puis de les effacer.
>>>>>>Je dois donc envisager le cas d'un espace disque insuffisant! Et je
>
> vais
>
>>>>>>pas demander au client d'effacer le contenu de son disque pour me
>
> faire
>
>>>>>>plus de place hein ;)
>>>>>
>>>>>
>>>>>Dans ce cas il faut anticiper l'espace necessaire et afficher un
>
> message
>
>>>>>d'erreur s'il y en a pas assez. De tte facon pour ce genre de manip

le

>>>>>client doit bien savoir qu'il faut de la marge sur son disque, donc

tu

>>>>>estimes large et tu affiches un messages si c'est pas bon.
>>>
>>>
>>>Hello,
>>>
>>>alors fais tes écritures en C. En C, il y a fflush(file_descriptor)

qui

>>>force l'écriture sur le stream désigné. Ce n'est pas compliqué de

faire

>>>une petite dll qui implémente juste une fonction

d'écriture.

>>>Il ne te reste plus qu'à appeler cette fonction depuis ton prgramme VB.
>>>
>>>Ce n'est qu'une solution parmi d'autres, je pense qu'il y a beaucoup
>
> plus
>
>>>secure avec un design différent de ton appli.
>>>
>
>
>

Je pense que comme cela a été indiqué, si on veut faire une sauvegarde, on
s'assure AVANT qu'on peut la faire, et donc qu'on a l'espace disque
nécessaire..
A mon sens, il faut estimer la taille nécessaire (ex: la taille de la BDD +
15%) au démarrage et s'arreter si l'espace n'est pas suffisant.

Ce type de test est quand même très simple à faire, cf les instructions
scripts VB appelables en visual basic à l'aide de createobject pour
connaitre la taille de la BDD et l'espace libre.

ci dessous un petite fonction qui doit faire l'affaire.

Function EspaceOK() as boolean

dim fso,f
dim E as long
dim T as long

Set fso = CreateObject("Scripting.FileSystemObject")
GetDrive(fso.GetDriveName("C:")
E=d.FreeSpace
Set f = fso.GetFile("c:mabase.mdb")
T=f.size * 1.15
if T <E then
msgbox "pas assez de place disponible, désolé"
espaceokúlse
else
espaceok=true
end if
end function



"Eric" <ericbellina@wanadoo.fr> a écrit dans le message de news:
eTG1ISCPFHA.2748@TK2MSFTNGP09.phx.gbl...

Non en fait il s'agit d'un export manuel de données issues de la BDD. Et
puis ca peut planter aussi bien sur l'écriture d'un petit fichier (1Ko)
que d'un gros. Quand le disque est plein, quelque soit la taille du
fichier à écrire ca ne passera pas :)


Driss HANIB wrote:
> Question bête
>
> ces procédures d'écritures sont elles des "sauvegardes" ou équivalentes

?

> je m'explique : ne pourrais tu pas écrire plus souvent tes fichiers et

non

> pas attendre un trop gros buffer ?
> Bien cela doit ralentir le travail .. d'où ma première question : est ce

que

> le temps est imporant ou est ce fait par exemple la nuit ?
>
> Driss
>
> "Eric" <ericbellina@wanadoo.fr> a écrit dans le message de
> news:OaKD43APFHA.2824@TK2MSFTNGP10.phx.gbl...
>
>>ok merci
>>je pense que je vais essayer de concevoir l'appli autrement.
>>
>>Jean-Marc wrote:
>>
>>>"Eric" <ericbellina@wanadoo.fr> a écrit dans le message de
>>>news:%23V2vMa4OFHA.3076@TK2MSFTNGP14.phx.gbl...
>>>
>>>
>>>>c'est impossible d'estimer la place qu'il faudrait... Et ca prendrait
>>>>inutilement du temps dans les cas (normaux) où il y a assez de place.
>>>>
>>>>ng wrote:
>>>>
>>>>
>>>>>Eric wrote:
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>>Mon programme génère pleins de fichiers contenant des données
>
> récupérées
>
>>>>>>de la BDD avant de compresser le tout puis de les effacer.
>>>>>>Je dois donc envisager le cas d'un espace disque insuffisant! Et je
>
> vais
>
>>>>>>pas demander au client d'effacer le contenu de son disque pour me
>
> faire
>
>>>>>>plus de place hein ;)
>>>>>
>>>>>
>>>>>Dans ce cas il faut anticiper l'espace necessaire et afficher un
>
> message
>
>>>>>d'erreur s'il y en a pas assez. De tte facon pour ce genre de manip

le

>>>>>client doit bien savoir qu'il faut de la marge sur son disque, donc

tu

>>>>>estimes large et tu affiches un messages si c'est pas bon.
>>>
>>>
>>>Hello,
>>>
>>>alors fais tes écritures en C. En C, il y a fflush(file_descriptor)

qui

>>>force l'écriture sur le stream désigné. Ce n'est pas compliqué de

faire

>>>une petite dll qui implémente juste une fonction

d'écriture.

>>>Il ne te reste plus qu'à appeler cette fonction depuis ton prgramme VB.
>>>
>>>Ce n'est qu'une solution parmi d'autres, je pense qu'il y a beaucoup
>
> plus
>
>>>secure avec un design différent de ton appli.
>>>
>
>
>

Bon, je le redis: il ne s'agit pas de sauvegarde mais d'export de
données particulières (il y a tout un algo de récupération de ces
données!). Il ne s'agit pas de récupérer toutes les données car dans ce
cas je ferais un export Oracle! Je ne peux donc pas évaluer la taille
qu'il me faudrait, sauf à dérouler l'algo qui peut prendre jusqu'à 1
journée selon le volume des données...

Merci qd même pour la solution proposée :)

Thierry Bertrand wrote:

Je pense que comme cela a été indiqué, si on veut faire une sauvegarde, on
s'assure AVANT qu'on peut la faire, et donc qu'on a l'espace disque
nécessaire..
A mon sens, il faut estimer la taille nécessaire (ex: la taille de la BDD +
15%) au démarrage et s'arreter si l'espace n'est pas suffisant.

Ce type de test est quand même très simple à faire, cf les instructions
scripts VB appelables en visual basic à l'aide de createobject pour
connaitre la taille de la BDD et l'espace libre.

ci dessous un petite fonction qui doit faire l'affaire.

Function EspaceOK() as boolean

dim fso,f
dim E as long
dim T as long

Set fso = CreateObject("Scripting.FileSystemObject")
GetDrive(fso.GetDriveName("C:")
E=d.FreeSpace
Set f = fso.GetFile("c:mabase.mdb")
T=f.size * 1.15
if T <E then
msgbox "pas assez de place disponible, désolé"
espaceokúlse
else
espaceok=true
end if
end function



"Eric" <ericbellina@wanadoo.fr> a écrit dans le message de news:
eTG1ISCPFHA.2748@TK2MSFTNGP09.phx.gbl...

Non en fait il s'agit d'un export manuel de données issues de la BDD. Et
puis ca peut planter aussi bien sur l'écriture d'un petit fichier (1Ko)
que d'un gros. Quand le disque est plein, quelque soit la taille du
fichier à écrire ca ne passera pas :)


Driss HANIB wrote:

Question bête

ces procédures d'écritures sont elles des "sauvegardes" ou équivalentes

?

je m'explique : ne pourrais tu pas écrire plus souvent tes fichiers et

non

pas attendre un trop gros buffer ?
Bien cela doit ralentir le travail .. d'où ma première question : est ce

que

le temps est imporant ou est ce fait par exemple la nuit ?

Driss

"Eric" <ericbellina@wanadoo.fr> a écrit dans le message de
news:OaKD43APFHA.2824@TK2MSFTNGP10.phx.gbl...

ok merci
je pense que je vais essayer de concevoir l'appli autrement.

Jean-Marc wrote:

"Eric" <ericbellina@wanadoo.fr> a écrit dans le message de
news:%23V2vMa4OFHA.3076@TK2MSFTNGP14.phx.gbl...

c'est impossible d'estimer la place qu'il faudrait... Et ca prendrait
inutilement du temps dans les cas (normaux) où il y a assez de place.

ng wrote:

Eric wrote:

Mon programme génère pleins de fichiers contenant des données

récupérées

de la BDD avant de compresser le tout puis de les effacer.
Je dois donc envisager le cas d'un espace disque insuffisant! Et je

vais

pas demander au client d'effacer le contenu de son disque pour me

faire

plus de place hein ;)

Dans ce cas il faut anticiper l'espace necessaire et afficher un

message

d'erreur s'il y en a pas assez. De tte facon pour ce genre de manip

le

client doit bien savoir qu'il faut de la marge sur son disque, donc

tu

estimes large et tu affiches un messages si c'est pas bon.

Hello,

alors fais tes écritures en C. En C, il y a fflush(file_descriptor)

qui

force l'écriture sur le stream désigné. Ce n'est pas compliqué de

faire

une petite dll qui implémente juste une fonction

d'écriture.

Il ne te reste plus qu'à appeler cette fonction depuis ton prgramme VB.

Ce n'est qu'une solution parmi d'autres, je pense qu'il y a beaucoup

plus

secure avec un design différent de ton appli.

Et bien non puisque comme je l'ai dit, l'export génère dans un premier
temps des tas de petits ou gros fichiers (plusieurs milliers) qui ne
sont compressés qu'à la fin en un fichier CAB. Donc si je réparti mes
fichiers un peu partout, je vais galérer pour générer le CAB...
Je pourrais par contre générer le cab au fur-et-à-mesure et tout fichier
qui serait ajouté au cab serait effacé aussitôt afin de libérer de la
place. Faut que j'étudie ca!

Driss HANIB wrote:

est ce tu ne peux pas prévoir une gravure de tes données sur CD ROM au fur
et à mesure.
Il existe des classes VB pour Graver ou piloter NERO etc..

Driss
"Eric" <ericbellina@wanadoo.fr> a écrit dans le message de
news:eTG1ISCPFHA.2748@TK2MSFTNGP09.phx.gbl...

Non en fait il s'agit d'un export manuel de données issues de la BDD. Et
puis ca peut planter aussi bien sur l'écriture d'un petit fichier (1Ko)
que d'un gros. Quand le disque est plein, quelque soit la taille du
fichier à écrire ca ne passera pas :)


Driss HANIB wrote:

Question bête

ces procédures d'écritures sont elles des "sauvegardes" ou équivalentes

?

je m'explique : ne pourrais tu pas écrire plus souvent tes fichiers et

non

pas attendre un trop gros buffer ?
Bien cela doit ralentir le travail .. d'où ma première question : est ce

que

le temps est imporant ou est ce fait par exemple la nuit ?

Driss

"Eric" <ericbellina@wanadoo.fr> a écrit dans le message de
news:OaKD43APFHA.2824@TK2MSFTNGP10.phx.gbl...

ok merci
je pense que je vais essayer de concevoir l'appli autrement.

Jean-Marc wrote:

"Eric" <ericbellina@wanadoo.fr> a écrit dans le message de
news:%23V2vMa4OFHA.3076@TK2MSFTNGP14.phx.gbl...

c'est impossible d'estimer la place qu'il faudrait... Et ca prendrait
inutilement du temps dans les cas (normaux) où il y a assez de place.

ng wrote:

Eric wrote:

Mon programme génère pleins de fichiers contenant des données

récupérées

de la BDD avant de compresser le tout puis de les effacer.
Je dois donc envisager le cas d'un espace disque insuffisant! Et je

vais

pas demander au client d'effacer le contenu de son disque pour me

faire

plus de place hein ;)

Dans ce cas il faut anticiper l'espace necessaire et afficher un

message

d'erreur s'il y en a pas assez. De tte facon pour ce genre de manip

le

client doit bien savoir qu'il faut de la marge sur son disque, donc

tu

estimes large et tu affiches un messages si c'est pas bon.

Hello,

alors fais tes écritures en C. En C, il y a fflush(file_descriptor)

qui

force l'écriture sur le stream désigné. Ce n'est pas compliqué de

faire

une petite dll qui implémente juste une fonction

d'écriture.

Il ne te reste plus qu'à appeler cette fonction depuis ton prgramme VB.

Ce n'est qu'une solution parmi d'autres, je pense qu'il y a beaucoup

plus

secure avec un design différent de ton appli.

Ca n'empêche, pour n'importe quel algo, on doit être capable de déterminer à
20% près, la taille des données exportées, ou au moins de majorer cette
valeur.

On connait les formats d'export (taille de record), grosso modo, le nombre
d'enregistrements par type, donc le volume global.

Mais bon, t'es libre.
En tout cas, moi c'est ce que ferai.

Bon courage quand même.