Dans l'aide de WD je suis tombé sur les possibilités de
créer des fichiers "dis" temporaires. On peut même les
enregistrer physiquement sur le disque et ajouter des
enregistrements que l'on sauve également ...
// Création des fichiers physiques
HCréation("CLIENT")
HCréation("VILLE")
// Ajout de valeurs dans le fichier "VILLE"
Ville.NOMVILLE = "Montpellier"
Ville.CODEPOSTAL = "34000"
HAjoute(Ville)
Ville.NOMVILLE = "Toulouse"
Ville.CODEPOSTAL = "31000"
HAjoute(Ville)
Ma question est simple voir peut-être idiote !?
En quoi ces fichiers créés par programmation sont-ils vraiment
"temporaire" ... Et si c'est le cas quel est alors leur réelle
utilité. Quand doit on utiliser un fichier temporaire et pourquoi ?
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire
Veuillez sélectionner un problème
Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
Romuald.besset
JPC a écrit :
Bonjour à tous,
Dans l'aide de WD je suis tombé sur les possibilités de créer des fichiers "dis" temporaires. On peut même les enregistrer physiquement sur le disque et ajouter des enregistrements que l'on sauve également ...
// Création des fichiers physiques HCréation("CLIENT") HCréation("VILLE")
// Ajout de valeurs dans le fichier "VILLE" Ville.NOMVILLE = "Montpellier" Ville.CODEPOSTAL = "34000" HAjoute(Ville) Ville.NOMVILLE = "Toulouse" Ville.CODEPOSTAL = "31000" HAjoute(Ville)
Ma question est simple voir peut-être idiote !?
En quoi ces fichiers créés par programmation sont-ils vraiment "temporaire" ... Et si c'est le cas quel est alors leur réelle utilité. Quand doit on utiliser un fichier temporaire et pourquoi ?
Merci de vos réactions !
jpc
Une partie de l'explication : http://www.wdforge.org/modules/icontent/index.php?page
++ R&B
JPC a écrit :
Bonjour à tous,
Dans l'aide de WD je suis tombé sur les possibilités de
créer des fichiers "dis" temporaires. On peut même les
enregistrer physiquement sur le disque et ajouter des
enregistrements que l'on sauve également ...
// Création des fichiers physiques
HCréation("CLIENT")
HCréation("VILLE")
// Ajout de valeurs dans le fichier "VILLE"
Ville.NOMVILLE = "Montpellier"
Ville.CODEPOSTAL = "34000"
HAjoute(Ville)
Ville.NOMVILLE = "Toulouse"
Ville.CODEPOSTAL = "31000"
HAjoute(Ville)
Ma question est simple voir peut-être idiote !?
En quoi ces fichiers créés par programmation sont-ils vraiment
"temporaire" ... Et si c'est le cas quel est alors leur réelle
utilité. Quand doit on utiliser un fichier temporaire et pourquoi ?
Merci de vos réactions !
jpc
jpc@delinde.net
Une partie de l'explication :
http://www.wdforge.org/modules/icontent/index.php?page
Dans l'aide de WD je suis tombé sur les possibilités de créer des fichiers "dis" temporaires. On peut même les enregistrer physiquement sur le disque et ajouter des enregistrements que l'on sauve également ...
// Création des fichiers physiques HCréation("CLIENT") HCréation("VILLE")
// Ajout de valeurs dans le fichier "VILLE" Ville.NOMVILLE = "Montpellier" Ville.CODEPOSTAL = "34000" HAjoute(Ville) Ville.NOMVILLE = "Toulouse" Ville.CODEPOSTAL = "31000" HAjoute(Ville)
Ma question est simple voir peut-être idiote !?
En quoi ces fichiers créés par programmation sont-ils vraiment "temporaire" ... Et si c'est le cas quel est alors leur réelle utilité. Quand doit on utiliser un fichier temporaire et pourquoi ?
Merci de vos réactions !
jpc
Une partie de l'explication : http://www.wdforge.org/modules/icontent/index.php?page
++ R&B
Roumegou Eric
Romuald.besset avait écrit le 22/11/2004 :
JPC a écrit :
Bonjour à tous,
Dans l'aide de WD je suis tombé sur les possibilités de créer des fichiers "dis" temporaires. On peut même les enregistrer physiquement sur le disque et ajouter des enregistrements que l'on sauve également ...
// Création des fichiers physiques HCréation("CLIENT") HCréation("VILLE")
// Ajout de valeurs dans le fichier "VILLE" Ville.NOMVILLE = "Montpellier" Ville.CODEPOSTAL = "34000" HAjoute(Ville) Ville.NOMVILLE = "Toulouse" Ville.CODEPOSTAL = "31000" HAjoute(Ville)
Ma question est simple voir peut-être idiote !?
En quoi ces fichiers créés par programmation sont-ils vraiment "temporaire" ... Et si c'est le cas quel est alors leur réelle utilité. Quand doit on utiliser un fichier temporaire et pourquoi ?
je m'étais poser la meme question sur cette notion de temporaire. Cela n'implique pas que le fichier va s'autodétruire (comme dans mission impossible). je m'attendais à un fn du style AS400 avec la bib QTEMP (mais non !)
Un fichier temporaire est donc un fichier que l'on créera, que l'on utilisera avec un alias et qu'on devra ensuite supprimer manuellement.
Merci de vos réactions !
jpc
Une partie de l'explication : http://www.wdforge.org/modules/icontent/index.php?page
++ R&B
-- Eric Roumégou http://cerbermail.com/?TSoulBerPA (cliquez sur le lien ci-dessus pour me contacter en privé)
Romuald.besset avait écrit le 22/11/2004 :
JPC a écrit :
Bonjour à tous,
Dans l'aide de WD je suis tombé sur les possibilités de
créer des fichiers "dis" temporaires. On peut même les
enregistrer physiquement sur le disque et ajouter des
enregistrements que l'on sauve également ...
// Création des fichiers physiques
HCréation("CLIENT")
HCréation("VILLE")
// Ajout de valeurs dans le fichier "VILLE"
Ville.NOMVILLE = "Montpellier"
Ville.CODEPOSTAL = "34000"
HAjoute(Ville)
Ville.NOMVILLE = "Toulouse"
Ville.CODEPOSTAL = "31000"
HAjoute(Ville)
Ma question est simple voir peut-être idiote !?
En quoi ces fichiers créés par programmation sont-ils vraiment
"temporaire" ... Et si c'est le cas quel est alors leur réelle
utilité. Quand doit on utiliser un fichier temporaire et pourquoi ?
je m'étais poser la meme question sur cette notion de temporaire. Cela
n'implique pas que le fichier va s'autodétruire (comme dans mission
impossible). je m'attendais à un fn du style AS400 avec la bib QTEMP
(mais non !)
Un fichier temporaire est donc un fichier que l'on créera, que l'on
utilisera avec un alias et qu'on devra ensuite supprimer manuellement.
Merci de vos réactions !
jpc
jpc@delinde.net
Une partie de l'explication :
http://www.wdforge.org/modules/icontent/index.php?page
++ R&B
--
Eric Roumégou
http://cerbermail.com/?TSoulBerPA
(cliquez sur le lien ci-dessus pour me contacter en privé)
Dans l'aide de WD je suis tombé sur les possibilités de créer des fichiers "dis" temporaires. On peut même les enregistrer physiquement sur le disque et ajouter des enregistrements que l'on sauve également ...
// Création des fichiers physiques HCréation("CLIENT") HCréation("VILLE")
// Ajout de valeurs dans le fichier "VILLE" Ville.NOMVILLE = "Montpellier" Ville.CODEPOSTAL = "34000" HAjoute(Ville) Ville.NOMVILLE = "Toulouse" Ville.CODEPOSTAL = "31000" HAjoute(Ville)
Ma question est simple voir peut-être idiote !?
En quoi ces fichiers créés par programmation sont-ils vraiment "temporaire" ... Et si c'est le cas quel est alors leur réelle utilité. Quand doit on utiliser un fichier temporaire et pourquoi ?
je m'étais poser la meme question sur cette notion de temporaire. Cela n'implique pas que le fichier va s'autodétruire (comme dans mission impossible). je m'attendais à un fn du style AS400 avec la bib QTEMP (mais non !)
Un fichier temporaire est donc un fichier que l'on créera, que l'on utilisera avec un alias et qu'on devra ensuite supprimer manuellement.
Merci de vos réactions !
jpc
Une partie de l'explication : http://www.wdforge.org/modules/icontent/index.php?page
++ R&B
-- Eric Roumégou http://cerbermail.com/?TSoulBerPA (cliquez sur le lien ci-dessus pour me contacter en privé)
Michel Herrscher
Bonjour,
Je m'en sers pour les éditions dont la structure des requêtes ( ou de la source de données) est trop complexe et/ou doit être programmée avec du code.
Ensuite dans l'édition ça roule tout seul... 1 seul fichier, des ruptures en veux tu en voilà etc ...cumul, moyenne stat etc ...
Seul écueil pensez en multi utilisateurs au nom du fichier ou à l'endroit où on le crée, si jamais ils sont 2 à faire l'édition ensemble....
Je les vide toujours en fin d'édition avec Hferme, Hcreation. ( inutile de perdre du temps avec les backups) A+ -- Michel Herrscher Consultant Président de WinDAsso - Association des Développeurs WINDEV(c) http://www.windasso.org Tel=+33 450 870912 Fax=+33 450 871741 GSM=+33 609044711
Bonjour,
Je m'en sers pour les éditions dont la structure des requêtes ( ou de la
source de données) est trop complexe et/ou doit être programmée avec du
code.
Ensuite dans l'édition ça roule tout seul... 1 seul fichier, des ruptures en
veux tu en voilà etc ...cumul, moyenne stat etc ...
Seul écueil pensez en multi utilisateurs au nom du fichier ou à l'endroit
où on le crée, si jamais ils sont 2 à faire l'édition ensemble....
Je les vide toujours en fin d'édition avec Hferme, Hcreation. ( inutile de
perdre du temps avec les backups)
A+
--
Michel Herrscher Consultant
Président de WinDAsso - Association des Développeurs WINDEV(c)
http://www.windasso.org
Tel=+33 450 870912 Fax=+33 450 871741 GSM=+33 609044711
Je m'en sers pour les éditions dont la structure des requêtes ( ou de la source de données) est trop complexe et/ou doit être programmée avec du code.
Ensuite dans l'édition ça roule tout seul... 1 seul fichier, des ruptures en veux tu en voilà etc ...cumul, moyenne stat etc ...
Seul écueil pensez en multi utilisateurs au nom du fichier ou à l'endroit où on le crée, si jamais ils sont 2 à faire l'édition ensemble....
Je les vide toujours en fin d'édition avec Hferme, Hcreation. ( inutile de perdre du temps avec les backups) A+ -- Michel Herrscher Consultant Président de WinDAsso - Association des Développeurs WINDEV(c) http://www.windasso.org Tel=+33 450 870912 Fax=+33 450 871741 GSM=+33 609044711
Romuald.besset
Michel Herrscher a écrit :
Bonjour,
Je m'en sers pour les éditions dont la structure des requêtes ( ou de la source de données) est trop complexe et/ou doit être programmée avec du code.
Ensuite dans l'édition ça roule tout seul... 1 seul fichier, des ruptures en veux tu en voilà etc ...cumul, moyenne stat etc ...
Seul écueil pensez en multi utilisateurs au nom du fichier ou à l'endroit où on le crée, si jamais ils sont 2 à faire l'édition ensemble....
Je les vide toujours en fin d'édition avec Hferme, Hcreation. ( inutile de perdre du temps avec les backups) A+
Je met en exergue cependant deux types de temporaires ne me rappelant pas si le dossier en référence le relève. Il faut différencier les temporaires selon leur durée de vie.
- le temps d'une session utilisateur : les vrais temporaires. Ces fichiers sont décrits et utilisés pour une action trés ponctuelle et précise. Ils sont complètement créés à chaque session (HCréation). Ainsi, la modification de la programmation permet aussi la mise à jour de leur structure... surtout si elle reprend des définitions de rubriques existantes dans l'analyse.
- supérieure au temps d'une session utilisateur : les pseudo temporaires ou masqués de l'analyse. Totalement proscrits, je leurs préfère les fichiers d'analyse, quitte à y piloter des alias (autre dossier au même endroit). En effet, entre deux sessions, une mise à jour du projet peut avoir lieu et là se pose le problème de la mise à jour des structure... et des données. Ces fichiers n'étant décrit dans l'analyse, WDModFic ne sait les traiter faute de référenciel. Ainsi, pour l'instant, sauf à produire un délicat mécanisme d'export-création-import, j'ai préféré à ce moment les proscrire tout simplement pour des utilisation 'générique' (simplification des problèmes). En revanche, pour les besoins ultra spécifiques, je décris ces fichiers dans des classes qui pilotent entièrement le module (VBAExterne dispo sur WDForge) et qui assurent alors la gestion complète du fichier sans aucun lien avec l'analyse...
Mais evidement il ne s'agit que d'une vision personnelle, la vérité est peut-être ailleurs...
++ R&B
Michel Herrscher a écrit :
Bonjour,
Je m'en sers pour les éditions dont la structure des requêtes ( ou de la
source de données) est trop complexe et/ou doit être programmée avec du
code.
Ensuite dans l'édition ça roule tout seul... 1 seul fichier, des ruptures en
veux tu en voilà etc ...cumul, moyenne stat etc ...
Seul écueil pensez en multi utilisateurs au nom du fichier ou à l'endroit
où on le crée, si jamais ils sont 2 à faire l'édition ensemble....
Je les vide toujours en fin d'édition avec Hferme, Hcreation. ( inutile de
perdre du temps avec les backups)
A+
Je met en exergue cependant deux types de temporaires ne me rappelant
pas si le dossier en référence le relève.
Il faut différencier les temporaires selon leur durée de vie.
- le temps d'une session utilisateur : les vrais temporaires.
Ces fichiers sont décrits et utilisés pour une action trés ponctuelle et
précise. Ils sont complètement créés à chaque session (HCréation).
Ainsi, la modification de la programmation permet aussi la mise à jour
de leur structure... surtout si elle reprend des définitions de
rubriques existantes dans l'analyse.
- supérieure au temps d'une session utilisateur : les pseudo temporaires
ou masqués de l'analyse.
Totalement proscrits, je leurs préfère les fichiers d'analyse, quitte à
y piloter des alias (autre dossier au même endroit).
En effet, entre deux sessions, une mise à jour du projet peut avoir lieu
et là se pose le problème de la mise à jour des structure... et des données.
Ces fichiers n'étant décrit dans l'analyse, WDModFic ne sait les traiter
faute de référenciel. Ainsi, pour l'instant, sauf à produire un délicat
mécanisme d'export-création-import, j'ai préféré à ce moment les
proscrire tout simplement pour des utilisation 'générique'
(simplification des problèmes).
En revanche, pour les besoins ultra spécifiques, je décris ces fichiers
dans des classes qui pilotent entièrement le module (VBAExterne dispo
sur WDForge) et qui assurent alors la gestion complète du fichier sans
aucun lien avec l'analyse...
Mais evidement il ne s'agit que d'une vision personnelle, la vérité est
peut-être ailleurs...
Je m'en sers pour les éditions dont la structure des requêtes ( ou de la source de données) est trop complexe et/ou doit être programmée avec du code.
Ensuite dans l'édition ça roule tout seul... 1 seul fichier, des ruptures en veux tu en voilà etc ...cumul, moyenne stat etc ...
Seul écueil pensez en multi utilisateurs au nom du fichier ou à l'endroit où on le crée, si jamais ils sont 2 à faire l'édition ensemble....
Je les vide toujours en fin d'édition avec Hferme, Hcreation. ( inutile de perdre du temps avec les backups) A+
Je met en exergue cependant deux types de temporaires ne me rappelant pas si le dossier en référence le relève. Il faut différencier les temporaires selon leur durée de vie.
- le temps d'une session utilisateur : les vrais temporaires. Ces fichiers sont décrits et utilisés pour une action trés ponctuelle et précise. Ils sont complètement créés à chaque session (HCréation). Ainsi, la modification de la programmation permet aussi la mise à jour de leur structure... surtout si elle reprend des définitions de rubriques existantes dans l'analyse.
- supérieure au temps d'une session utilisateur : les pseudo temporaires ou masqués de l'analyse. Totalement proscrits, je leurs préfère les fichiers d'analyse, quitte à y piloter des alias (autre dossier au même endroit). En effet, entre deux sessions, une mise à jour du projet peut avoir lieu et là se pose le problème de la mise à jour des structure... et des données. Ces fichiers n'étant décrit dans l'analyse, WDModFic ne sait les traiter faute de référenciel. Ainsi, pour l'instant, sauf à produire un délicat mécanisme d'export-création-import, j'ai préféré à ce moment les proscrire tout simplement pour des utilisation 'générique' (simplification des problèmes). En revanche, pour les besoins ultra spécifiques, je décris ces fichiers dans des classes qui pilotent entièrement le module (VBAExterne dispo sur WDForge) et qui assurent alors la gestion complète du fichier sans aucun lien avec l'analyse...
Mais evidement il ne s'agit que d'une vision personnelle, la vérité est peut-être ailleurs...
++ R&B
jpc
Merci à vous tous pour ces conseils. Je vais tester cela dans une appli test ...
A Bientôt,
JPC
"Romuald.besset" wrote in message news:<cnsbvi$s33$...
Michel Herrscher a écrit : > Bonjour, > > Je m'en sers pour les éditions dont la structure des requêtes ( ou de la > source de données) est trop complexe et/ou doit être programmée avec du > code. > > Ensuite dans l'édition ça roule tout seul... 1 seul fichier, des ruptures en > veux tu en voilà etc ...cumul, moyenne stat etc ... > > Seul écueil pensez en multi utilisateurs au nom du fichier ou à l'endroit > où on le crée, si jamais ils sont 2 à faire l'édition ensemble.... > > Je les vide toujours en fin d'édition avec Hferme, Hcreation. ( inutile de > perdre du temps avec les backups) > A+
Je met en exergue cependant deux types de temporaires ne me rappelant pas si le dossier en référence le relève. Il faut différencier les temporaires selon leur durée de vie.
- le temps d'une session utilisateur : les vrais temporaires. Ces fichiers sont décrits et utilisés pour une action trés ponctuelle et précise. Ils sont complètement créés à chaque session (HCréation). Ainsi, la modification de la programmation permet aussi la mise à jour de leur structure... surtout si elle reprend des définitions de rubriques existantes dans l'analyse.
- supérieure au temps d'une session utilisateur : les pseudo temporaires ou masqués de l'analyse. Totalement proscrits, je leurs préfère les fichiers d'analyse, quitte à y piloter des alias (autre dossier au même endroit). En effet, entre deux sessions, une mise à jour du projet peut avoir lieu et là se pose le problème de la mise à jour des structure... et des données. Ces fichiers n'étant décrit dans l'analyse, WDModFic ne sait les traiter faute de référenciel. Ainsi, pour l'instant, sauf à produire un délicat mécanisme d'export-création-import, j'ai préféré à ce moment les proscrire tout simplement pour des utilisation 'générique' (simplification des problèmes). En revanche, pour les besoins ultra spécifiques, je décris ces fichiers dans des classes qui pilotent entièrement le module (VBAExterne dispo sur WDForge) et qui assurent alors la gestion complète du fichier sans aucun lien avec l'analyse...
Mais evidement il ne s'agit que d'une vision personnelle, la vérité est peut-être ailleurs...
++ R&B
Merci à vous tous pour ces conseils.
Je vais tester cela dans une appli test ...
A Bientôt,
JPC
"Romuald.besset" <info@wdforge.org> wrote in message news:<cnsbvi$s33$1@s5.feed.news.oleane.net>...
Michel Herrscher a écrit :
> Bonjour,
>
> Je m'en sers pour les éditions dont la structure des requêtes ( ou de la
> source de données) est trop complexe et/ou doit être programmée avec du
> code.
>
> Ensuite dans l'édition ça roule tout seul... 1 seul fichier, des ruptures en
> veux tu en voilà etc ...cumul, moyenne stat etc ...
>
> Seul écueil pensez en multi utilisateurs au nom du fichier ou à l'endroit
> où on le crée, si jamais ils sont 2 à faire l'édition ensemble....
>
> Je les vide toujours en fin d'édition avec Hferme, Hcreation. ( inutile de
> perdre du temps avec les backups)
> A+
Je met en exergue cependant deux types de temporaires ne me rappelant
pas si le dossier en référence le relève.
Il faut différencier les temporaires selon leur durée de vie.
- le temps d'une session utilisateur : les vrais temporaires.
Ces fichiers sont décrits et utilisés pour une action trés ponctuelle et
précise. Ils sont complètement créés à chaque session (HCréation).
Ainsi, la modification de la programmation permet aussi la mise à jour
de leur structure... surtout si elle reprend des définitions de
rubriques existantes dans l'analyse.
- supérieure au temps d'une session utilisateur : les pseudo temporaires
ou masqués de l'analyse.
Totalement proscrits, je leurs préfère les fichiers d'analyse, quitte à
y piloter des alias (autre dossier au même endroit).
En effet, entre deux sessions, une mise à jour du projet peut avoir lieu
et là se pose le problème de la mise à jour des structure... et des données.
Ces fichiers n'étant décrit dans l'analyse, WDModFic ne sait les traiter
faute de référenciel. Ainsi, pour l'instant, sauf à produire un délicat
mécanisme d'export-création-import, j'ai préféré à ce moment les
proscrire tout simplement pour des utilisation 'générique'
(simplification des problèmes).
En revanche, pour les besoins ultra spécifiques, je décris ces fichiers
dans des classes qui pilotent entièrement le module (VBAExterne dispo
sur WDForge) et qui assurent alors la gestion complète du fichier sans
aucun lien avec l'analyse...
Mais evidement il ne s'agit que d'une vision personnelle, la vérité est
peut-être ailleurs...
Merci à vous tous pour ces conseils. Je vais tester cela dans une appli test ...
A Bientôt,
JPC
"Romuald.besset" wrote in message news:<cnsbvi$s33$...
Michel Herrscher a écrit : > Bonjour, > > Je m'en sers pour les éditions dont la structure des requêtes ( ou de la > source de données) est trop complexe et/ou doit être programmée avec du > code. > > Ensuite dans l'édition ça roule tout seul... 1 seul fichier, des ruptures en > veux tu en voilà etc ...cumul, moyenne stat etc ... > > Seul écueil pensez en multi utilisateurs au nom du fichier ou à l'endroit > où on le crée, si jamais ils sont 2 à faire l'édition ensemble.... > > Je les vide toujours en fin d'édition avec Hferme, Hcreation. ( inutile de > perdre du temps avec les backups) > A+
Je met en exergue cependant deux types de temporaires ne me rappelant pas si le dossier en référence le relève. Il faut différencier les temporaires selon leur durée de vie.
- le temps d'une session utilisateur : les vrais temporaires. Ces fichiers sont décrits et utilisés pour une action trés ponctuelle et précise. Ils sont complètement créés à chaque session (HCréation). Ainsi, la modification de la programmation permet aussi la mise à jour de leur structure... surtout si elle reprend des définitions de rubriques existantes dans l'analyse.
- supérieure au temps d'une session utilisateur : les pseudo temporaires ou masqués de l'analyse. Totalement proscrits, je leurs préfère les fichiers d'analyse, quitte à y piloter des alias (autre dossier au même endroit). En effet, entre deux sessions, une mise à jour du projet peut avoir lieu et là se pose le problème de la mise à jour des structure... et des données. Ces fichiers n'étant décrit dans l'analyse, WDModFic ne sait les traiter faute de référenciel. Ainsi, pour l'instant, sauf à produire un délicat mécanisme d'export-création-import, j'ai préféré à ce moment les proscrire tout simplement pour des utilisation 'générique' (simplification des problèmes). En revanche, pour les besoins ultra spécifiques, je décris ces fichiers dans des classes qui pilotent entièrement le module (VBAExterne dispo sur WDForge) et qui assurent alors la gestion complète du fichier sans aucun lien avec l'analyse...
Mais evidement il ne s'agit que d'une vision personnelle, la vérité est peut-être ailleurs...
