Access-o-Mania

Hallo,

ich habe mir in einer Abfrage einen SQL Text für eine fortlaufende Nr. bezogen auf den Daten_ID einer Tabelle erzeugt.

lfdNr: (Select Count (*) FROM [Gesamtdatenerfassung_Handling_tab] as X WHERE [X].[DatenHandling_ID] < [Gesamtdatenerfassung_Handling_tab].[DatenHandling_ID])+1

In der Ansicht wird mir nun die fortlaufende Nr angezeigt. Soweit so gut. Kann man jetzt diesen Code umschreiben, dass er in der Ansicht so aussieht?
1/13
2/13
3/13  usw.

Fortlaufende Nr/Aktuelles Jahr

Ab dem Jahr 2014 soll die fortlaufende Nr wieder mit 1/14 beginnen usw

Hi

in der Abfrage als Deklaration für den Zähler:

Nr: Format((select count (*) from GesamtDatenerfassung_Handling_tab as x where x.datenhandling_id < gesamtdatenerfassung_handling_tab.datenhandling_id)+1;"00") & "/" & Rechts(Jahr(Datum());2)

Wobei ich das aktuelle Jahr anhand von date ermittle.

Harald

Hallo,

danke für die großartige Hilfe. Genau das habe ich benötigt. Habe es schon intergriert. Läuft einwandfrei.

Danke nochmals

gruß Ludwig

ZitatLäuft einwandfrei.

ZitatAb dem Jahr 2014 soll die fortlaufende Nr wieder mit 1/14 beginnen usw

Ob das mit diesem Code funktioniert, dürfte bezweifelt werden.  :-\

Hallo,

Hast du dann einen besseren Vorschlag parat? Ich kann mir in dieser Hinsicht nicht helfen.

Hi,

Fall 1:
egal welche Bedingung gesetzt, sollte es, sofern es wenigsten einen Datensatz gibt, die dafür ermittelte Anzahl bei EINS liegen. Die Anfangszahl sollte also unabhängig vom Jahr immer mit 1 anfangen.

Je nach Jahr wird dann eine 14 oder 15 oder ... angehängt.


Fall 2:
Wenn dabei "zu viele" Datensätze {... im Laufe der Jahre ...} herauskommen, ist hoffentlich ein Datumsfeld dabei, um Daten aus dem Vorjahr auszugrenzen: Im einfachsten Fall durch Vergleich von Year(Datumsfeld) = Year (Date()).


Fall 3:
Falls diese Nummerierung "nur" im Bericht benötigt wird, ist das dort mit weniger Aufwand möglich: ungebundenes Feld auf 1 setzen und Summe über Gruppe (z.B. Jahreszahl).


Harald

ZitatFortlaufende Nr/Aktuelles Jahr

Die erste Normalform (atomare Daten einzeln führen) macht nicht nur in der Datenmodellierung Sinn, sondern auch in funktionaler Hinsicht. Daher würde man zwei Felder führen: Die Jahreszahl sowie die laufende Nummer wie schon beherrscht, ergänzt um einen Vergleich auf die Jahreszahl.

In einem Abfragefeld kann man dann beide Felder verknüpfen und für weitere Auswertungen zur Verfügung stellen:
SELECT LfdNr & "/" & Jahresfeld
FROM Tabelle
ORDER BY LfdNr, Jahresfeld
Hiermit gelingt über die Einzelfelder ganz nebenbei eine vernünftige Sortierung, mit dem zusammengesetzten Feld gäbe es da erhebliche Probleme.

Hi Ludwig,

anbei im Anhang ein Beispiel, wie die Nummerierung beim Jahreswechsel bei 1 anfängt.

Es gibt dort zwei Abfragen.
In der zweiten mache ich auf ein Problem aufmerksam, wenn eine unpassende Sortierung verwendet wird:
Die Sortierung nach dem Eingabe_Datum erzeugt eine willkürliche Nummerierung, wenn die ID zum Zählen verwendet wird.
Konsequenz sollte sein, dass der where-Teil in der Unterabfrage der Sortierung angepasst werden muß.

Harald

Zitatunpassende Sortierung

