Office: (Office 2003) Datensätze unter neuem Datum in gleicher Tabelle ablegen

Also war keine Absicht das ich das nicht eindeutig erklärt habe!

Aber ich frag mich gerade wie da nen schuh draus wird und alle aussagen passen?

Gibt es denn nicht einfach eine Möglichkeit einen Datensatz(e) aufgrund ein oder mehrer Kriterien auszuwählen und zukopieren und danach wieder in die Tabelle abzulegen!

Erklärung: z.B. drei Störungen mit dazugehörigen Ausgeführten Arbeiten vom 13.10.09 die noch nicht behoben sind sollen in der Tabelle mit dem Datum 14.10.09 neu abgelegt werden, so dass das Datum im Kombifeld erscheint( das krieg ich hin) und der Arbeiter den 14.10.09 auswählt und diese Störungen angezeigt werden ( von mir aus auch mit leerem " Ausgeführte Arbeiten"-Feld)!So das der Arbeiter neu einträge machen kann im "Ausgeführte Arbeiten"-Feld. Und das Alles möglichst durch einen KLICK!

Ich weiss vielleicht haltet ihr es wieder für Unsinn , allerdings versuch ich die Datenbank auf die Wünsche der Arbeiter zu "bauen". Die Datenbank soll sich den Arbeitern möglichst anpassen und nicht anders rum. Versteht Ihr! Hätte nicht gedacht das es so schwer ist ein oder mehrere DS einer Tabelle zu duplizieren wobei das Datum um ein Tag "wächst"! *upps ...puuuhhhh....
Ich brauche Eure Hilfeund Danke euch auch für die schon gesendeten Beiträge!

Falls ihr noch mehr Infos braucht geb ich sie euch gern.

Danke,*grins Christian!


Und nochmal auch wenns sich komisch anhört: Die Störungen haben keine Deadline! Natürlich werden sie schnellstmöglich behoben aber es gibt keine festgelegten Daten! Die Störung soll so schnell behoben werden, so schnell sie halt behoben werden können!

 

Wie Du Datensätze duplizieren kannst hat Dir Atrus in Post #2 gezeigt.

Wenn das Dich und die Arbeiter glücklich macht, bitte verwende es.
Es kann und wird Dir hier keiner vorschreiben wollen wie Du was anlegst.

Wir geben i.d.R. gut gemeinte Ratschläge die aus mehr oder weniger Erfahrung im Bereich Datenbanken resultieren.

Was der "Arbeiter" bedient ist die Oberfläche.
Die hat nichts, und absolut gar nichts, mit dem Datenmodell zu tun.

Diese muss natürlich absolut userfreundlich und angepasst sein.
Und am liebsten hätten manche User immer noch Lochkarten, weil "Das haben wir schon immer so gemacht!".
Kenne ich zur Genüge und es gibt sicherlich Fälle in denen man sich diesem "beugen" muss.
Aber selbst dann sollte die Wirtschaftlichkeit nicht vernachlässigt werden und da sehe ich, wenn Du es denn wirklich so umsetzen willst/musst noch einiges auf Dich (und vmtl. uns) zukommen *wink.gif*

Kannst Du vleicht mal eine Tabelle hier posten, in der ein paar Beispielhafte Störungen auftauchen.
Dann versuche ich daraus ein kleines Modell zu erstellen, wie ich es mir vorstellen.

Evtl. wird es dann für Dich klarer und ich/wir können Dich doch noch von einem "guten" bzw. "besseren" Datenmodell wie dem angestrebten überzeugen *wink.gif*

 

Ihr habt ja recht! Und ich würd es gerne so machen wir ihr vorschlagt !
Allerdings hab ich erst vor ca. drei wochen mit access angefangen und schon den dicken Wälzer durch(zum teil).
Das ist alles ganz schön komplex und schwer zugreifen für einen nicht informatiker!*upps

Danke aufjedenfall allen die sich an diesem Thema beteiligt Haben!!!!!*grins

Setze wenn ich morgen auf arbeit bin euch die Tabelle zur verfügung und was ihr sonst noch braucht!

Wie muss ich dass denn machen!

wenn ich euch die datenbank schicken soll müsste ich die firmeninternen Daten rausnehmen wegen Betriebsgeheimnis. *rolleyes.gif*


Danke für dein Angebot CptChaos!*wink.gif*

