zwei Fragen

[Arndt]

Eine Frage:


Hallo Leute, mal zwei Fragen:

Wenn ich in einer Tabelle ein Feld umbenenne, wird die neue Bezeichnung dann in allen Formularen übernommen?

Wieviele Felder sollte denn eine Tabelle maximal haben bzw. ab wann steigt die Wahrscheinlichkeit von Problemen und welche könnten das sein?

Vielen Dank für die Antworten

[DF6GL]

Hallo,

die Übernahme hängt von Access-Einstellungen ab.  Ob das immer und überall funktioniert, würde ich nicht unterschreiben wollen.

Lt. Spezifikation kann eine Tabelle max. 255 Felder enthalten.  Diese Anzahl wird aber in einer normalisierten Umgebung (schon wieder diese schlimme Normalisierung      ) selten, wenn überhaupt erreicht.

PS: 
<Tutorial on>
Beim entwickeln einer DB sollte eine gewisse Reihenfolge eingehalten werden, die das Leben ungemein erleichtert:

0) Festlegung eines Konzeptes:  Was hat man, was will man, was soll die DB leisten

1)  Datenanalyse und Bestimmung der Abhängigkeiten  (das geht, ohne dabei schon an eine Datenbank zu denken)

2)  Zusammenfassung von zusammengehörenden Daten und diese jeweils als eine Tabelle darstellen.
Datentypen strikt(!) beachten, bzw. festlegen.

3) Datenabhängigkeiten als Beziehungen zwischen den Tabellen definieren.

4) Nochmal die Datenbeziehungen auf Plausibilität prüfen, ggflls korrigieren.

5) Nochmal Punkt 4) abarbeiten

6) Nochmal Punkt 5) abarbeiten

7) Je ein Formular  für je eine Tabelle erstellen. (Für die Erstentwicklung hat es sich bei mir, entgegen anderslautenden Meinungen, bewährt, lediglich den Tabellennamen in die Datenherkunft einzutragen und keine Abfrage zu verwenden. Das kann man später nachholen, wenn es überhaupt nötig sein sollte, z. B. für vorgebene Sortierungen.)
1:n Beziehungen mit HFO/UFO-Konstruktion darstellen.
Stammdaten-Auswahlen mit Kombifeldern realisieren.   
Access-Standards benutzen (d.h. nicht tricksen, das kann man später immer noch, wenn alles läuft).  Mehrere Formulare mit selber Datenherkunft sind in den meisten Fällen unnötig.
Keine Makros, gleich VBA-Prozeduren benutzen. Fehlerbehandlung


Nochmal Punkt 6) abarbeiten.

9) Testdaten einpflegen.  Arbeitsvorgänge (Bedienung der DB)  testen.

10) Weiteres Debuggen.

11) User-Benchmark.  Den Anwendern die DB vorlegen und selbstständig  bedienen lassen. Feedback einfordern und DB anpassen.

<Tutorial off>

[Arndt]

Ich habe an anderer Stelle beschrieben, dass ich mit einer Kollegin eine DB mit einer monolitischen Tabelle zweimal an verschiedenen Arbeitsplätzen geöffnet hatte, wobei sich unsere Edits gegenseitig überschrieben. Das ist eigentlich ein Zustand, mit dem ich für meine Zwecke gut leben kann, weil das selten vorkommt und wenn, dann unerheblich.

Bleibt dieser Zustand auch nach einer Normalisierung erhalten, oder muss man dann gleich auf FE/BE-Architektur umsteigen, wenn man Konflikte vermeiden möchte?

[Beaker s.a.]

Hallo Arndt,

Bleibt dieser Zustand auch nach einer Normalisierung erhalten

Klar; - das hat nämlich nichts mit der Aufteilung zu tun.

muss man dann gleich auf FE/BE-Architektur umsteigen, wenn man Konflikte vermeiden möchte?

Das muss man in einer Mehrbenutzerumgebung so oder so. Wie schon
in einem deiner anderen Threads von Franz oder Klaus angemerkt, hast
Du dann EIN Backend (Tabellen, ob nun normalisiert oder nicht) auf dem
Fileserver und für JEDEN User EIN EIGENES Frontend (Abfragen, Formulare
und Code) auf seinem Rechner.
In den Optionen der Frontends stelltst Du dann unter Clienteinstellungen
den "Standard bei Datensatzsperung" auf "bearbeiteter Datensatz" und
setzt das Häkchen bei "Datenbanken mit Sperrung auf Datensatzebene
öffnen". Da bekommt der zweite User eine Meldung, wenn er einen DS
bearbeiten will, der vom ersten User bereits in Bearbeitung ist (Form.Dirty = True).
Und ob ihr ohne diese Aufteilung gut damit leben könnt, ist eigentlich
unerheblich, weil falsch oder zumindest fragwürdig.
Ich mach das gar nicht mehr anders, selbst bei Standalone-DBs, die
nur ich selber verwende, wird geteilt.
gruss ekkehard

[bahasu]

Hallo,

damit Du auf mögliche "Absonderlichkeiten" beim Einsatz der access-eigenen Sperrmethode vorbereitet bist, siehe:
http://www.access-o-mania.de/forum/index.php?topic=19191.msg105451#msg105451

[DF6GL]

Hallo,


das Sperrproblem taucht m. E. in diesem Fall nur dann auf, wenn  die "monolitische Tabelle"   (also eine Tabelle mit allen Datenfeldern und ohne jegliche Normalisierung und Beziehungen)  von mehreren Personen bearbeitet werden soll.

Da wird eben der ganze  DS gesperrt, egal, welches Feld gerade modifiziert wird.   Wäre die Tabelle (DB) normalisiert, also ein DS auf mehrere in Beziehung stehende Tabellen aufgeteilt  (nicht zu verwechseln mit der Aufteilung in FE und BE!) , ist das Risiko, dass der selbe DS in der selben Tabelle von mehreren Personen gleichzeitig im Zugriff ist, deutlich reduziert.


Ich kann nur nochmal (jetzt aber hier in diesen Zusammenhang zum letzten Mal) darauf hinweisen, dass die Anwendung der Normalisierungsregeln  Grundbedingung für eine problemlos arbeitende Db ist...

[Arndt]

<Tutorial off>

Diesen Edit habe ich mir ausgedruckt und an die Wand gehängt. :-)