... für eine Anzeige gibt es meiner Meinung nach nicht. Eine vorgenommene Sortierung richtet sich nach funktionalen Gesichtspunkten und nicht danach, wie Teile der Daten erzeugt wurden.
Wenn die ID's nicht zeitchronologisch erzeugt werden, aber für die Errechnung einer laufenden Nummer herangezogen werden, dann ist es eben so. Legt man Wert auf eine zeitchronologische laufende Nummerierung, würde man dann den Timestamp zur Ermittung heranziehen und nicht eine dann bedeutungslose ID.

Hi

Zitatunpassende Sortierung

mit "unpassend" hatte ich gemeint, dass eine Sortierung, die eine gewünschte Funktionalität aufweist, nicht zu dem zuvor aufgeführten Modell der Nummerierung passt, was dann halt angepasst werden muss.

Zitatdass der where-Teil in der Unterabfrage der Sortierung angepasst werden muß.

Das "unpassend" bezog sich nicht auf die ANZEIGE, sondern nur auf die Nummerierung.  ;D

Harald

Wenn man sich gleich klar ausdrückt, muss man nicht nachfolgend erklären, was man gemeint hat. Beim Programmieren macht sich das besonders schlecht.

Zitatgemeint, dass eine Sortierung, die eine gewünschte Funktionalität aufweist, nicht zu dem zuvor aufgeführten Modell der Nummerierung passt

Da bin ich anderer Meinung, und den Weg hatte ich bereits gezeigt: => Einzelfelder statt Textkonglomerat

Übrigens bekommt Deine Format-Variante Probleme, wenn der DB-User fleißig ist und mehr als 99 zählenswerte Vorgänge erzeugt.
Ob man das ursprünglich gewählte Nummerierungsmodell überhaupt abändern darf, müsste erst geklärt werden. Gerade bei betrieblich festeingefahrenen Abläufen dürfte hier eine Verhandlungsbereitschaft des Auftraggebers sehr eingeschränkt sein.

Hi,

ich habe nicht den Anspruch eine fertige Lösung zu präsentieren. Dafür habe ich weder die notwendige Informationen über die Abläufe noch die Zeit. Es ist schon schwer genug für sich selber eine fertige Lösung zu finden.  ;D

Mein alleiniges Ziel ist es, dem Fragesteller Hilfe zur Selbsthilfe zu geben, damit er über Anregungen, die er dann selber seinen Bedürfnissen anpassen kann, sein Ziel erreicht.


Harald

Hallo,

nur mal so am Rande habe jetzt bemerkt, dass mit dem SQL Code: DatlfdNr: Format((select count (*) from Gesamtdatenerfassung_tab as x where x.Gesamtdaten_ID < Gesamtdatenerfassung_tab.Gesamtdaten_ID)+1;"00") & "/" & Rechts(Jahr(Datum());2) keine Eingabe mehr funkioniert. Bei jeder Abfrage wo ich diesen Code angefügt habe, kann ich im Formular keine Datenänderung mehr machen.. Es sind alle Felder gesperrt. Erst wenn ich in der jeweiligen Abfrage der Datensatzherkunft diesen Code entferne, kann ich wieder Daten ändern.

gruß Ludwig

... und das passiert "plötzlich", oder hattest Du mit der Abfrage lt. Beitrag #1 nicht die gleiche Situation?

Generell sollte man zulassen, dass Eingabe und Anzeigen sehr verschiedene Vorgänge sein und daher auch über verschiedene Formulare bedient werden können. Es ist eben nicht mehr das Exceltabellenblatt, wo ich sehe, eingebe, speichere, rechne und wieder sehe.

Vielleicht könnte man auch darüber nachdenken, was (welches Ding) durch die gebildete laufende Nummer ausgezeichnet wird. Wenn man an einen Artikel oder einen Vorgang denkt, sollte doch eher eine feste Zuordnung erfolgen statt einer laufenden Berechnung, die dann auch schnell das gleiche Ding anders nummeriert, wenn Datensätze hinzukommen oder wegfallen.
Feste Zuordnung heißt Speicherung der Informationen in eine Tabelle, sinnvollerweise wie oben angemerkt die Einzelinformationen in getrennten Feldern. Dann müsste man die LNr nur jeweils für neu angelegte Datensätze ermitteln. Die Jahreszahl sollte kein Problem sein, und den Teil lfdNr bekommt man hin mit ...
neu_lfdNr = Nz(DMax("lfdNr", "TabelleX", "Jahresfeld = Year(Date())"), 0) + 1