Das mit den CODES versteh ich auch immer nicht so richtig ich hab zwar schon den CODE-Assistenten kennegelernt aber nur bei den Eigenschaften. Aber das könn wir ja klären wenns soweit ist *wink.gif*

Hab bis jetzt denk ich mal nur an der oberfläche gekratzt!

 

Also hier mal meine Tabelle mit nen paar Beispieldatensätzen + Formular als pdf wenn ihr es anders braucht dann sagt Bescheid!

Vielen Dank!

 

Christian,

du hast ein Feld der Tabelle "ausgeführte Arbeiten" genannt. Diese Mehrzahl ist doch schon ein Hinweis darauf, dass es mehrere Folgejobs zu einer Störung gibt. Bisher schreibst du diese Arbeiten hintereinander.

Das ist keine gute Idee. Alles, was "mehrfach" auftreten kann, sollte in Form von mehreren Zeilen abgelegt sein. Jede dieser Zeilen ist ein "Abhilfejob" zur Störung. Das kann eine Zeile sein für Kleinigkeiten, oder 50 Zeilen für größere Reparaturen.

Wie schon mehrfach erwähnt, hast du also mindestens mal zwei Tabellen: tblStörungen und tblBehebungstätigkeiten. Die stehen 1:n in Beziehung, da 1 Störung eben mehrere (1-x) Behebungstätigkeiten haben kann.

Und auch wenn die STörung immer asap behoben werden soll, finden doch die Behebungsarbeiten an je einem Tag (und Zeit) statt, haben je ein (oder mehrere?) Servicetechniker, die da tätig sind und haben vermutlich auch ein Resultat, z.B. "Störung behoben", "Störung besteht weiter". Erledigt ist die Störung erst dann, wenn die Tätigkeiten "in Summe" den Mangel beseitigt haben.

Und was grundsätzliches: Datenbanken sollen die Wirklichkeit abbilden. Die Arbeiter sehen aber nur einen Teil der Wirklichkeit, nämlich "ihren Job". Du in der Zentrale hast mehr im Blick, wovon die Arbeiter nichst wissen, z.B. ob es zur selben Anlage schon früher mal Defekte gegeben hat, die vielleicht in Summe andeuten, dass die Anlage generell morsch ist. Du solltest dir also nicht von Leuten, die nur Details sehen, den Datenbankafubau vorschreiben lassen. DB-Design ist (sorry) nichts für Laien und nichts für Leute, die nur ihren Schraubenschlüssel kennen. Kein Bauingenieur lässt sich vom Laien in die Statik reinreden; "da reicht eine Dachlatte", wo ein Balken hinmuss...

 

Hab nochmal 2 Formularansichten von 2 aufeinanderfolgenden Tagen im Anhang!*tongue.gif*

Das mit den 2 Tabellen hört sich gut an und ist auch ( jetzt) verständlich für mich!

Aber welche felder nehm ich in welche Tabelle , damit wie man in meinem Formular oben links sieht, der Arbeiter sich das Datum ( z.B. von heute) aussucht und die Störungen angezeigt werden ( offene und behobene)?

Und wie lös ich dann das Problem das am Ende eines Tages durch ein Knopfdruck die offenen Störungen in den nächsten Tag übernommen werden?

Aber trotzdem die Behebungstätigkeiten an den Störungen vom Vortag durch Auswahl des Vortages im Kombifeld angeschaut werden können?

Oh Gott!*boah Das hört sich bei euch immer alles so schlüssig an!

Hoffentlich krieg ich das hin! Der Weg ist steinig...*eek.gif*

 

Den zur Verfügung gestellten Screens ist Dein Kopf noch in Excel, nicht in Access *wink.gif*
Das müssen wir als erstes ändern.

Und letztmals: Es werden keine Störungen "übernommen" oder gar dupliziert!!!
Diese haben, wie von Atrus schön beschrieben, verschiedene Schritte die es gilt zu dokumentieren.
Der erste dieser Schritte ist die Störungsmeldung, der letzte die Störungsbehebung.
Dazwischen können n Schritte sein.

Ebenfalls nochmals (letztmalig) die Bitte/Aufforderung Dich von dem Thema Formulare (ich weiss, die sind schön bunt und schnell hat mein ein optisch ansprechendes Ergebnis, aber die Basis stimmt trotzdem nicht) vorerst zu "verabschieden".
Formulare sind das "Sahnehäubchen" auf die Daten.

Erstmal muss das Datenmodell stehen; danach gehts an die Formulare.

