Beziehung mit RI im Badk-End verschwunden...!?!?
Roland Klassen
habe hier ein Problem, daß mich bis ins Mark erschüttert...!
Wir arbeiten mit einer Access03-DB, Backend und versch. Frontends.
Kontakte und Adressen liegen in verschiedenen Tabellen, da ein Kontakt
mehrere Adressen haben kann. Diese sind natürlich über das Feld KontaktCode
Als Primär- bzw. Fremdschlüssel verbunden mit referentieller Integrität im
Backend.
Heute morgen will ich einige Kontakte löschen, die doppelt angelegt wurden.
Plötzlich fehlt mir einer davon gänzlich. Ich finde ihn dann in einer
automatischen Sicherung des Backends, die 2 x täglich erstellt wird.
Ich sehe in der aktuellen DB nach, ob die jeweiligen Adressen des Kontaktes
noch da sind - und siehe da - sie sind's noch...!?!? Und die RI...????
...Die Beziehung mit der RI im Backend ist weg!
...In der Sicherungs-MDB von heute morgen ist sie noch da.
Es ist EXTREM UNWAHRSCHEINLICH, daß irgendjemand anderes außer mir ins
Backend geht und dort in den Beziehungen doktert!
Kann es sein, daß Access aus irgendeinem Grund einen Fehler produziert, wo
so eine Beziehung "flöten" geht...???
Ich hatte heute morgen eine "Inkonsistenz" oder so etwas ähnliches in einem
anderen Zusammenhang. Habe die Daten bereinigt und das Backend komprimiert
und repariert...
Weiß nicht mehr weiter, wenn ich mich nicht auf die Beziehungen mit RI in
Access verlassen kann...!?
L. G. Roland
Jörg Ackermann
Roland Klassen wrote:
> Kann es sein, daß Access aus irgendeinem Grund einen Fehler produziert, wo so eine Beziehung "flöten" geht...???
> Ich hatte heute morgen eine "Inkonsistenz" oder so etwas ähnliches in
> einem anderen Zusammenhang. Habe die Daten bereinigt und das Backend
> komprimiert und repariert...
Dann könnte das schon sein...
Gruß
Roland Klassen
Das ist aber doch dann mehr als beängstigend, oder...!?
L. G. Roland
Roland Klassen
das aktuelle Backend zu importieren...?
Wenn ich eine Rücksicherung mache, ist ein halber Tag Arbeit von mehreren
Leuten futsch...!
Und die Beziehungen einfach wieder manuell herstellen...? Ich weiß ja nicht,
wo eventuell noch irgendwelche Dinge verschwunden sind...!?
Access hat mich noch nie so geschockt wie heute...!?
L. G. Roland
Jörg Ackermann
Roland Klassen wrote:
>> Dann könnte das schon sein...
>
> Das ist aber doch dann mehr als beängstigend, oder...!?
Inwiefern?
References sind letzendlich nichts weiter wie
Einträge in einer Systemtabelle.
Da kann schon mal was schiefgehen, wenn die
MDB einen Knack bekommt.
Importiere alles in eine neue MDB, kontrolliere
die Beziehungen, setze ggf. neu und gut ist.
Ihr macht regelmäßige Backups? So what...
Unter uns...
Im Office 2007 geht auch schon mal die ganze
ACCDB/MDB nach dem Compact/Repair dahin.
Gruß
Mark Doerbandt
Roland Klassen:
> Wenn ich eine Rücksicherung mache, ist ein halber Tag Arbeit von mehreren
> Leuten futsch...!
dann musst Du haeufiger sichern.
> Access hat mich noch nie so geschockt wie heute...!?
Ich bin auch des Oefteren geschockt!
Wie Leute so drauflosarbeiten... ;-)
Wenn Du mit mehreren Leuten im Team an einer Access-Loesung arbeitest,
solltest Du in jedem Fall die einzelnen Aenderungen protokollieren,
z.B. mit einem Quellcodeverwaltungssystem. Durch die entstehende
Redundanz (die Leute arbeiten dann ja mit lokalen Kopien) hast Du
zusaetzliche Sicherheit. Aenderungen am Backend wuerde ich in so eienr
Umgebung eh nur per SQL geskriptet zulassen.
Gruss - Mark
--
Informationen fuer Neulinge in den Access-Newsgroups unter
http://www.doerbandt.de/Access/Newbie.htm
Bitte keine eMails auf Newsgroup-Beiträge senden.
Roland Klassen
>>
>> Das ist aber doch dann mehr als beängstigend, oder...!?
>
> Inwiefern?
>
> References sind letzendlich nichts weiter wie
> Einträge in einer Systemtabelle.
>
> Da kann schon mal was schiefgehen, wenn die
> MDB einen Knack bekommt.
>
> Importiere alles in eine neue MDB, kontrolliere
> die Beziehungen, setze ggf. neu und gut ist.
:-) Es handelt sich hier um wasweißich wieviele Tabellen mit noch viel mehr
Beziehungen...!!!
>
> Ihr macht regelmäßige Backups? So what...
>
Ja, 2 x täglich wird die DB automatisch gesichert, 1 x täglich sämtliche
Daten auf dem Server auf ein Sicherungsband...
Roland Klassen
>> Leuten futsch...!
>
> dann musst Du haeufiger sichern.
Wo kann ich einstellen, daß die Sicherung stündlich (oder alle 2 Stunden)
erfolgt...?
>
>> Access hat mich noch nie so geschockt wie heute...!?
>
> Ich bin auch des Oefteren geschockt!
> Wie Leute so drauflosarbeiten... ;-)
Ja, aber die RI war bis jetzt für mich eine Schweizer Bank... das Fundament
einer DB... Hier drinnen stehen die komplette Daten eines mittleren Betriebs
mit ca. 15 Angestellten seit ungefähr 10 Jahren... und dann kann mal so 'ne
Grundarchitektur einfach so hopplahopp mirnichtsdirnichts die Segel
streichen...? (Ok, die Daten sind natürlich gesichert... aber was, wenn
ich's nicht zufällig gemerkt hätte... daß die Beziehung weg iss... Dann
hätten wir können unter Umständen munter Datenmüll produzieren für weißnicht
wie lange...!?
>
> Wenn Du mit mehreren Leuten im Team an einer Access-Loesung arbeitest,
> solltest Du in jedem Fall die einzelnen Aenderungen protokollieren,
> z.B. mit einem Quellcodeverwaltungssystem. Durch die entstehende
> Redundanz (die Leute arbeiten dann ja mit lokalen Kopien) hast Du
> zusaetzliche Sicherheit. Aenderungen am Backend wuerde ich in so eienr
> Umgebung eh nur per SQL geskriptet zulassen.
An dem Entwurf der DB arbeite ich alleine. Lediglich ein Kollege kennt sich
etwas aus und weiß schon mal, wie er eine Tabelle öffnen kann... Was
bedeutet "Quellcodeverwaltungssystem" bzw. "nur per SQL geskriptet"...? (Die
Leute arbeiten jetzt ja auch mit lokalen Kopien des Front-Ends)...
L. G. Roland
Jörg Ackermann
Roland Klassen wrote:
> :-) Es handelt sich hier um wasweißich wieviele Tabellen mit noch
> viel mehr Beziehungen...!!!
Dann laß' Dir die References jeweils zB. in eine
Textdatei ausgeben und vergleiche sie.
Gruß
Roland Klassen
> References sind letzendlich nichts weiter wie
> Einträge in einer Systemtabelle.
>
kopieren...?
L. G. Roland
Jörg Ackermann
Jörg Ackermann wrote:
> Dann laß' Dir die References...
Sorry, Relations latürnich.
Vielleicht hilft Dir ja sowas:
SELECT
MSysRelationships.szReferencedObject,
MSysRelationships.szReferencedColumn,
MSysRelationships.szObject,
MSysRelationships.szColumn,
MSysRelationships.szRelationship,
MSysRelationships.grbit
FROM MSysRelationships
ORDER BY MSysRelationships.szReferencedObject;
Gruß
Roland Klassen
>> :-) Es handelt sich hier um wasweißich wieviele Tabellen mit noch
>> viel mehr Beziehungen...!!!
>
> Dann laß' Dir die References jeweils zB. in eine
> Textdatei ausgeben und vergleiche sie.
>
grafischen Beziehungsfenster erstellt...
G. Roland
Mark Doerbandt
Roland Klassen:
> Wo kann ich einstellen, daß die Sicherung stündlich (oder alle 2 Stunden)
> erfolgt...?
womit sicherst Du denn?
> Ja, aber die RI war bis jetzt für mich eine Schweizer Bank... das Fundament
> einer DB... Hier drinnen stehen die komplette Daten eines mittleren Betriebs
> mit ca. 15 Angestellten seit ungefähr 10 Jahren... und dann kann mal so 'ne
> Grundarchitektur einfach so hopplahopp mirnichtsdirnichts die Segel
> streichen...?
Es sind doch nur die Beziehungen weg, oder?
> An dem Entwurf der DB arbeite ich alleine. Lediglich ein Kollege kennt sich
> etwas aus und weiß schon mal, wie er eine Tabelle öffnen kann... Was
> bedeutet "Quellcodeverwaltungssystem" bzw. "nur per SQL geskriptet"...? (Die
> Leute arbeiten jetzt ja auch mit lokalen Kopien des Front-Ends)...
OK, dann haben wir aneinander vorbei geredet. Ich hatte es so
verstanden, dass alle Leute im Team an der Applikation entwickeln.
Du musst doch nur die Beziehungen wieder herstellen, dann sollte alles
wieder so sein wie vorher.
Zum Thema Quellcodeverwaltung:
http://www.codekabinett.com/rdumps.php?targetDoc=ScmAcc
und zum Thema "Skripten des Backends": ich mache das in der Regel so,
dass ich im Frontend eine Prozedur habe, die das Backend aktualisiert,
wenn es Aenderungen gibt. Da koenntest Du z.B. auch eine Pruefung
einbauen, ob alle Strukturen (incl. Beziehungen) noch so sind, wie Du
es erwartest.
Peter Doering
Roland Klassen wrote:
Normalerweise schon: Datei - Externe Daten - Importieren - Backup.mdb
auswaehlen - unter Optionen Beziehungen anklicken.
Gruss - Peter
--
Ich beantworte keine Fragen per Email.
Mitglied im http://www.dbdev.org
FAQ: http://www.donkarl.com
Oliver Straub
> Ja, aber die RI war bis jetzt für mich eine Schweizer Bank... das
> Fundament einer DB...
was bringt Dir den die RI, warum ist die Dir so wichtig?
(Leg mal als "Sicherheitskopie" ein leere DB mit Deinen Bez. an. Wenn die
Bez. mal wieder verschwunden sind, musst Du nur die Daten in die
"Sicherheitskopie" schieben.)
Gruss
Oliver
Roland Klassen
>
>> Ja, aber die RI war bis jetzt für mich eine Schweizer Bank... das
>> Fundament einer DB...
>
> was bringt Dir den die RI, warum ist die Dir so wichtig?
>
Detail-Datensätze zu Master-Datensätzen, die es gar nicht gibt...!?
> (Leg mal als "Sicherheitskopie" ein leere DB mit Deinen Bez. an. Wenn die
> Bez. mal wieder verschwunden sind, musst Du nur die Daten in die
> "Sicherheitskopie" schieben.)
>
Kann ich die Daten dann einfach in das "Tabellengerüst" schieben...? Was
passiert mit den Nummern, die per Autowert vergeben wurden bzw. deren
Detail-Datensätzen...?
Gruß Roland
Roland Klassen
>>> References sind letzendlich nichts weiter wie
>>> Einträge in einer Systemtabelle.
>>>
>> Kann ich die dann nicht einfach von der Sicherung-MDB in die aktuelle MDB
>> kopieren...?
>
> Normalerweise schon: Datei - Externe Daten - Importieren - Backup.mdb
> auswaehlen - unter Optionen Beziehungen anklicken.
>
Tabellen und neue Daten...?
Gruß Roland
Stefan Dase
> ...Die Beziehung mit der RI im Backend ist weg!
Nur mal sicherheitshalber nachgefragt: Die Beziehungen sind nicht nur
nicht angezeigt, sondern wirklich weg? Man kann das Beziehungsfenster
auch total löschen, ohne dass sich an den RIs etwas ändert. Um alles
wieder anzuzeigen, muss man nur das Symbol "Alle Beziehungen anzeigen"
neben dem Löschen-Kreuz anklicken.
Viele Grüße aus Bremen,
Stefan
Roland Klassen
>> ...Die Beziehung mit der RI im Backend ist weg!
>
> Nur mal sicherheitshalber nachgefragt: Die Beziehungen sind nicht nur
> nicht angezeigt, sondern wirklich weg? Man kann das Beziehungsfenster auch
> total löschen, ohne dass sich an den RIs etwas ändert. Um alles wieder
> anzuzeigen, muss man nur das Symbol "Alle Beziehungen anzeigen" neben dem
> Löschen-Kreuz anklicken.
>
Masterdatensatz anlegen, den es überhaupt nicht gibt..!
Gruß Roland
Oliver Straub
>> was bringt Dir den die RI, warum ist die Dir so wichtig?
>>
> Na die sorgt doch dafür, daß kein "Datenmüll" angelegt wird - keine
> Detail-Datensätze zu Master-Datensätzen, die es gar nicht gibt...!?
wo sollten die den angelegt werden?
RI bereitet IMO nichts als Ärger. Beim internen arbeiten mit DS oder zB. im
Zusammenhang mit diversen Schnittstellen, werden DS nicht angefügt, weil
kein Master-DS vorhanden ist. Diese DS sind aber kein Datenmüll, es fehlt
einfach nur ein (Master-) DS, denn könnte man ganz schnell nachträglich
erfassen. Wegen RI wird aber verhindert, dass diese DS angefügt werden
können.
Anfänglich habe ich auch mit Beziehungen gearbeitet, nachdem das für mich
nur Nachteile brachte, bin ich davon abgekommen. Für eine
Anwendungsprogrammierung ist das überflüssig, wenn man direkt in den
Tabellen arbeitet, brigt's vermutlich schon Vorteile.
> Kann ich die Daten dann einfach in das "Tabellengerüst" schieben...? Was
> passiert mit den Nummern, die per Autowert vergeben wurden bzw. deren
> Detail-Datensätzen...?
Du benutzt doch nicht etwa Autowerte als Fremdschlüssel? Das wäre keine gute
Idee!
Gruss
Oliver
Peter Doering
Roland Klassen wrote:
Weiss nicht, was du meinst. Du musst keine Tabellen oder sonstigen Objekte
auswaehlen. Es wird nur importiert, was ausgewaehlt ist. Teste einfach mal
mit einer Kopie.
Jörg Ackermann
Oliver Straub wrote:
> RI bereitet IMO nichts als Ärger.
Ja, da ist er doch, unser Weihnachts-Tread... ;-)
Gruß
Mark Doerbandt
Jörg Ackermann:
>> RI bereitet IMO nichts als Ärger.
> Ja, da ist er doch, unser Weihnachts-Tread... ;-)
schade, dass Michael nicht mehr hier ist!
;-) Gruss - Mark
Roland Klassen
>
>>>>> References sind letzendlich nichts weiter wie
>>>>> Einträge in einer Systemtabelle.
>>>>>
>>>> Kann ich die dann nicht einfach von der Sicherung-MDB in die aktuelle
>>>> MDB
>>>> kopieren...?
>>>
>>> Normalerweise schon: Datei - Externe Daten - Importieren - Backup.mdb
>>> auswaehlen - unter Optionen Beziehungen anklicken.
>>>
>> Ja, schon... aber ich meine "nur" die (verlorenen) Beziehungen - ohne
>> neue
>> Tabellen und neue Daten...?
>
> Weiss nicht, was du meinst. Du musst keine Tabellen oder sonstigen Objekte
> auswaehlen. Es wird nur importiert, was ausgewaehlt ist. Teste einfach mal
> mit einer Kopie.
>
anscheinend nur auf die ausgewählten Tabellen - und diese kann ich entweder
mit "Definition und Daten" oder nur "Definition" auswählen. Somit importiert
er mir immer eine neue Tabelle anstatt er mir die alte beibehält und nur die
Beziehungen importiert...
Gruß Roland
Roland Klassen
Nein, aber als Primärschlüssel...
Gruß Roland
Roland Klassen
"Mark Doerbandt" <spamre...@doerbandt.de> schrieb im Newsbeitrag
news:eme7e...@dit8.doerbandt.de...
tststs... die einen weinen... die anderen freuen sich, darüber zu
diskutieren... ;-)
Oliver Straub
>> gute
>
> Nein, aber als Primärschlüssel...
Das ist egal, dann kannst Du die Daten rüberschieben.
Hast Du mal versucht die DS von MSysRelationships aus der Sicherungskopie
rüberzuschieben? Wenn das geht, wäre das doch das Einfachste.
Gruss
Oliver
Roland Klassen
die Sys-DBs ran... Kann ich die irgendwo einblenden...?
Gruß Roland
Oliver Straub
> die Sys-DBs ran... Kann ich die irgendwo einblenden...?
Optionen/Ansicht/Systemobjekte Haken rein.
Peter Doering
Jo, in der Tat, gerade getestet. Falls du mit den bisherigen Vorschlaegen
nicht klar kommen solltest:
- Mach einen Rename auf die vorhandenen Tabellen.
- Importiere alle Tabellen aus dem Backup, *einschl.* Beziehungen.
- Leere die importierten Tabellen und mach Append-Abfragen von den
gesicherten auf die leeren importierten Tabellen.
Roland Klassen
Arbeit...!
Gruß Roland
Roland Klassen
der PrimärCode ein Autowert ist...? Der wird doch dann wahrscheinlich neu
vergeben...? Und die Detail-Datensätze kennen Ihren Master-DS nicht
mehr...!?
Gruß Roland
Jörg Ackermann
Roland Klassen wrote:
> Ach so... Was ist dann mit den in Beziehungstehenden Datensetztn, bei
> denen der PrimärCode ein Autowert ist...? Der wird doch dann
> wahrscheinlich neu vergeben...? Und die Detail-Datensätze kennen
> Ihren Master-DS nicht mehr...!?
Man verwendet Anfügeabfragen.
Dann wird kein neuer Autowert vergeben.
Aber bevor der Wahnsinn weitere Kreise zieht,
vergleiche doch erst mal, welche Relations
überhaupt fehlen.
Gruß
Roland Klassen
anderen Primär-Tabelle). In diesen beiden Primärtabellen gibts keinen
Primärschlüssel mehr. Der ehemalige Prmärschlüssel enthält jetzt Duplikate.
Das Ding ist aber ein Autowert. !?!?!?
Gruß Roland
Peter Doering
Roland Klassen wrote:
>>> Ach so... Was ist dann mit den in Beziehungstehenden Datensetztn, bei
>>> denen der PrimärCode ein Autowert ist...? Der wird doch dann
>>> wahrscheinlich neu vergeben...? Und die Detail-Datensätze kennen
>>> Ihren Master-DS nicht mehr...!?
>>
>> Man verwendet Anfügeabfragen.
>> Dann wird kein neuer Autowert vergeben.
bzw. es wird nur dann ein neuer Autowert vergeben, wenn der Autowert nicht
Bestandteil der Anfuegeabfrage ist. Wenn man ihn behalten will/muss, muss
man ihn natuerlich angeben.
>> Aber bevor der Wahnsinn weitere Kreise zieht,
>> vergleiche doch erst mal, welche Relations
>> überhaupt fehlen.
>>
> So... Sch... Es fehlen 19 Beziehungen (18 einer Primär-Tabelle und 1 einer
> anderen Primär-Tabelle). In diesen beiden Primärtabellen gibts keinen
> Primärschlüssel mehr. Der ehemalige Prmärschlüssel enthält jetzt Duplikate.
> Das Ding ist aber ein Autowert. !?!?!?
Die Tatsache Autowert stellt noch keine Eindeutigkeit sicher. Z.B. ist es
moeglich, per Einfuegeabfrage die gleichen Werte zu schreiben. Erst der
Index ohne Duplikate macht das Feld eindeutig.
Oliver Straub
> denen der PrimärCode ein Autowert ist...? Der wird doch dann
> wahrscheinlich neu vergeben...? Und die Detail-Datensätze kennen Ihren
> Master-DS nicht mehr...!?
Die Detail-Sätze kennen ihren Master-DS nicht mehr, weil Du aus einem
Autowert einen Fremdschlüssel gemacht hast! Auch wenn das Tabellenfeld des
"Detail"-Satzes das den Autowert speichert als Primärschlüssel definiert
ist, ist der Autowert im Detailsatz ein Fremdschlüssel.
Du machst Dir Gedanken wegen den verschwundenen Beziehungen, aber benutzt
Autowerte als Fremdschlüssel. Ts, ts, Du solltest über den Begriff Priorität
nachdenken. :-)
Gruss
Oliver
Jörg Ackermann
Roland Klassen wrote:
> So... Sch... Es fehlen 19 Beziehungen (18 einer Primär-Tabelle und 1
> einer anderen Primär-Tabelle). In diesen beiden Primärtabellen gibts
> keinen Primärschlüssel mehr. Der ehemalige Prmärschlüssel enthält
> jetzt Duplikate. Das Ding ist aber ein Autowert. !?!?!?
Na ok, dann lösche die Duplikate sinnig raus,
setze die Primärschlüssel und lege die Beziehungen
neu an und gut ist.
Dann alles in eine neue MDB importieren und
nochmal kontrollieren ob alles ok ist.
Gruß
Thomas Möller
Oliver Straub <oliver.s...@web.de> schrieb:
> RI bereitet IMO nichts als Ärger.
wenn Du aus Sicht eine professionellen Anwenders sprichst, der immer
ganz genau weiss, was er da tut und niemals Fehler macht, dann könnte
man eventuell geneigt sein, diesem Statement zu folgen.
In der Realität haben wir es aber selten mit wirklich professionellen
Anwendern zu tun sondern eher mit Datenbank-DAU's. Diejenigen, die
glauben, Profis zu sein, wissen auch nicht immer in letzter Konsequenz,
was sie da tun. Und die User, die niemals Fehler machen sind mehr als
selten.
Da also die Prämissen nicht haltbar sind, verlasse ich mich lieber auf
die RI anstatt auf Fähigkeiten des Anwenders.
> Beim internen arbeiten mit DS oder
> zB. im Zusammenhang mit diversen Schnittstellen, werden DS nicht
> angefügt, weil kein Master-DS vorhanden ist. Diese DS sind aber kein
> Datenmüll, es fehlt einfach nur ein (Master-) DS, denn könnte man
> ganz schnell nachträglich erfassen. Wegen RI wird aber verhindert,
> dass diese DS angefügt werden können.
Wenn man die Datensätze in den Tabellen in der entsprechen den
Reihenfolge eingibt oder importiert gibt es auch mit der RI kein
Problem. Klar ist es eventuell etwas unbequem, wenn man nicht einfach
eben so seine Daten importieren kann sondern sich erst Gedanken über die
Abhängigkeiten zwischen den Tabellen machen muss um dann die fehlenden
Masterdatensätze zu erzeugen. Dafür hat man dann aber auch konsistente
Daten. Unabhängig davon, ob der User verstanden hat, was er da tut -
oder eben nicht.
> Anfänglich habe ich auch mit Beziehungen gearbeitet, nachdem das für
> mich nur Nachteile brachte, bin ich davon abgekommen. Für eine
> Anwendungsprogrammierung ist das überflüssig, wenn man direkt in den
> Tabellen arbeitet, brigt's vermutlich schon Vorteile.
Direkt in die Tabellen sollte man den User sowieso nicht arbeiten
lassen. Also müssen Formulare und Abfragen her. Hier willst Du dann die
notwendigen Mechanismen implementieren, um zu verhindern, dass Datenmüll
erfasst werden kann. Das wird aber ganz schön aufwendig. Wozu dass
ganze, wenn Access Dir die Arbeit abnehmen kann?
Ich bleibe bei meinem Statement:
RI ist kein "Kann" sondern ein "Muss".
CU
--
Thomas
Homepage: www.Team-Moeller.de
Oliver Straub
>> RI bereitet IMO nichts als Ärger.
>
> wenn Du aus Sicht eine professionellen Anwenders sprichst, der immer ganz
> genau weiss, was er da tut und niemals Fehler macht, dann könnte man
> eventuell geneigt sein, diesem Statement zu folgen.
> In der Realität haben wir es aber selten mit wirklich professionellen
> Anwendern zu tun sondern eher mit Datenbank-DAU's. Diejenigen, die
> glauben, Profis zu sein, wissen auch nicht immer in letzter Konsequenz,
> was sie da tun. Und die User, die niemals Fehler machen sind mehr als
> selten.
> Da also die Prämissen nicht haltbar sind, verlasse ich mich lieber auf die
> RI anstatt auf Fähigkeiten des Anwenders.
welche Fähigkeiten meinst Du, wenn Du dabei an RI denkst?
Die RI besteht aus zwei Regeln:
1. Ein neuer Datensatz kann nicht in einer Tabelle mit einem Fremdschlüssel
eingefügt werden, wenn ein entsprechender Wert nicht in der refernzierten
Tabelle existiert.
2. Wenn ein Wert in einer Tabelle, die durch einen Fremdschlüssel
referenziert ist, geändert oder gelöscht wird, dürfen die Datensätze in der
Tabelle mit dem Fremdschlüssel nicht 'in der Luft' hängen.
Da wird doch nur eine selbstredende Selbstverständigkeit in zwei Regeln mit
einem hübschen Namen verpackt und zum Verkauf feil geboten. Wie immer. (Der
Name ist nicht nur hübsch, er ist sogar schnittig. "Referenzielle
Integrität" das klingt schon so wie Erfolg, so wie Sieg, so wie alles
beherrschend ... ist aber nur leere Luft, puff, puff.)
> Wenn man die Datensätze in den Tabellen in der entsprechen den Reihenfolge
> eingibt oder importiert gibt es auch mit der RI kein Problem. Klar ist es
> eventuell etwas unbequem, wenn man nicht einfach eben so seine Daten
> importieren kann sondern sich erst Gedanken über die Abhängigkeiten
> zwischen den Tabellen machen muss um dann die fehlenden Masterdatensätze
> zu erzeugen. Dafür hat man dann aber auch konsistente Daten. Unabhängig
> davon, ob der User verstanden hat, was er da tut - oder eben nicht.
Bei den Schnittstellen geht's ja nicht um eigene Daten, sondern die Daten
kommen meistens von anderen. Da kannst Du Dir aber lange Gedanken darüber
machen, auf was für Probleme du da treffen kannst. Die RI ist nie ein
Freund, die ist immer nur ein Nörgler der Fehlermeldungen produziert. Was
auch immer der User versteht oder nicht, eine Fehlermeldung ist für ihn eine
Fehlermeldung und Fehlermeldungen sagen, dass der Entwickler seine Software
nicht im Griff hat. (Es sei den man arbeitet bei SAP.)
Meistens würde es der Anwender gar nicht merken, das ein MasterDS fehlt,
wenn der verwendete Fremdschlüssel im Kontext steht. Der AW tipp zB. einfach
eine Titel-Nr ein und ohne zu merken, dass der DS des Titels noch nicht
existierte, kommt er zu den Detaildatensätzen.
> Direkt in die Tabellen sollte man den User sowieso nicht arbeiten lassen.
> Also müssen Formulare und Abfragen her. Hier willst Du dann die
> notwendigen Mechanismen implementieren, um zu verhindern, dass Datenmüll
> erfasst werden kann. Das wird aber ganz schön aufwendig. Wozu dass ganze,
> wenn Access Dir die Arbeit abnehmen kann?
Ich kann nach wie vor nicht verstehen, wie man im Sinne RI Datenmüll
erfassen könnte. Das Wort Datenmüll ist mehr was für die Alchemistenküche
der Systemadministratoren. Man kommt doch eh nicht ohne Datensicherungen aus
falls mal was kaputt geht. Die RI nimmt einem dabei kein Stück Arbeit ab,
die löst höchstens eine Fehlermeldung aus.
Ich implementiere keine Mechanismen um RI beim Erfassen zu gewährleisten,
das ergibt sich von alleine. Meist durch die Abfragen der Formulare. Da
würde es einen Fehler geben, wenn der Mastersatz fehlen würde, also vergesse
ich mein me.refresh nie und das ist auch schon alles.
Die Aktualisierungsweitergabe ist vielleicht noch nützlich, auf die
Löschweitergabe kann ich gut verzichten. Beim Löschen behalte ich doch
lieber selber die Kontrolle über das was da gelöscht wird. Aber bitte, diese
Funktionen könnten vielleicht noch ein Pluspunkt der RI sein.
> Ich bleibe bei meinem Statement:
> RI ist kein "Kann" sondern ein "Muss".
Dieser Beobachtung schließ ich mich an!
Wenn man mit RI arbeitet gibt's kein "Kann" mehr, sondern nur noch "Muss".
Fazit:
Wenn ich mich quälen will geh ich zu Opus Dei.;-)
Gruss
Oliver
![Henry Habermacher [MVP Access]'s profile photo](http://lh3.googleusercontent.com/a-/ALV-UjXPfmOOaa8EFpRmZBPn2kitX4o3ceZ35GdaeT4JdvuolYogn_8=s40-c)
Henry Habermacher [MVP Access]
quoting Mark Doerbandt:
> schade, dass Michael nicht mehr hier ist!
Vielleicht sollten wir ihn anpingen, den MZ aus Mz (normalerweise hört er
auf diese Kürzel ;-))
Gruss
Henry
Josef Poetzl
Oliver Straub schrieb:
>>> RI bereitet IMO nichts als Ärger.
>>
>> wenn Du aus Sicht eine professionellen Anwenders sprichst, der immer ganz
>> genau weiss, was er da tut und niemals Fehler macht, dann könnte man
>> eventuell geneigt sein, diesem Statement zu folgen.
>> In der Realität haben wir es aber selten mit wirklich professionellen
>> Anwendern zu tun sondern eher mit Datenbank-DAU's. Diejenigen, die
>> glauben, Profis zu sein, wissen auch nicht immer in letzter Konsequenz,
>> was sie da tun. Und die User, die niemals Fehler machen sind mehr als
>> selten.
>> Da also die Prämissen nicht haltbar sind, verlasse ich mich lieber auf die
>> RI anstatt auf Fähigkeiten des Anwenders.
>
> welche Fähigkeiten meinst Du, wenn Du dabei an RI denkst?
Die Löschung eines Datensatzes verhindern, solange er von anderen
Datensätzen benötigt wird. Diese Verhinderung sollte unabhängig vom FE
sein, denn wer weiß, ob ein BE nicht von mehreren unabhängigen FE
bedient wird.
Vom User erwarte ich nicht, dass er weiß, wo dieser DS überall
verwendet wird. Vom DBMS erwarte ich das schon. ;)
mfg
Josef
Peter Doering
Thomas Möller wrote:
> Oliver Straub <oliver.s...@web.de> schrieb:
>> RI bereitet IMO nichts als Ärger.
>
> wenn Du aus Sicht eine professionellen Anwenders sprichst, der immer
> ganz genau weiss, was er da tut und niemals Fehler macht, dann könnte
> man eventuell geneigt sein, diesem Statement zu folgen.
> In der Realität haben wir es aber selten mit wirklich professionellen
> Anwendern zu tun sondern eher mit Datenbank-DAU's. Diejenigen, die
> glauben, Profis zu sein, wissen auch nicht immer in letzter Konsequenz,
> was sie da tun. Und die User, die niemals Fehler machen sind mehr als
> selten.
> Da also die Prämissen nicht haltbar sind, verlasse ich mich lieber auf
> die RI anstatt auf Fähigkeiten des Anwenders.
Ich denke, das ist nicht die Frage. Der Anwender darf nie die Entscheidung
haben, welche Daten er eingeben will oder nicht, sondern das System muss
ihm per Korsett die Vollstaendigkeit der Daten abverlangen, sprich, nach
Form_BeforeUpdate muss die Konsistenz gewahrt sein.
Die Frage ist, ob dafuer die /eingebaute/ RI Verwendung finden sollte oder
nicht. Und da kann man geteilter Meinung sein. Ich z.B. nutze sie nicht,
weil ich meine (eigenentwickelte) Replikation nicht der bordeigenen RI
unterordnen will, sondern selbst sicherstelle, dass zum Ende der
Replikation alle Daten konsistent sind.
> Ich bleibe bei meinem Statement:
> RI ist kein "Kann" sondern ein "Muss".
Jo, aber das "wie" ist entscheidend.
Oliver Straub
>> welche Fähigkeiten meinst Du, wenn Du dabei an RI denkst?
>
> Die Löschung eines Datensatzes verhindern, solange er von anderen
> Datensätzen benötigt wird. Diese Verhinderung sollte unabhängig vom FE
> sein, denn wer weiß, ob ein BE nicht von mehreren unabhängigen FE
> bedient wird.
> Vom User erwarte ich nicht, dass er weiß, wo dieser DS überall
> verwendet wird. Vom DBMS erwarte ich das schon. ;)
das Löschen ist sicherlich das wesendliche Thema im Zusammenhang mit RI.
Durch unzulängliches Löschen kann tatsächlich Datenmüll entstehen. Das kennt
man noch von Früher. Da wurde ein Programm erweitert und dabei neu Dateien
(vgl.Tabellen) eingeführt. An alles wurde gedacht, aber nicht an die
Erweiterung der Löschfunktionen. Wenn dann gelöscht wurde, blieben die neuen
Daten erhalten. Auf Grund der geringen Plattenkapazitäten wurde das dann
schnell zu einem Problem. Das wäre natürlich mit RI nicht passiert.
Einerseits hätten die unteren DS nicht gelöscht werden können, andererseits
hätte man sich darum gar nicht kümmern müssen, wenn man mir Löschweitergabe
gearbeitet hätte. Das aber Daten gelöscht werden könnten, die noch benötigt
werden würden, ist IMO eher ein untypisches Problem.
Ich gebe gern zu, dass ich erst vor einigen Tagen drauf gestoßen bin, dass
man in einem Programm von mir Datenmüll im Sinne von Detailsätzen ohne
Mastersatz, produzieren könnte. Eigentlich sollen die User nur mit von mir
eingebauten Funktionen arbeiten, drum blende ich auch alle Toolbars aus.
Einige User haben sich aber schon an den Toolbar "Formular" gewöhnt und
benutzen ihn gerne. Was ich nicht bedacht hatte war, dass man über den
Toolbar auch Mastersätze löschen kann, ohne dass das auf die Detailsätze
übertragen wird. Naja, jetzt hab ich in dem Formular den Beim Löschen Event
aktiviert und nun ist die Sache wieder konsistent.
Was ist denn, wenn ich RI und die Löschweitergabe aktiviert habe und ein
schlauer User denkt sich er müsste schnell mal ein paar DS direkt in einer
Tabelle löschen. Da kommt dann die Frage wegen der Löschweitergabe und da
klickt er schnell auf OK und schwups sind einige 100 bis mehrere 1000
Detailsätze verschwunden. Ich habe mehr Angst um meine Detailsätze als um
die Mastersätze. Das Verhältnis steht doch da meisten > 1:100. Ich halte es
nicht für die richtige Betrachtungsweise, dass 1 DS mehr wert seien soll als
100 DS.
Eine der direkten Folgen der RI in meinen alten Programmen war, dass wegen
fehlender Mastersätze viele hundert DS manuell erfasst werden mussten. Das
möchte ich meinen Usern nicht mehr zumuten.
Gruss
Oliver
Josef Poetzl
Oliver Straub schrieb:
>>> welche Fähigkeiten meinst Du, wenn Du dabei an RI denkst?
>> Die Löschung eines Datensatzes verhindern, solange er von anderen
>> Datensätzen benötigt wird. [...]
>
> das Löschen ist sicherlich das wesendliche Thema im Zusammenhang mit RI.
> Durch unzulängliches Löschen kann tatsächlich Datenmüll entstehen.
[...]
> Das aber Daten gelöscht werden könnten, die noch benötigt
> werden würden, ist IMO eher ein untypisches Problem.
Ich glaub in komplexeren Anwendungen ist es durchaus ein mögliches
Szenario. Nicht immer ist jedem User klar, wo der aktuelle DS überall
benötigt wird.
Du musst natürlich nicht die Prüfung vom DBMS verwenden. Im Prinzip
kannst du auch vor dem Löschen per Programmcode prüfen, ob überhaupt
gelöscht werden darf. Ich selbst verbiete das Löschen aber lieber per
DBMS, da ich mir dann sicher sein kann, dass ich nicht durch das
Vergessen einer Aktualisierung irgendeiner Löschfunktion im FE
Datenmüll erzeuge.
[Traue nie einem FE-Programmierer, erst recht nicht, wenn du es selbst
bist. ;) ]
Auch wenn ich im neuen FE alle Prüfungen berücksichtige, wie
verhindere ich dann, dass nicht doch irgendein User ein "altes" FE
verwendet, das die eine Prüfung nicht durchführt?
[...]
> Was ist denn, wenn ich RI und die Löschweitergabe aktiviert habe und ein
> schlauer User denkt sich er müsste schnell mal ein paar DS direkt in einer
> Tabelle löschen. Da kommt dann die Frage wegen der Löschweitergabe und da
> klickt er schnell auf OK und schwups sind einige 100 bis mehrere 1000
> Detailsätze verschwunden.
Darum wirst du in meinen AnwendungsDB nie eine aktivierte
Löschweitergabe finden. ;)
RI <> Löschweitergabe
> Ich habe mehr Angst um meine Detailsätze als um
> die Mastersätze. Das Verhältnis steht doch da meisten > 1:100. Ich halte es
> nicht für die richtige Betrachtungsweise, dass 1 DS mehr wert seien soll als
> 100 DS.
> Eine der direkten Folgen der RI in meinen alten Programmen war, dass wegen
> fehlender Mastersätze viele hundert DS manuell erfasst werden mussten. Das
> möchte ich meinen Usern nicht mehr zumuten.
Was hindert dich daran, zuerst die fehlenden Master-DS anzulegen und
erst dann die Detail-DS zu importieren?
mfg
Josef
Thomas Möller
Peter Doering <nos...@doering.org> schrieb:
>> wenn Du aus Sicht eine professionellen Anwenders sprichst, der immer
>> ganz genau weiss, was er da tut und niemals Fehler macht, dann könnte
>> man eventuell geneigt sein, diesem Statement zu folgen.
>> In der Realität haben wir es aber selten mit wirklich professionellen
>> Anwendern zu tun sondern eher mit Datenbank-DAU's. Diejenigen, die
>> glauben, Profis zu sein, wissen auch nicht immer in letzter
>> Konsequenz, was sie da tun. Und die User, die niemals Fehler machen
>> sind mehr als selten.
>> Da also die Prämissen nicht haltbar sind, verlasse ich mich lieber
>> auf die RI anstatt auf Fähigkeiten des Anwenders.
>
> Ich denke, das ist nicht die Frage. Der Anwender darf nie die
> Entscheidung haben, welche Daten er eingeben will oder nicht, sondern
> das System muss ihm per Korsett die Vollstaendigkeit der Daten
> abverlangen, sprich, nach Form_BeforeUpdate muss die Konsistenz
> gewahrt sein.
Darin stimmen wird absolut überein. Die Anwendung bestimmt, welche Daten
sie zulässt und welche nicht.
Mit meiner Aussage wollte ich deutlich machen, warum ich eine technische
Lösung als zwingend notwendig ansehe.
> Die Frage ist, ob dafuer die /eingebaute/ RI Verwendung finden sollte
> oder nicht. Und da kann man geteilter Meinung sein. Ich z.B. nutze
> sie nicht, weil ich meine (eigenentwickelte) Replikation nicht der
> bordeigenen RI unterordnen will, sondern selbst sicherstelle, dass
> zum Ende der Replikation alle Daten konsistent sind.
Meinungen kann man schon teilen. ;-)
Du musst zugeben, dass die Anforderungen Deiner Anwendung an dieser
Stelle schon sehr speziell sind. In diesem Fall hätte ich es auch selbst
ausprogrammiert.
Im Regelfall wird es aber doch so sein, dass durch die Verwendung der RI
auf einfach Art die Konsistenz der Daten sichergestellt werden kann.
Ohne dass Du viel programmieren musst.
Bei der Diskussion mit Oliver geht es nicht um das "wie" sondern um das
"ob". Und da sind wir uns beide einig. :-)
>> Ich bleibe bei meinem Statement:
>> RI ist kein "Kann" sondern ein "Muss".
Ich ergänze noch:
RI ist keine Frage des Stils sondern der Effektivität.
CU
--
Thomas
Homepage: www.Team-Moeller.de
Ich wünsche allen frohe und besinnliche Weihnachtsfeiertage
Thomas Möller
Oliver Straub <oliver.s...@web.de> schrieb:
> welche Fähigkeiten meinst Du, wenn Du dabei an RI denkst?
>
> Die RI besteht aus zwei Regeln:
> 1. Ein neuer Datensatz kann nicht in einer Tabelle mit einem
> Fremdschlüssel eingefügt werden, wenn ein entsprechender Wert nicht
> in der refernzierten Tabelle existiert.
> 2. Wenn ein Wert in einer Tabelle, die durch einen Fremdschlüssel
> referenziert ist, geändert oder gelöscht wird, dürfen die Datensätze
> in der Tabelle mit dem Fremdschlüssel nicht 'in der Luft' hängen.
Genau darum geht es. Die Fähigkeit der RI ist es zu verhindern, dass
inkonsistente Datensätze entstehen. Wenn mir Access dafür einen einfach
zu nutzenden Mechanismus anbietet, dann sehe ich keinen Grund darauf zu
verzichten. Ich könnte nur verlieren.
Entweder verliere ich viel Zeit, weil ich selbst durch meine
Programmierung die Konsistenz der Daten erzwingen muss oder ich verliere
meine Datenqualität. Dann darf ich später viel Zeit dafür aufwenden, die
fehlenden oder überzähligen Datensätze zu finden und zu bereinigen.
Das ist manchmal gar nicht so einfach. Wie willst Du folgende Situation
entscheiden: Ein Detaildatensatz hat einen Verweis auf einen nicht
existenten Masterdatensatz. Jetzt könnte bei der Erfassung der Daten ein
Fehler aufgetreten sein und es wurde einfach nur die falsche Referenz
erfasst - aber welche ist die richtige? Oder aber es gibt den
"richtigen" Masterdatensatz noch gar nicht. Dann müsste dieser erst
angelegt werden.
Diese Frage wird Dir nur der User zum Zeitpunkt der Datenerfassung
beantworten können. Wenn Du in zwei Wochen kommst und fragst: "Du hast
da vor zwei Wochen eine Rechnungsposition erfasst - aber die Rechnung
gibt es gar nicht. Was sollen wir damit machen?" dann wirst Du
wahrscheinlich als Antwort bekommen, dass sich der Verkäufer bei ca.
2.000 in der Vorweihnachtszeit verkauften Artikeln an dieses Detail nun
sicher nicht erinnern kann.
> Bei den Schnittstellen geht's ja nicht um eigene Daten, sondern die
> Daten kommen meistens von anderen. Da kannst Du Dir aber lange
> Gedanken darüber machen, auf was für Probleme du da treffen kannst.
> Die RI ist nie ein Freund, die ist immer nur ein Nörgler der
> Fehlermeldungen produziert. Was auch immer der User versteht oder
> nicht, eine Fehlermeldung ist für ihn eine Fehlermeldung und
> Fehlermeldungen sagen, dass der Entwickler seine Software nicht im
> Griff hat.
Den User, der sich über eine Fehlermeldung ärgert, den verstehe ich. Es
ist nun mal die Aufgabe des Datenbankprogrammierers dafür zu sorgen,
dass keine Fehler auftreten können. ;-)
Den User, der sich über fehlerhafte Auswertungen auf Grund
inkonsistenter Daten ärgert, den verstehe ich aber noch viel mehr. Der
beschwert sich zurecht bei Dir. Es wäre Deine Aufgabe gewesen, dafür zu
sorgen, dass nur "gültige" Daten in die Datenbank übernommen werden.
Wenn Du Daten zu importiere hast, dann hast Du es doch am Ende gar nicht
zu schwer. Du musst einmal die Datentabellen analysieren und die
bestehenden Abhängigkeiten ermitteln. Danach sorgst Du dafür, dass die
Tabellen in der richtigen Reihenfolge eingelesen werden. Wenn Du das
sauber gemacht hast dann kann Dich die RI gut unterstützen. Sie meldet
nämlich nur noch Fehler, wenn welche vorhanden sind.
> Meistens würde es der Anwender gar nicht merken, das ein MasterDS
> fehlt, wenn der verwendete Fremdschlüssel im Kontext steht. Der AW
> tipp zB. einfach eine Titel-Nr ein und ohne zu merken, dass der DS
> des Titels noch nicht existierte, kommt er zu den Detaildatensätzen.
Das ist doch aber kein erstrebenswerter Zustand - oder? Ich würde
erwarten, dass die Referenz auf den MasterDS aus einem Kombinationsfeld
auszuwählen ist. Dann kann so etwas gar nicht passieren. Und mit der
Lösung aus der FAQ 4.13 (www.donkarl.com) Variante 2 wird das für den
User eine übersichtliche Sache.
Wenn das mit dem Kombinationsfeld nicht geht, dann müsstest Du selber
vor dem Speichern ermitteln, ob der gewählte MasterDS vorhanden ist. Ich
denke, beide Wege sind so aufwendig nicht - sie stellen aber auf jeden
Fall eine konsistente Datenbasis sicher.
> Ich kann nach wie vor nicht verstehen, wie man im Sinne RI Datenmüll
> erfassen könnte. Das Wort Datenmüll ist mehr was für die
> Alchemistenküche der Systemadministratoren. Man kommt doch eh nicht
> ohne Datensicherungen aus falls mal was kaputt geht. Die RI nimmt
> einem dabei kein Stück Arbeit ab, die löst höchstens eine
> Fehlermeldung aus.
Ob man es nun plakativ "Datenmüll" nennt oder ob wir von inkonsistenten
Daten sprechen - letztlich ändert sich an der Sache nichts. Die
vorliegenden Daten sind so nur eingeschränkt zu verwenden!
> Ich implementiere keine Mechanismen um RI beim Erfassen zu
> gewährleisten, das ergibt sich von alleine. Meist durch die Abfragen
> der Formulare. Da würde es einen Fehler geben, wenn der Mastersatz
> fehlen würde, also vergesse ich mein me.refresh nie und das ist auch
> schon alles.
Diese Aussage verstehe ich nun gar nicht. Oben schreibst Du, dass User
Fehlermeldungen hassen. An dieser Stelle setz Du aber gezielt darauf,
dass Access den User mit einer Fehlermeldung belästigt. Ich finde, Du
solltest Dich entscheiden. Wenn schon eine schlechte Datenqualität dann
aber bitte ohne Fehlermeldung für den User. ;-)
> Die Aktualisierungsweitergabe ist vielleicht noch nützlich, auf die
> Löschweitergabe kann ich gut verzichten. Beim Löschen behalte ich doch
> lieber selber die Kontrolle über das was da gelöscht wird. Aber
> bitte, diese Funktionen könnten vielleicht noch ein Pluspunkt der RI
> sein.
Ich persönlich habe die Löschweitergabe bisher nur einmal verwendet.
Hier stimme ich Dir zu: Beim Löschen von Daten habe ich auch gern die
Kontrolle, was da genau passiert.
>> Ich bleibe bei meinem Statement:
>> RI ist kein "Kann" sondern ein "Muss".
>
> Dieser Beobachtung schließ ich mich an!
> Wenn man mit RI arbeitet gibt's kein "Kann" mehr, sondern nur noch
> "Muss".
Ich ergänze mein Fazit:
RI ist kein "Kann" sondern ein "Muss".
RI ist keine Frage des Stils sondern der Effektivität.
RI ist keine Frage!
CU
--
Thomas
Homepage: www.Team-Moeller.de
Ich wünsche allen frohe und besinnliche Weihnachtsfeiertage
Thomas Möller
Oliver Straub <oliver.s...@web.de> schrieb:
> Ich gebe gern zu, dass ich erst vor einigen Tagen drauf gestoßen bin,
> dass man in einem Programm von mir Datenmüll im Sinne von
> Detailsätzen ohne Mastersatz, produzieren könnte.
Glaube mir: wenn es technisch möglich ist, dann wird es auch User
gegeben haben, die von dieser "Möglichkeit" Gebrauch gemacht haben. ;-)
Eine Abfrage zur Inkonsistenzsuche schafft da schnell Klarheit.
> Eigentlich sollen
> die User nur mit von mir eingebauten Funktionen arbeiten, drum blende
> ich auch alle Toolbars aus. Einige User haben sich aber schon an den
> Toolbar "Formular" gewöhnt und benutzen ihn gerne. Was ich nicht
> bedacht hatte war, dass man über den Toolbar auch Mastersätze löschen
> kann, ohne dass das auf die Detailsätze übertragen wird. Naja, jetzt
> hab ich in dem Formular den Beim Löschen Event aktiviert und nun ist
> die Sache wieder konsistent.
Die User haben in meinen Anwendungen nur Zugriff auf die Funktionen, die
sie haben sollen.
Du könntest auf Deinem Formular einen Löschen-Button einfügen. Dahinter
könntest Du die gesamte Logik, die Du für konsistentes Löschen
benötigst, verpacken. Jetzt änderst Du noch die Eigenschaft "Löschen
zulassen" auf "Nein". So kann ein DS (über das FrontEnd) nur noch
gelöscht werden, wenn er durch Deine Routine gelöscht wird.
> Was ist denn, wenn ich RI und die Löschweitergabe aktiviert habe und
> ein schlauer User denkt sich er müsste schnell mal ein paar DS direkt
> in einer Tabelle löschen.
User haben in den Tabellen nichts zu suchen. Wenn Du beim Start der
Anwendung ein Formular lädst, die Access-Spezialtasten deaktivierst und
die Funktion der Shift-Taste abschaltest hast Du für die meisten User
schon Hindernisse geschaffen, die gross genug sind.
> Da kommt dann die Frage wegen der
> Löschweitergabe und da klickt er schnell auf OK und schwups sind
> einige 100 bis mehrere 1000 Detailsätze verschwunden. Ich habe mehr
> Angst um meine Detailsätze als um die Mastersätze. Das Verhältnis
> steht doch da meisten > 1:100. Ich halte es nicht für die richtige
> Betrachtungsweise, dass 1 DS mehr wert seien soll als 100 DS.
Ich denke, in diesem Punkt sind wir uns einige. Löschweitergabe sollte
man nur verwenden, wenn man sehr genau weiss was man da tut. Aus den von
Dir genannten Gründen verwende ich diese in meinen Projekten nicht.
> Eine der direkten Folgen der RI in meinen alten Programmen war, dass
> wegen fehlender Mastersätze viele hundert DS manuell erfasst werden
> mussten. Das möchte ich meinen Usern nicht mehr zumuten.
Dieses Thema hatten wir schon. Du musst den Import so organisieren, dass
erst die MasterDS importiert werden und erst dann die abhängigen
Tabellen. Die RI sorgt dann dafür, dass nur DS mit tatsächlich fehlendem
Master nicht importiert werden können. Bei allen anderen DS kannst Du
sicher sein, dass diese konsistent sind.
CU
--
Thomas
Homepage: www.Team-Moeller.de
Ich wünsche allen frohe und
besinnliche Weihnachtsfeiertage
Oliver Straub
> Genau darum geht es. Die Fähigkeit der RI ist es zu verhindern, dass
> inkonsistente Datensätze entstehen. Wenn mir Access dafür einen einfach zu
> nutzenden Mechanismus anbietet, dann sehe ich keinen Grund darauf zu
> verzichten. Ich könnte nur verlieren.
Der einzige Mechanismus den Access im Rahmen der RI anbietet ist, dass
zusätzlich ein Fehler ausgegeben wird, falls die RI verletzt wird.
> Entweder verliere ich viel Zeit, weil ich selbst durch meine
> Programmierung die Konsistenz der Daten erzwingen muss oder ich verliere
> meine Datenqualität.
Nur weil da ein Fehler ausgelöst wurde ist die Arbeit des Programmierers
damit nicht beendet, sondern das muss man ebenso ausprogrammieren, wie wenn
man ohne diese zusätzliche Fehlermeldung auskommt.
> Dann darf ich später viel Zeit dafür aufwenden, die fehlenden oder
> überzähligen Datensätze zu finden und zu bereinigen.
> Das ist manchmal gar nicht so einfach. Wie willst Du folgende Situation
> entscheiden: Ein Detaildatensatz hat einen Verweis auf einen nicht
> existenten Masterdatensatz. Jetzt könnte bei der Erfassung der Daten ein
> Fehler aufgetreten sein und es wurde einfach nur die falsche Referenz
> erfasst - aber welche ist die richtige? Oder aber es gibt den "richtigen"
> Masterdatensatz noch gar nicht. Dann müsste dieser erst angelegt werden.
Es ist mir ziemlich unverständlich wie man auf die Idee kommen kann,
Autowerte als Fremdschlüssel zu verwenden. Alle meine Fremdschlüssel haben
selbstverständlich einen klaren Kontext zu ihrem jeweiligen DS. Wenn ich
einen Detailsatz sehe, weiß ich automatisch wo er dazu gehört. Mir kann
keiner erzählen, dass es irgendeine Rechtfertigung dafür gibt, im Bereich
kaufmännischer Unternehmenssoftware, mit Autowerten als Fremdschlüssel zu
arbeiten. Alles ist immer einer klaren Kombination von Identifikatoren zu
zuordnen. Projekt-Nr., Angebots-Nr, Rechnungs-Nr., Bestell-Nr.,
Nachtrags-Nr., Personal-Nr., Kostenstellen, Kostenarten, etc, etc, etc.....
> Diese Frage wird Dir nur der User zum Zeitpunkt der Datenerfassung
> beantworten können. Wenn Du in zwei Wochen kommst und fragst: "Du hast da
> vor zwei Wochen eine Rechnungsposition erfasst - aber die Rechnung gibt es
> gar nicht. Was sollen wir damit machen?" dann wirst Du wahrscheinlich als
> Antwort bekommen, dass sich der Verkäufer bei ca. 2.000 in der
> Vorweihnachtszeit verkauften Artikeln an dieses Detail nun sicher nicht
> erinnern kann.
Damit outest Du Dich doch als jemand der von der praktischen Seite her kaum
über Erfahrung verfügt. Das ist doch wohl eine Konstellation die es in der
Realität niemals gibt. Was hat das den mit der Vorweihnachtszeit zu tun?
Denkst Du etwa an den Einzelhandel? Denkst Du da an einen Verkäufer der an
der Kasse steht?
> Den User, der sich über eine Fehlermeldung ärgert, den verstehe ich. Es
> ist nun mal die Aufgabe des Datenbankprogrammierers dafür zu sorgen, dass
> keine Fehler auftreten können. ;-)
> Den User, der sich über fehlerhafte Auswertungen auf Grund inkonsistenter
> Daten ärgert, den verstehe ich aber noch viel mehr. Der beschwert sich
> zurecht bei Dir. Es wäre Deine Aufgabe gewesen, dafür zu sorgen, dass nur
> "gültige" Daten in die Datenbank übernommen werden.
Nur nochmal zu Deiner Information: Wir reden nicht über referenzielle
Integrität, sondern über die im Rahmen der RI eingebaute Funktionalität von
MS Access. Der User will unbehelligt mit seiner Software arbeiten können,
ohne Fehlermeldungen und ohne fehlerhafte Daten. Diese Grundvorraussetzung
sollten wir innerhalb eines Expertengesprächs als selbstverständlich
ansehen.
> Diese Aussage verstehe ich nun gar nicht. Oben schreibst Du, dass User
> Fehlermeldungen hassen. An dieser Stelle setz Du aber gezielt darauf, dass
> Access den User mit einer Fehlermeldung belästigt. Ich finde, Du solltest
> Dich entscheiden. Wenn schon eine schlechte Datenqualität dann aber bitte
> ohne Fehlermeldung für den User. ;-)
Da Detaildatensätze meistens in eigenen Fenstern eingegeben werden,
benötigen diese Fenster auch Abfragen als Datenherkunft. Wenn ich innerhalb
einer solchen Abfrage ein Left Join zum Master-DS verwende (weil ich den
auch brauche), dann würde auch so ein Fehler ausgelöst werden, wenn die RI
verletzt werden würde, ebenso, wie es bei einer gesetzten Beziehung der Fall
wäre. Das ist es ja worüber wir reden: Muss ich eine Beziehung setzen damit
ich eine Fehlermeldung bekommen, oder brauch ich das nicht. Zu Deiner
weiteren Information: Der Fehler würde nur auftreten, wenn der Master-DS in
seinem Erfassungsfenster angelegt, aber noch nicht abgespeichert worden
wäre..-> drum würde da offensichtlich ein me.refresh fehlen, bevor das
Fenster für die Detailsätze geöffnet werden kann. Dieser Fehler würde einmal
beim ersten Testen auftreten, dann würde man darauf reagieren und der User
bekommt diesen Fehler nie zu Gesicht.
Falls Du mir auch nur eine vernünftige Möglichkeit nennen kannst, wie ein
User in der Lage seien sollte, einen Detailsatz ohne passenden
Fremdschlüssel zu erfassen, dann würdest Du mich damit ziemlich überraschen.
Fremdschlüssel werden niemals erfasst, sondern die kommen immer aus der
Fremde, wie es der Name schon Nahe legt.
Gruss
Oliver
Mark Doerbandt
Oliver Straub:
> Nur weil da ein Fehler ausgelöst wurde ist die Arbeit des Programmierers
> damit nicht beendet, sondern das muss man ebenso ausprogrammieren, wie wenn
> man ohne diese zusätzliche Fehlermeldung auskommt.
Du darfst nicht davon ausgehen, dass es nur einen Programmierer gibt.
Mit RI hat der DB-/Designer/ die Moeglichkeit, zu verhindern, dass ein
anderer (dummer, meist nachlaessiger oder auch mal boeswilliger)
Programmierer oder auch ein Anwender, der mal in die
anforderungsgemaess ungeschuetzten Tabellen schaut, unzulaessige
Datensaetze erzeugt. Das ist eine ganz andere Qualitaet der
"Sicherheit". Das bedauerliche Fehlen von Triggern mal aussen vor.
Gruss - Mark
--
Informationen fuer Neulinge in den Access-Newsgroups unter
http://www.doerbandt.de/Access/Newbie.htm
Bitte keine eMails auf Newsgroup-Beiträge senden.
Oliver Straub
> Dieses Thema hatten wir schon. Du musst den Import so organisieren, dass
> erst die MasterDS importiert werden und erst dann die abhängigen Tabellen.
> Die RI sorgt dann dafür, dass nur DS mit tatsächlich fehlendem Master
> nicht importiert werden können. Bei allen anderen DS kannst Du sicher
> sein, dass diese konsistent sind.
Um es mal auszusprechen, ich berichtete da über die Probleme die im Rahmen
des GAEB-Datenaustausches auftreten. Das Problem dabei ist, das sich die
Ersteller solcher Austauchdateien nicht an die refernzielle Integrität
halten. Die liefern da ggf. Detailsätze ohne zugehörigen MasterDS. Das
GAEB-Format gehört zur Baubranche und in dieser lautet die Devise der
Auftraggeber "Friss oder stirb", dass sage ich Dir, damit Du nicht auf die
Idee kommst es wäre ein Lösung zu sagen: Die Datei ist falsch und kann nicht
eingelesen werden, beschweren sie sich bei dem Ersteller.
(Zur kurz Info: Ich arbeite ja wie berichtet nicht mehr mit Beziehungen,
folglich müssen diese Probleme, über die ich berichtete, auch schon in der
Vergangenheit liegen, also sind sie alle schon längst gelöst, und JA
natürlich, ich löse jedes Problem, sobald es mir bekannt wird.
> Die User haben in meinen Anwendungen nur Zugriff auf die Funktionen, die
> sie haben sollen.
> Du könntest auf Deinem Formular einen Löschen-Button einfügen. Dahinter
> könntest Du die gesamte Logik, die Du für konsistentes Löschen benötigst,
> verpacken.
Es ist ja klar, dass ein solcher Button auf dem Formular vorhanden ist, von
dem ich sprach.
>Jetzt änderst Du noch die Eigenschaft "Löschen zulassen" auf "Nein"... ...
>, die Access-Spezialtasten deaktivierst und die Funktion der Shift-Taste
>abschaltest...
Keine anderen Tipps als diese hätte ich von Dir erwartet, mein lieber Jens.
;-)
Aber mal ehrlich, ich habe also in meinem Formular, dass den Master-DS
beherbergt, im Beim Löschen Ereignis hinterlegt, dass die Löschabfragen auf
die zugehörigen Detailsätze ausgeführt werden. Denkst Du ich bau das jetzt
wieder aus und verbiete statt dessen das Löschen? Einen solchen Rückschritt
kannst Du mir nicht zumuten.
Wenn jemand von mir ein Programm kauft, dann darf der damit machen was er
will (im Rahmen!). Es würde mir schon die Höfflichkeit verbieten ihn bei
seinen Zugriffen auf das Datenbankfenster zu reglementieren. Ich will ja
Kunden haben, die zufrieden sind. Und ich will diese Kunden unterstützen
können, ohne das ich dafür erst durch die Lande fliege muss. Dafür muss man
Probleme auch telefonisch lösen können, und dafür muss ein problemloser
Zugriff auf das Datenbankfenster gewährleistet sein. (Ich habe aber bei
meinen Standardfunktionen auch eine Funktion UserMod, die alles abschaltet
was man abschalten kann. Das hat sich in der Praxis nicht bewährt, drum wird
die höchst selten benutzt.)
Fazit 1: Der Einsatz von Beziehungen ist kein "Muss" sondern ein "Kann"
immer dann wenn man es brauche kann. Besser ist es aber, wenn man in der
Lage ist, ohne Einschränkungen auszukommen. (Bei gleichen Ergebnissen)
Fazit 2: Frohe Weihnachten und immer die die Ohren steif halten.
Gruss
Oliver
Jens Schilling
> Keine anderen Tipps als diese hätte ich von Dir erwartet, mein lieber
> Jens. ;-)
Weder ich - noch einer meiner Namensvetter - trauten sich bisher, sich zu
Deinen ausführlichen Darstellungen zu äussern ;-)
Ich persönlich bin eh kein Freund dieser endlosen Grundsatzdiskussionen -
und halte mich daher auch weiterhin zurück.
Gruss
Jens
Peter Doering
Oliver Straub wrote:
> Hallo Thomas,
>
>> Genau darum geht es. Die Fähigkeit der RI ist es zu verhindern, dass
>> inkonsistente Datensätze entstehen. Wenn mir Access dafür einen einfach zu
>> nutzenden Mechanismus anbietet, dann sehe ich keinen Grund darauf zu
>> verzichten. Ich könnte nur verlieren.
>
> Der einzige Mechanismus den Access im Rahmen der RI anbietet ist, dass
> zusätzlich ein Fehler ausgegeben wird, falls die RI verletzt wird.
Nee, wenn Loeschweitergabe nicht angeklickt ist, wird verhindert, dass der
Master-DS geloescht werden kann. Ansonsten Rueckfrage und Loeschung von
Master- und Detaildaten, oder weder noch.
>> Entweder verliere ich viel Zeit, weil ich selbst durch meine
>> Programmierung die Konsistenz der Daten erzwingen muss oder ich verliere
>> meine Datenqualität.
>
> Nur weil da ein Fehler ausgelöst wurde ist die Arbeit des Programmierers
> damit nicht beendet, sondern das muss man ebenso ausprogrammieren, wie wenn
> man ohne diese zusätzliche Fehlermeldung auskommt.
Jo. Allerdings wird das wesentliche Erfordernis, RI zu garantieren,
erfuellt.
> Es ist mir ziemlich unverständlich wie man auf die Idee kommen kann,
> Autowerte als Fremdschlüssel zu verwenden. Alle meine Fremdschlüssel haben
> selbstverständlich einen klaren Kontext zu ihrem jeweiligen DS. Wenn ich
> einen Detailsatz sehe, weiß ich automatisch wo er dazu gehört.
Woran erkennst du das? Beispiel?
Thomas Möller
Oliver Straub <oliver.s...@web.de> schrieb:
> Der einzige Mechanismus den Access im Rahmen der RI anbietet ist, dass
> zusätzlich ein Fehler ausgegeben wird, falls die RI verletzt wird.
Nein, es wird zusätzlich verhindert, dass die inkonsistenten Datensätze
gespeichert werden können - und darauf kommt es schliesslich an.
> Es ist mir ziemlich unverständlich wie man auf die Idee kommen kann,
> Autowerte als Fremdschlüssel zu verwenden. Alle meine Fremdschlüssel
> haben selbstverständlich einen klaren Kontext zu ihrem jeweiligen DS.
> Wenn ich einen Detailsatz sehe, weiß ich automatisch wo er dazu
> gehört. Mir kann keiner erzählen, dass es irgendeine Rechtfertigung
> dafür gibt, im Bereich kaufmännischer Unternehmenssoftware, mit
> Autowerten als Fremdschlüssel zu arbeiten. Alles ist immer einer
> klaren Kombination von Identifikatoren zu zuordnen. Projekt-Nr.,
> Angebots-Nr, Rechnungs-Nr., Bestell-Nr., Nachtrags-Nr., Personal-Nr.,
> Kostenstellen, Kostenarten, etc, etc, etc.....
Ich würde Deine Behauptung nicht in dieser Absolutheit unterstreichen,
aber rein prinzipiell sind wir uns da einig. Darum ging es aber in
meinem Beispiel nicht.
Mit geht es darum: Wie kannst Du unterscheiden, ob es sich um einen
Tippfehler (z.B. zu einer bestehenden KundenID) handelt oder ob es
dieser Referenz (z.B. KundenID) um einen Datensatz handelt?
> Nur nochmal zu Deiner Information: Wir reden nicht über referenzielle
> Integrität, sondern über die im Rahmen der RI eingebaute
> Funktionalität von MS Access. Der User will unbehelligt mit seiner
> Software arbeiten können, ohne Fehlermeldungen und ohne fehlerhafte
> Daten. Diese Grundvorraussetzung sollten wir innerhalb eines
> Expertengesprächs als selbstverständlich ansehen.
Darüber sind wir und (mittlerweile?) einig. Dazu gehört für mich aber
auch, dass ich nur DS zulasse, die die Datenintegrität nicht gefährden.
Aus diesem Grund gibt es schon den einen oder anderen Dialog, der den
User dazu auffordert, die noch fehlenden Informationen zu erfassen.
> Da Detaildatensätze meistens in eigenen Fenstern eingegeben werden,
> benötigen diese Fenster auch Abfragen als Datenherkunft. Wenn ich
> innerhalb einer solchen Abfrage ein Left Join zum Master-DS verwende
> (weil ich den auch brauche), dann würde auch so ein Fehler ausgelöst
> werden, wenn die RI verletzt werden würde, ebenso, wie es bei einer
> gesetzten Beziehung der Fall wäre. Das ist es ja worüber wir reden:
> Muss ich eine Beziehung setzen damit ich eine Fehlermeldung bekommen,
> oder brauch ich das nicht.
Sobald ein weiterer Programmierer zum Team dazustösst, steigt das
Fehlerpotential. Und wenn Du einen direkten Import auf Tabellenebene
durchführst auch. Ich denke da z.B. an den (programmgesteuerten) Import
von Daten aus einer Excel-Tabelle. Hier wirst Du oder ein weiterer
Programmierer von der RI unterstützt. So kannst Du die notwendigen
Prüfroutinen nicht vergessen.
> Falls Du mir auch nur eine vernünftige Möglichkeit nennen kannst, wie
> ein User in der Lage seien sollte, einen Detailsatz ohne passenden
> Fremdschlüssel zu erfassen, dann würdest Du mich damit ziemlich
> überraschen. Fremdschlüssel werden niemals erfasst, sondern die
> kommen immer aus der Fremde, wie es der Name schon Nahe legt.
Ja: Tabelle öffnen und Daten erfassen. ;-)
IMHO dient die RI dazu, die Integrität der Daten in jeder Situation
sicherzustellen. Unabhängig auf welchem Weg die Daten in die Tabellen
gelangen.
Die Aufgabe des Programmierers ist es, die in den verschiedenen
Situationen auftretenden Fehlermeldungen durch eigene, geeignete
Prüfroutinen abzufangen und den User zu Konkretisierung oder Korrektur
seiner Eingabe aufzufordern.
Ich habe bei den Eindruck, dass Du zwar schon die von Dir erkannten
Problemstellen ausprogrammieren willst. Warum Du allerdings auf die RI
verzichten willst und damit riskierst, dass am Ende doch inkonsistente
Daten in Deine Anwendung gelangen verstehe ich nicht.