Diese Tabellenfelder kann (sollte) man indizieren, was dann der Ausführungsgeschwindigkeit beim Filtern, Sortieren, Rechnen hilft.

Das Ganze ist auch keine fertige Lösung, sondern ein Vorschlag, der die gestellte Aufgabe löst und zusätzlich weitere Aufgaben zulässt, ohne das da etwas umgestellt werden muss:
- Vorgänge vierstellig?
- Vorgang 2 aus den Jahren 12, 13 und 14 gegenüberstellen
- höchste Nummer aus einem Jahr ermitteln uva.

Hallo Eberhard,

nach dem SQL Hinweis wie ich ihn im Eintrag #1 erhalten habe, habe ich diesen Code DatlfdNr: Format((select count (*) from Gesamtdatenerfassung_tab as x where x.Gesamtdaten_ID < Gesamtdatenerfassung_tab.Gesamtdaten_ID)+1;"00") & "/" & Rechts(Jahr(Datum());2) in meinen Abfragen zu den betreffenden Formularen angefügt.
In meinen Formularen hat die Anzeige der lfd.Nr/Jahr funktioniert. Zum Testen bin ich dann nicht mehr gekommen, erst heute morgen. Da ist mir aufgefallen, dass jedes Formular das sich von der Datensatzherkunft auf eines der Abfragen mit dem Code bezieht, nicht mehr betätigen lässt. Ich könnte keine Änderung an den Daten mehr ausführen. Weder am Formular, noch in der Abfrage. Jedes Feld war als hätte ich es gesperrt.
Erst als ich den Code in den Abfragen auf "nicht Anzeigen" setzte, bzw entfernte funktionierte alles wie gewohnt.

Nochmal zum Verständnis:
Ich bin auf eine lfd. Nr. mit Jahreszahl gekommen, da wir für defekte Ersatzteile die an eine Fremdfirma zur Reparatur versendet werden, einen Warenbegleitschein mit zum Versand legen müssen. Bis jetzt hatte ich dazu Excel und dafür die lfd Nr von Spalte A dafür verwendet.
Im Jahr kommen im Schnitt ca. 3800 Datensätze zusammen. Diese lfd Nr. (z.Bsp. 3525 wird dann per Formel im Warenbegleitschein erfasst. Anhand dieser Nr. wird dem erfassten Ersatzteil der betreffende Datensatz, wo Daten wie Name, Datum, Störart, usw. zugewiesen.)

In Access habe ich für den Warenbegleitschein einen Bericht erstellt der einwandfrei funktioniert und wo ich die betreffenden Daten erhalte. Bis jetzt hatte ich dazu die ID verwendet. Nun wollte ich genau dieses nicht über die ID zuweisen, sondern über eine lfd.Nr jedes Datensatzes mit / Jahreszahl. Zu Beginn eines neuen Jahres würde dann diese lfd. Nr wieder bei 1 beginnen aber mit der /aktuellen Jahreszahl. Die ID wäre dann schon bei über 3800 oder mehr.
Auf den defekten ERsatzteilen haben wir vom Hersteller Etiketten, wo genau diese lfd. Nr noch vermekrt wird. Somit könnte man, auf den ersten Blick schon sehen, in welchem Jahr dieses Teil, das ja nach erledigter Reparatur wieder zurück kommt schon mal versendet wurde.

Ludwig

Hallo,

wenn Berechnungen in einer Abfrage erfolgen (berechnete Spalten verwendet werden), dann ist eine solche Abfrage nicht mehr aktualisierbar, was sich (auch) an der "Sperrung" der Formularfelder äußert.
 

Insofern lass die Berechnungen in der Abfrage bleiben und berechne die lfdNr wie von Eberhard vorgeschlagen mit Hilfe einer VBA-Funktion.