Ist wie beim Maschinenbau:
Erstmal muss ich wissen, wofür ich die Maschine brauche (das Ziel, die Anforderung)
Dann mach ich mir Gedanken welche Teile/Materialien ich benötige (die Modellierung und Planungsphase)
Anschliessend wird das ganze in einem Plan zusammengefasst (Planung bzw. beim Entwickler möglicherweise die Erstellung eines Angebots/Vorschlags)
Ist dieser Plan in Ordnung und (vorauss.) umsetzbar, geht es ans "Handwerk", also erstmal die nötigen Teile "zusammensuchen" und aneinander anpassen (das sind quasi die Tabellen die erstellt werden wollen)
Erst ganz zum Schluss wird alles zusammengebaut, lackiert, etc. (das sind dann die Formulare)

Hast Du Dir mal die Links in Atrus und meiner Sig angeschaut?
Wirklich notwendig für Dich sollte das Accesstutorial und relationale DBs sein.

Ich weiss noch nicht wie ich heute dazu komme, aber ich versuche Dir eine einfache Beispieldatenbank zur Erfassung und Dokumentation von Störungen zu erstellen.

 

Wie oft noch? *frown.gif* Das ist nicht sinnvoll!

Es gibt nichts zu übernehmen, weil alles offen ist und bleibt, was nicht erledigt ist. Und erledit ist, was du mit einem Erledigungsdatum (nicht Häkchen!) kennzeichnest.

 

Sorry das ich immer wieder damit anfangen bin irgendwie festgefahren, aber ihr wisst ja jetzt zumindest auf was ich hinaus will. Werds nicht mehr erwähnen!!! ( glaub ich*tongue.gif* )

Das wär super ! *grins

Werd mich derweil weiter einarbeiten!
Also ich hab ja schon die Übungen aus dem Buch durchgespielt, aber anscheinend häng ich im Bereich des Datenbankmodells und dem Aufbau (optimalen) einer Datenbank!

Also gibt es Sachen die ich mir eher anschauen sollte als andere?*rolleyes.gif*

 

Ok, Du bist zumindest nicht gänzlich "Beratungsresistent" *wink.gif*

1. Lektüre: relationale DBs in meiner Signatur (lesen)
2. Lektüre: relationale DBs in meiner Signatur (verstehen)
3. Lektüre: Kels: Relationale Datenbanken in Atrus´Sig (nochmal lesen)
4. Lektüre: Kels: Relationale Datenbanken in Atrus´Sig (wirklich verstehen)
5. Lektüre: Access-Tutorial in Atrus´Sig

Das Buch (welches?) lass erstmal liegen... ist vmtl. sehr Accessspezifisch.
Und wir sind erstmal beim Thema Datenbanken. Access ist dazu nur ein Mittel der Wahl.

 

Hi,

@christian:
hier mal ein Entwurf.

Schau dir die Tabellen an, die Beziehungen und versuche das nachzuvollziehen.

• tblAnlagen = Liste der Anlagen
• tblStörungen = Liste der Meldungen; jede verweist auf eine Anlage
• tblKategorien: Liste der Störungskategorien (Schwere der Störung, also Kernschmelze oder Ausfall der Kaffeemaschine?)
• tblEinsätze: Liste der einzelnen Einsätze, die zur Behebung der Störung gefahren wurden. Jeder Einsatz kann die Störung auf einen Endstatus setzen, d.h. "behoben" oder "offen". Dabei ist es durchaus möglich, dass ein Ticket "wiederauflebt" (Stichwort Brandwache o.ä.).
• tblTätigkeiten: was in den Einsätzen unternommen wurde, um die Störung zu beheben (Demo: Austausch oder Reparatur).

Die Abfrage zeigt dir, welche Störungen "derzeit" noch offen sind. Das sind alle Störungen, die

• noch gar keinen Behebunbgseinsatz haben
• oder bei denen der Maximale Behebngsstatus nicht auf erledigt lautet (in Arbeit, aber noch offen).

Die Abfrage kann bisher noch nicht mit Störungen umgehen, die mal erledigt waren und danach wieder auf offen gestellt wurden. Sie soll erstmal nur demonstrieren, wie man ohne ein Satzkopieren den aktuellen Status ermitteln kann.

Viel Spaß beim Durchgucken.

 

Ok! Danke euch beiden!

