Seite 1 von 1
DbSelectArea()
Verfasst: Di, 11. Apr 2006 14:28
von Manfred
Hi,
mal wieder eine Frage, die bohrt:
Ich mache mir gerade ein paar Gedanken zu folgendem Problem:
Die Funktion DbSelectArea() ist doch eigentlich überflüssig? Ich habe doch immer die Möglichkeit vorher den Alias-> anzugeben und kann damit aus jedem anderen Selectbereich die einzelnen DB ansprechen.
Oder denke ich hier falsch? Nö, oder?
Verfasst: Di, 11. Apr 2006 16:19
von brandelh
Hallo,
wenn man sich strikt an die DBFunktionen() hält und keine Datei Befehle einsetzt, bzw. bei z.B. replace db->feld with db2->feld arbeitet, dann stimmt das. Ich weiße Felder immer mit replace zu, da ich dann nach Feldzuweisungen im Programmeditor suchen kann.
Manche arbeiten halt lieber mit den Befehlen und die müssen die Selectarea aussuchen können.
Verfasst: Di, 11. Apr 2006 16:24
von Manfred
Hi Hubert,
hm, replace wird doch eigentlich nicht mehr verwendet. Ist es nicht wesentlich eleganter den Zuweisungsoperator := zu benutzen? Ich benutze den jetzt schon seit einigen Jahren. Schon allein der Tipperei wegen.
Ja, da fällt mir noch was ein: Ich habe mal irgendwo gelesen, das es wohl üblich wäre, alle DB Felder in je eine Speichervaria abzulegen und dann immer komplett wegzuspeichern.
Ich habe alle Felder einer DB im Objekt abgelegt, lese sie dann ein, editiere diese und schreibe sie wieder zurück. Das geht über eine Schleife und ich spare mir jede einzelne Replace Angabe. Unter Clipper war es so, dass der sowieso alle Felder immer getauscht hat, egal ob angegeben, oder nicht. Meine ich mal so verstanden zu haben beim Support.
Verfasst: Di, 11. Apr 2006 17:04
von brandelh
replace wird doch eigentlich nicht mehr verwendet. Ist es nicht wesentlich eleganter den Zuweisungsoperator := zu benutzen?
das ist reine geschackssache, der Präprozessor macht auch aus replace ein := (wobei er noch ein field-> vor die Variable setzt).
Wie gesagt, ich mag es lieber wenn ich über die Volltextsuche 'REPLACE' alle Felder finden kann.
Ja, da fällt mir noch was ein: Ich habe mal irgendwo gelesen, das es wohl üblich wäre, alle DB Felder in je eine Speichervaria abzulegen und dann immer komplett wegzuspeichern.
Das kommt darauf an.
1. Einen Datenbankeditor sollte immer jede Änderung (nach Rückfrage ?) wegschreiben. Also braucht man auch nicht puffern (macht das GUI Element aber selbst schon, wie das alte GET ja auch).
2. Eingabe von Datensätzen, da sollte man puffern, damit man eine Plausiprüfung machen kann und erst speichert wenn alle Felder plausibel sind. Auch ein Aufheben kann so leicht gemacht werden. Auch das geht über die GUI Puffer, wobei ich lieber umständlicher bin und meine eigenen nutze.
3. Bei Bearbeitung eines Aktenfalles gehe ich noch extremer vor, ähnlich wie Word das ganze Dokument im Speicher hält, speichere ich da den ganzen Datensatz aller DBF Dateien zwischen und nur auf Wunsch wird gespeichert. Dieses wurde hauptsächlich wegen schwacher WAN-Leitungen eingeführt, hat sich aber auch bewährt um bei Schulungen etc. einfach im Fall spielen zu können ohne die Daten wirklich zu ändern.
Es kommt halt immer drauf an, was im Einzelfall besser ist. Sicherlich würde ich die letzte Methode nicht bei einer Massenbelegerfassung nutzen. Bei einem Absturz der Maschine nach 4 Stunden würde ich sicherlich den Tag nicht überleben
.
Unter Clipper war es so, dass der sowieso alle Felder immer getauscht hat, egal ob angegeben, oder nicht. Meine ich mal so verstanden zu haben beim Support.
In einer DBF wird sicherlich auch noch heute immer Satzweise (non exclusive) gelesen und geschrieben. Das wäre sonst von der Performance her viel zu langsam. Ein Zugriff kostet die gleiche Zeit, egal ob ein Feld oder ein Datensatz getauscht wird. Das regelt aber die DBE intern, da muss man sich nicht drum kümmern. Im exclusiven Zugriff geht das sogar weit über die Satzgrenzen hinaus - Microsoft Access sperrt aus diesem Grund z.B. immer 4 kByte Daten auch im Netzwerk.
Verfasst: Di, 11. Apr 2006 17:18
von Tom
Wie gesagt, ich mag es lieber wenn ich über die Volltextsuche 'REPLACE' alle Felder finden kann.
Ich auch, und nicht nur aus diesem Grund. Eine Zuweisung an ein Datenbankfeld ist auch ein qualitativ anderer Vorgang, deshalb halte ich es für wichtig, ihn von Variablenzuweisungen auch optisch leicht unterscheiden zu können.
Verfasst: Di, 11. Apr 2006 17:22
von Manfred
Da merke ich jetzt schon, warum die Angelegenheit zu driften beginnt.
Anfänglich habe ich mir auch meine Gedanken dazu gemacht und gedacht, dass es schwierig wird da durchzublicken, aber irgendwann habe ich mir dann angewöhnt grundsätzlich vor jedes Feld die DB-> zu setzen.
Jetzt gehe ich sogar soweit, dass ich den Compiler anweise alle Unklarheiten anzuzeigen und alles plausibel zu definieren. Sicherlich eine Arbeit für Doofe, aber ich finde es hilft später beim Durchblicken sehr viel. Und vor allen Dingen man bekommt recht früh mit, wenn irgendwas falsch, oder unbenutzt deklariert wurde.
Verfasst: Di, 11. Apr 2006 17:32
von brandelh
Sicherlich eine Arbeit für Doofe, aber ich finde
also ich habe in meinen Anwendungen auch die Warnstufen auf maximal (inkl. unbenützter Variablen). Das finde ich sicherer als auf Tipfehler-Fehlermeldungen zu warten.
Also nix mit doofe, fleisig und vorsichtig bezeichne ich das ...
Verfasst: Di, 11. Apr 2006 17:33
von Manfred
brandelh hat geschrieben:Sicherlich eine Arbeit für Doofe, aber ich finde
also ich habe in meinen Anwendungen auch die Warnstufen auf maximal (inkl. unbenützter Variablen). Das finde ich sicherer als auf Tipfehler-Fehlermeldungen zu warten.
Also nix mit doofe, fleisig und vorsichtig bezeichne ich das ...
Prima, was trinkst Du?