Hallo,

ich habe nun den Code

DatlfdNr: Format((select count (*) from Gesamtdatenerfassung_tab as x where x.Gesamtdaten_ID < Gesamtdatenerfassung_tab.Gesamtdaten_ID)+1;"0000") & "/" & Rechts(Jahr(Datum());4)

in die Abfrage gelegt, die für den Bericht vorgesehen ist. Im Formular zur Dateneingabe für den anschl. Bericht wähle ich nun über ID aus und somit habe ich dann im Bericht die richtige DatlfdNr vorliegen.
Ich denke dass ich bis jetzt richtig liege. Auf jeden Fall ist es momentan genau so wie ich es gerne haben möchte.
Ob die DatlfdNr nun im Jahr 2014 neu angelegt wird mit 0001/2014 werde ich ja dann im neuen Jahr sehen :)

gruß Ludwig

Hallo,

das könnte auch gleich getestet werden, indem das Systemdatum temporär auf z. B.  den 1.1.2014  gesetzt wird.


Ich kann aber gleich sagen, dass das eher enttäuschend sein wird.  (Die "Laufende Nummer" schert sich nicht um den Jahreswechsel)



Zudem ist die LFdNr in keiner Weise irgendwie aussagekräftig. Wenn z.B. Datensätze gelöscht werden, bleibt zwar die Lfdnr an sich lückenlos fortlaufend, wird aber dadurch auch unterschiedlichen Datensätzen zugeordnet, so dass die einzige Wirkung in einer für den User vielleicht "angenehmen" Lesbarkeit des Berichtes liegt.


Weiterhin ist der Ausdruck:

... & Rechts(Jahr(Datum());4)

schlichtweg Unsinn.