Werd mir erstmal eure Sig`s durchlesen und verstehen*wink.gif*
und danach deinen ( Atrus ) Entwurf anschauen!

A propro " Wie im Maschinenbau", bin Maschinenbaustudent im 5.Semester also vielleicht ( ich will) krieg ichs ja hin mit de DBs.*grins

Für heute hab ich erstmal genug zutun!
Meld mich dann morgen wieder, und stell dumme *tongue.gif* Fragen?

Danke für Eure Hilfe! Ohne euch wär ick aufgeschmissen!*wink.gif*

Gruss Christian!

 

Der Vergleich mit dem Maschinenbau war durchaus deshalb so gewählt *wink.gif*

Es ist immer einfacher, jemanden "vor der Tür" abzuholen als darauf zu warten dass er "ins Geschäft" kommt.

Sprich irgendwas nehmen das der Kunde (in dem Fall Du) kennt und versuchen dann die Brücke zu schlagen zum eigentlichen Thema.

Der Gedanke ist auch hilfreich bei der Erstellung von Datenbanken.

 

Also ich habe mir das DB-Skript gestern einmal und heute das zweite mal durchgelesen ( das in Atrus seiner Sig ist ja dasselbe *wink.gif* ) und zum gößten Teil verstanden. Versteh jetzt auch eure Einwände was mein Schrott-Datenbankmodell angeht!
Das Access-Tutorial hab ich angefangen und festgestellt das ich vieles ( nicht alles) schon kenne ( was nicht überheblich gemeint ist).
Ich denke Access muss man machen um es zu verstehen und da würd ich gern mit meiner neuen DB arbeiten.
Atrus dein Vorschlag hab ich mir auch angesehen und verstanden worum es geht, Danke nochmal!

Hab mir Gedanken über die Normalisierung gemacht ( mit Skizze*grins ) und hänge jetzt irgendwie.
Also als erste hab ich nachgedacht wo für die DB dienen soll: zum einen Störungsaufnahme+Behebung und zum anderen zusätzlich als Arbeitsnachweis der Arbeiter.

Dann hab ich notwendige Attribute erstellt:
Stoerung
StoerungsDatum
StoerungsUhrzeit
Maschine/Anlage
Gebäude
StoerungBeseitigtAmDatum
Abhilfejob
AbhilfejobDatum
AbhilfejobStartzeit
AbhilfejobEndzeit
Mitarbeiter1
Mitarbeiter2
Mitarbeiter3
Mitarbeiter4

Das problem was ich jetzt irgendwie habe ist: Öffter arbeiten z.B. 2 Mitarbeiter an einem Abhilfejob. Der eine 1 Std und der andere 2 Std!
Ist es jetzt besser für jeden Mitarbeiter eine eigene AbhilfeStart- und Endzeit zu deklarieren? Oder nehm ich die AbhilfeStartzeit und AbhilfeEndzeit raus und mach ne Beziehung zwischen MitarbeiterX und Abhilfejob? *upps

Hab schon versucht ne 2.NF zu erstellen (was wahrscheinlich hinfällig ist wenn ich nicht erst das erste problem gelöst habe):

tblStoerung = Stoerung,Anlage,Gebaeude,StoerungsDatum,StoerungsUhrzeit

tblAbhilfejob =Abhilfejob,AbhilfejobDatum,AbhilfejobStartzeit,AbhilfejobEndzeit,MA1,MA2,MA3,MA 4,

tblStoerungsStatus= Stoerung,Abhilfejob,StoerungBeseitigtAmDatum!!!


Könnt ihr ja mal überfliegen, ich weiss ist ganz schön viel!*rolleyes.gif*

 

Das sieht doch jetzt schonmal sehr gut aus! *five

Wie Du schon selbst festgestellt hast, passt das mit den MA noch nicht.
Als Gedanke: Was machst Du, wenn zukünftig irgendwann mal 5 statt 4 MA möglich sein sollen? Oder nur noch 2?
Dann müsste am Datenmodell geschraubt werden.

Also raus mit den MA aus der tblAbhilfeJob und rein in eine eigene Tabelle welche in Relation zur tblAbhilfeJob steht. -> tblAbhilfeMitarbeiter

Die enthält neben dem PrimaryKey aus tblAbhilfeJob noch den PrimaryKey aus einer (noch zu erstellenden ?) Mitarbeitertabelle sowie Informationen von wann bis wann der jeweilige Mitarbeiter daran gearbeitet hat.

Somit kannst Du später auch einfach auswerten das Müller am JobA 2 Stunden und Huber am JobA 3 Stunden gearbeitet hat.