Physische Dateien mit Schlüssel

[cbe]

das einzige dass mir dazu einfällt ist, dass wir zum Jahrtausendwechsel das Jahrhundert in etlichen Dateien zugefügt haben:
1. LFs gelöscht
2. Dateifeld von 6 auf 8 verlängert
3. JH zugefügt (aus 981231 wird 19981231)
4. LFs neu aufgebaut

Und wenn das Datumsfeld dummerweise im Key der PF war, wurde in 3. bei _jedem_ Satz die Datei umsortiert. Das war erheblich langsamer als in 4. die LFs am Schluss komplett neu aufzubauen.

Gruß, Christian

[BenderD]

.. wenn mans richtig gemacht hätte, hätte man die Datei maint vorübergehend auf delayed geändert und am Ende wieder auf immed.
BTW: - da wird nix sortiert
- da hätte man date Felder draus machen sollen
- da gibt es noch die Sache mit dem kaputten Zugriffspfad, wo die PF ohne Key besser abschneidet, habe ich aber noch nicht wirklich gesehen

D*B

das einzige dass mir dazu einfällt ist, dass wir zum Jahrtausendwechsel das Jahrhundert in etlichen Dateien zugefügt haben:
1. LFs gelöscht
2. Dateifeld von 6 auf 8 verlängert
3. JH zugefügt (aus 981231 wird 19981231)
4. LFs neu aufgebaut

Und wenn das Datumsfeld dummerweise im Key der PF war, wurde in 3. bei _jedem_ Satz die Datei umsortiert. Das war erheblich langsamer als in 4. die LFs am Schluss komplett neu aufzubauen.

Gruß, Christian

[cbe]

.. wenn mans richtig gemacht hätte, hätte man die Datei maint vorübergehend auf delayed geändert und am Ende wieder auf immed.
...

ach wenn ich das damals gewusst hätte...

[Fuerchau]

Manche APP's setzen FRCRATIO(1) was bei Massen-Änderungen gewaltig auf die Performance geht.
Da dauert dann eben auch ein CPYF erheblich länger.

Bei solchen Aktionen ggf. auch FRCRATIO prüfen.