Die String-Funktion (Rechts() auf einen numerischen Ausdruck (bzw. numerische Zahl) anzuwenden, kann ins Auge gehen.

... & Jahr(Datum())   allein liefert schon die numerische Jahreszahl, die an sich schon 4-stellig ist. Der "&"-Operator sorgt dann dafür, dass intern der numerische Wert beim Verketten in einen String konvertiert wird.

ZitatDie "Laufende Nummer" schert sich nicht um den Jahreswechsel

Nicht ganz: Durch die Art der Berechnung werden alle defekten Teile aller Jahre in das dann aktuelle Jahr übernommen. Der Auftragnehmer wird sich freuen über viel viel Arbeit.

Zitatwerde ich ja dann im neuen Jahr sehen

Irgendwas wirst Du sehen ...

Hallo,


mit "Laufender Nummer" meinte ich nicht "DatlfdNr", sondern den Wert, den Count(*) im dargelegten SQL-String der berechneten Abfrage-Spalte ermittelt und der beim Jahreswechsel wieder bei 1 beginnen soll.

Hallo,

Ich bin jetzt wirklich schon am überlegen, diese lfdNr die ich gerne im Bericht haben möchte, in meinem Formular zur Datenerfassung eines defekten Ersatzteiles manuell in einem Textfeld anzulegen. Da ich ja das Formular nun umgebaut habe, dass der letzte Eintrag im Datensatz immer oben angezeigt wird ist auch die zuletzt eingetragene lfdNr sofort ersichtlich. Diese würde ich dann im gerade eingegebenen Datensatz um 1 erhöhen. Somit ist dann diese Nummer auch ID wieder zugeordnet.

Gruß Ludwig

Hi,

Wenn Du die Nummern-Angabe zum Identifizieren benötigst, mußt Du eine von Eberhard vorgeschlagene Lösung (peace  ;D) verwenden, bei der die Nummer in der Tabelle gespeichert wird.

Im Anhang findest Du ein erstes Beispiel, das eine Orientierung geben kann, wie solch eine Nummer erstellt wird. Genutzt wird das Ereignis "Vor Aktualisierung" im Formular. Es wird ein Eingabe_Datum erfasst, um daraus das Jahr abzuleiten.

Vielleicht hilft das.

Harald

Nachtrag:
Unter Umständen ist ein Eingabe_Datum nicht optimal:
Wenn eine Eingabe am 02.01. gemacht wird, sie sich aber auf z.B. 30.12 des Vorjahres bezieht, sollte ein "Geschäftsjahr" oder "Reparaturjahr" als Basis verwendet werden

Hallo,

ich möchte mein Thema nochmal aufgreifen da ich eine Erweiterung vor habe.

Zu dem u.a. Code der einwandfrei funktioniert und mir zu jeder Gesamtdaten_ID eine lfd W_ScheinNr (Warenschein Nr) erzeugt in Form von xxx1/2014 usw. möchte ich nun noch ein weiteres Datum dazufügen.

Das Feld nennt sich Wartungsdatum.

Also gibt es zu jeder Gesamtdaten_ID entweder ein Stoerungsdatum oder ein Wartungsdatum. Beide Einträge auf eine ID wird es nicht geben.

W_ScheinNr: Format((Select Count (*) FROM [Gesamtdatenerfassung_tab] as X WHERE [X].[Gesamtdaten_ID] < [Gesamtdatenerfassung_tab].[Gesamtdaten_ID]
and year(

• .[Stoerungsdatum]) = year([Gesamtdatenerfassung_tab].[Stoerungsdatum]))+1;"0000") & "/" & Rechts(Jahr([Stoerungsdatum]);4)
  
  Kann mir jemand behiflich sein wie nun dieseer Code um das Wartungsdatum erweitert werden muss?
  
  

Der Kopf ist rund, damit das Denken die Richtung wechseln kann.

Du hast aber die wiederholt gegebenen Hinweise nicht verstanden und erst recht nicht umgesetzt, und das "funktioniert einwandfrei" hängt nur damit zusammen, dass Du bestenfalls in einem idealisierten Zustand "testest".
Noch einmal zur Verdeutlichung: Mit Deinem Codeteil wird die laufende Nummer jedes Mal über alle Datensätze neu berechnet.
Das heißt zum einen: Die Berechnung einer laufenden Nummer ist hier technisch bedingt aufwändig und kostet Zeit, bei einer entsprechenden Datenmenge dann auch spürbar (Laufzeit!).
Zum anderen: Wenn jetzt innerhalb der vorhandenen Datensätze ein Datensatz eingeschoben wird oder auch gelöscht wird (und Du glaubst nicht, was ein User so alles anstellen kann, wenn Du ihn nicht knebelst), verschieben sich wegen der ständigen Neuberechnung für die nachfolgenden Datensätze die Nummern.

ZitatNochmal zum Verständnis:
Ich bin auf eine lfd. Nr. mit Jahreszahl gekommen, da wir für defekte Ersatzteile die an eine Fremdfirma zur Reparatur versendet werden, einen Warenbegleitschein mit zum Versand legen müssen.
...
Anhand dieser Nr. wird dem erfassten Ersatzteil der betreffende Datensatz, wo Daten wie Name, Datum, Störart, usw. zugewiesen.)

Wie gut bist Du für den Fall gerüstet, dass sich in der EDV die Warenbegleitscheinnummern ändern, nicht aber auf dem Papier (was sicher auch bewegt wird), und für den Fall, dass eben die Zuordnung Ersatzteil und Person auseinanderfliegt?

Zu Deiner neuen Frage: Zur Technik will ich mich da nicht äußern, weil ich alleine durch den Inhalt schon Probleme habe. Eine Vorgangsnummer zu einem Ersatzteil würde ich im Moment der Erfassung vergeben, eine Lieferungsnummer (die mehrere Ersatzteile umfasst?) zum Zeitpunkt der Lieferung. Welche Rolle da ein Störungsdatum oder ein Wartungsdatum spielen sollen, wäre näher zu erklären.

Wenn womöglich in Deiner Sichtweise das Störungsdatum durch das Wartungsdatum ersetzt(?) wird, hättest Du ein geplantes und sicher funktionierendes Nummerndurcheinander.
Da würde ich abschließend fragen: Verdienst Du mit Deiner Tätigkeit Geld, und hast Du eine ausreichende, solche Fälle abdeckende Haftpflicht oder ein eigenes Vermögen?