Erreur : Error while trying to write to file

Version imprimable

17/05/2006, 16h16
WebPac

Erreur : Error while trying to write to file

Bonjour tout le monde,

j'essaie d'effectuer une requête classique SELECT .. FROM .. WHERE ..
avec 8 tables, 7 jointures, la table la plus grosse compte 400 000 enregistrements.

Je n'arrive pas à ouvrir la requête, au bout d'un quart d'heure, j'ai cette erreur qui est remontée :

Citation:

Impossible d'ouvrir la requête
Erreur SQL Server : I/O error for file "C:\WINDOWS\TEMP\fb_sort11c6yl"
Error while trying to write to file
L'imprimante n'a plus de papier.

J'ai fait des recherches sur le net, sur Developpez et sur le site de Firebird, je n'ai rien trouvé à part en russe sur le net en général.

Avez-vous déjà eu cette erreur, et si oui comment peut-on la résoudre ?

Merci.

PS : l'imprimante a bien du papier, il n'y a pas de soucis de ce côté ci.
18/05/2006, 18h43
Bejaia-In

Citation:

Envoyé par WebPac

Impossible d'ouvrir la requête
Erreur SQL Server : I/O error for file "C:\WINDOWS\TEMP\fb_sort11c6yl"
Error while trying to write to file
L'imprimante n'a plus de papier.

j'ai bien lu "erreur SQL Server" !?
votre base est Firebird/interbese ou SQL Server ?
18/05/2006, 22h32
WebPac

La base de donnée est bien Firebird, je pense qu'il veut dire le serveur SQL en anglais. C'est Microsoft qui aime bien utiliser des noms communs pour ses produits Windows, Office, SQL Server, Word ...

Pour preuve, le fichier qu'il n'arrive pas à écrire est fb_sort11c6yl, il commence par fb comme FireBird.

En fait, on dirait que Firebird utilise un fichier temporaire de taille fort conséquente car j'ai perdu presque toute la place libre sur mon disque dur avant l'erreur, un utilisateur avec 6Go de libre n'a pas réussi à ouvrir la requête et un autre avec 15Go a réussi.
19/05/2006, 11h23
WebPac

J'ai un peu avancé sur le problème, la requête qui est faite est un SELECT DISTINCT, lorsqu'on fait la même requête sans le DISTINCT, elle s'ouvre en très peu de temps (moins de 2 secondes). Malheureusement, le DISTINCT est utile et je ne peux le retirer.

Malgré tout, le problème n'est pas encore résolu.
19/05/2006, 14h30
Olivier Muet

Le problème vient de firebird.conf ;)

Pour le résoudre :
• Soit corrige, firebird.conf,
• Soit crée le dossier c:\windows\temp.
19/05/2006, 15h11
WebPac

Que dois-je faire dans Firebird.conf ?

En fait mon dossier Windows/Temp existe bien, mais il me créé dedans un tas de fichiers temporaires de 1Go chacun à peu près et lorsque j'ai mon disque dur qui est plein, il me renvoie cette erreur.

Pour information, j'ai 3Go d'espace libre, un utilisateur avec 6Go d'espace libre a la même erreur et un autre utilisateur avec 15Go n'a pas eu d'erreurs.
Sachant qu'on travaille sur une base de donnée qui ne fait que 80 Mo.
19/05/2006, 16h32
TMuet

Il ne te reste qu'à acheter un disque dur d'au moins 15 Go :lol:

Concernant Firebird.conf, il n'y a rien à faire. Il peut effectivement y avoir un souci lié à ce fichier, mais là c'est clairement un problème de place.

De plus si une telle requête prend autant de temps, il ne te reste plus qu'à l'optimiser (plan, join, etc.) ;)
19/05/2006, 16h51
WebPac

Citation:

Envoyé par TMuet

De plus si une telle requête prend autant de temps, il ne te reste plus qu'à l'optimiser (plan, join, etc.) ;)

Si je le pouvais, je l'aurrais déjà fait, malheureusement je n'ai pas la main dessus.
Je cherche surtout à comprendre pourquoi firebird agit ainsi afin de ne pas avoir ce problème dans d'autres circonstances. Surtout que la même requête sans DISTINCT est bien plus rapide, les temps n'ont rien à voir.
19/05/2006, 18h14
makowski

Citation:

Envoyé par WebPac

Si je le pouvais, je l'aurrais déjà fait, malheureusement je n'ai pas la main dessus.
Je cherche surtout à comprendre pourquoi firebird agit ainsi afin de ne pas avoir ce problème dans d'autres circonstances. Surtout que la même requête sans DISTINCT est bien plus rapide, les temps n'ont rien à voir.

ça que la requête sans distinct soit plus rapide c'est fonction du nombre d'enregistrements renvoyés, déjàen ne rappatriant pas tous les enregistrements le résultat sera plus rapide
d'autre part, pour les fichier temporaires, il en faut bien donc pas d'échapatoire, il faut plus de place sur le disque c'est tout
mais bon au lieu d'installer Firebird en local, il faut le mettre sur un serveur avec de la place
19/05/2006, 19h02
WebPac

Citation:

Envoyé par makowski

ça que la requête sans distinct soit plus rapide c'est fonction du nombre d'enregistrements renvoyés

Ah bon ! J'aurrais dit qu'une requête avec DISTINCT serra plus rapide car elle retourne moins d'enregistrements et non l'inverse.

Citation:

Envoyé par makowski

déjàen ne rappatriant pas tous les enregistrements le résultat sera plus rapide

Je (l'application) ne rappatrie que les 200 premiers enregistrements, et les suivants à la demande de l'utilisateur. C'est l'ouverture de la requête qui n'arrive pas à terme.
19/05/2006, 20h27
makowski

[quote=WebPac]Ah bon ! J'aurrais dit qu'une requête avec DISTINCT serra plus rapide car elle retourne moins d'enregistrements et non l'inverse.

pardon j'aurais du être plus précis
le distinct oblige à tout trier et donc à faire ces fichier temporaires
mais oui cela rappatrie moins d'enregistrements bien sûr
mais là clairement le probème est bêtement un problème d'espace disque ce qui amène plantage et lenteur
19/05/2006, 22h23
WebPac

Citation:

Envoyé par makowski

pardon j'aurais du être plus précis
le distinct oblige à tout trier et donc à faire ces fichier temporaires
mais oui cela rappatrie moins d'enregistrements bien sûr
mais là clairement le probème est bêtement un problème d'espace disque ce qui amène plantage et lenteur

C'est bien ce que je me disais aussi, et ça explique aussi le mot sort dans le nom du fichier temporaire, mais ne connaissant pas le fonctionnement interne des moteurs de bases de données, je préférais attendre de voir ce que les gens du milieu pouvaient dire.