Personalnummer vorschlagen

[ellinho]

Hallo zusammen.
Vielleicht ist es ja ganz einfach...
Ich habe ein Formular, über das ich Mitarbeiter(stammdaten) erfasse.
Ich möchte gerne, dass bei Aufruf des Formulars eine (freie!) Personalnummer vorgeschlagen wird. Habe mir nun eine Tabelle mit fortlaufenden Personalnummern erstellt (000001 bis 000099). Weiterhin habe ich mir eine Abfrage erstellt, die die nicht belegten Personalnummern aus dem besagten Nummernkreis ausgibt. Nun soll immer die kleinste, freie Personalnummer beim Aufruf des Erfassungsformulars vorgeschlagen werden. Das Textfeld ist jedoch mit dem Feld "Personalnummer" der Tabelle "Mitarbeiter" verknüpft. Was kann ich tun ?

Gruß
Karsten

[DF6GL]

Hallo,

überdenke zunächst das Konzept der Personalnummern:


Warum führende Nullen ?
Warum Tabelle mit vorbelegten fortlaufenden Nummern?
Sollen wirklich Lücken (das heißt vorher vorhandene und bei Gegebenheit gelöschte Nummern) wieder verwendet werden?


1) am Einfachsten erreicht man das durch Einbau eines inkrementellen Autowertfeldes, das gleichzeitig als Primärschlüssel dient. DAbei wird der nächst höhere Wert bei einer Neuerfassung eines Mitarbeiters automatisch vorgeschlagen (eher: benutzt).
2) Evtl. Lücken wieder zu füllen halte ich für ein riskantes Unterfangen, was aber bei einem Autowert eh nicht möglich ist.

[ellinho]

Hallo.
Führende Nullen nur, weil die Personalnummern seit jeher so aufgebaut sind.
Wiederverwendete Lücken sollten kein Problem sein. Es existieren Löschweitergaben an alle Tabellen, wenn ein Mitarbeiter ausscheidet und seine Stammdaten gelöscht werden.
Der Vorschlag mit dem inkrementellen Autowertfeld hört sich gut an, allerdings müsste ich, so wie ich das verstehe, alles umstricken bezüglich Primärschlüssel und Fremdschlüsselbeziehungen (Löschweitergaben. Einen Autowert besitzt die Tabelle Mitarbeiter bisher nicht. Die Personalnummer ist der Primärschlüssel. Habe ich nicht die Möglichkeit, den Vorschlag aus der bestehenden Abfrage zu bekommen ?

Gruß
Karsten

[MzKlMu]

Hallo,
ich würde für den Primärschlüssel die Personalnummer als Zahl verwenden. Führende Nullen kannman mit Format problemlos darstellen auch bei einer Zahl.
Ein Textfeld als PK ist ungeeignet, da ein Vergleich dann Zeichen für Zeichen der Personalnummer vergleichen muss, als Zahl geht das deutlich schneller.

wenn ein Mitarbeiter ausscheidet und seine Stammdaten gelöscht werden.

Auch das halte ich für falsch. Ausgeschiedene Mitarbeiter werden nicht gelöscht, sondern kriegen im einfachsten Fall einfach ein Datumsfeld "AusgeschiedenAm".

Im Anhang mal ein Beispiel, mit einer Zahl als Nummer und führenden Nullen. Die Zahl kannst Du auch als PK verwenden.

[Anhang gelöscht durch Administrator]

[DF6GL]

Hallo,


weitere Beispiele:

http://www.dbwiki.net/wiki/VBA_Tipp:_Freie_Nummern_belegen

[ellinho]

Hallo.
Habe versäumt zu erklären, dass ich mit einer adp (Access-Projekt) arbeite. Da funktionieren viele Dinge eben anders und auch die Beispiele von Franz leider nicht. Mit dem Autowert ist nichts, da mehrere Nummernkreise bestanden und man die Personalnummern (bzw. den Autowert) in ganz anderen Nummernkreisen starten lassen müsste. Das ist nicht gewünscht, denn so habe ich noch einen Nummernkreis mehr. Möchte jetzt gerne eine Ereignisprozedur für das gesperrte Textfeld "Personalnummer" schreiben, das bei Fokuserhalt den kleinsten Wert aus meiner Abfrage hineinschreibt. Die Abfrage bezieht sich auf die Tabelle Personalnummern mit Werten von 000001 bis 000100 und filtert die Nummern heraus, die bereits belegt sind. Hat jemand eine Idee, wie man die Prozedur aufbauen kann, so dass sie auch in einer adp funktioniert?

[DF6GL]

Hallo,


was soll da bei einem ADP nicht funktionieren, außer dass man ADODB-Zugriffsmethoden benutzen muss?


Erstelle eine weitere Abfrage "(abf_FreiePersnr"), die die freien Nummern liefert (statt not in kann auch Left Join-Verknüpfung benutzt werden):

Select PersNr from tblPersonalnummern where PersNr not in (select PersNr from abf_BelegtePersnr)  order by PersNr

dann als Ereignisprozedur:

Sub PersNr_Enter()
Me!PersNr = Dlookup("PersNr","abf_FreiePersnr")
End Sub

Ob die Verwendung des Enter-Ereignis entspr. Deiner Forderung nun zielführend ist, wage ich zu bezweifeln.

[ellinho]

Danke Franz.

Der DLookup hat mich auf den richtigen Weg gebracht.
Funktioniert prima.

Gruß
Karsten

[ellinho]

Hallo nochmal.
Hatte das Thema eigentlich schon auf "gelöst" gesetzt. Hatte es nur durch Aufruf des Formulars getestet. Da wird immer die richtige (nächste freie) Personalnummer vorgeschlagen. Allerdings bekomme ich bei Klick auf Datensatz hinzufügen bei der Erfassung eines Mitarbeiters den Fehler "Die Schlüsselspalteninformationen sind ungenügend oder inkorrekt. Es sind zu viele Zeilen von der Aktualisierung betroffen."...wobei der Datensatz allerdings trotzdem der tblMitarbeiter hinzugefügt wird. Bekomme ich nun doch noch ein Problem damit, dass die Personalnummer in der tblMitarbeiter der PK ist und die tbl keinen Autowert als PK besitzt? Ich kann den Fehler im Moment nicht deuten. Zur Vervollständigung der Infos muss ich sagen, dass an der tblMitarbeiter ein Trigger "hängt", der nach Erfassung des Mitarbeiters die tblSollstunden zunächst mit 7 Datensätzen für die Woche befüllt. Und zwar folgendermaßen :
100002, 1, 0
100002, 2, 0
100002, 3, 0
100002, 4, 0
100002, 5, 0
100002, 6, 0
100002, 7, 0
Im Beispiel wurde soeben ein Mitarbeiter erfasst der die Personalnummer 100002 bekommen hat. Die 7 Datensätze (für jeden Wochentag einer) wurden durch den Trigger an die tblSollstunden angehängt. Oft sind die Sollstunden bei Erfassung des neuen Mitarbeiters noch nicht bekannt. Deswegen wird das so gemacht, dass diese später editiert werden. Vielleicht hat jemand noch eine Idee, woher dieser Fehler beim Datensatz hinzufügen kommt.

Gruß
Karsten

[DF6GL]

Hallo,

auf Grund der zu sehr fragmentierten und unvollständigen  Informationen (welche relevanten Tabellen gibt und wie heißen die, welche Felder sind die Schlüsselfelder und  welchen Datentyp habe die, wie sind die Beziehungen aufgebaut, gibt es "Timestamp"-Felder in den Tabellen, und ja, welche Trigger gibt es in diesem Zusammenhang, etc....) kann man (wenigstens ich ) nicht viel dazu sagen...

[ellinho]

OK. Bevor ich versuche mal aufzulisten, was relevant sein könnte :
Die Dinge laufen alle vollständig reibungslos ab. Die genannte Fehlermeldung erscheint. Wenn man danach in die tblMitarbeiter schaut, ist der Datensatz hinzugefügt worden. Wenn man in die tblSollstunden schaut, die durch den Trigger gefüllt wird, den ich nachfolgend noch genauer beschreibe, sind dort auch alle Datensätze wie gewünscht, vorhanden.
Nun zur Auflistung der Gegebenheiten:
In der tblMitarbeiter stehen die Stammdaten der Mitarbeiter. PK ist die Personalnummer vom Datentyp nvarchar(255).
In der tblSollstunden stehen die Sollstunden der Mitarbeiter. Dabei ist ein Datensatz pro Mitarbeiter und Wochentag vorhanden. Somit konnte hier nicht als PK die Personalnummer gewählt werden, da sie doppelt vorkommende Werte enthalten würde, sondern das Feld ID vom Typ int. Das Feld Personalnummer hat hier ebenfalls den Datentyp nvarchar (255). Zwischen den beiden Tabellen besteht eine Fremdschlüsselbeziehung für Löschweitergabe. Wenn in der tblMitarbeiter ein Datensatz gelöscht wird, werden alle Datensätze zugehörig zu dieser Personalnummer aus der tblSollstunden gelöscht. Der beschriebene Trigger ist der einzige Trigger in der gesamten Datenbank. Er ist an die tblMitarbeiter gebunden und schreibt beim Hinzufügen eines Datensatzes zu der tblMitarbeiter 7 Datensätze in die tblSollstunden (aufgebaut als Personalnummer,Wochentag,Sollstunden - also z.B. 100002,1,0 als ein Datensatz). Für den automatischen Vorschlag einer freien Personalnummer wurde zusätzlich noch die tblPersonalnummern erstellt. Diese enthält die Felder ID als PK mit Datentyp int und Personalnummer mit Datentyp nvarchar(255). In dieser Tabelle befinden sich alle Personalnummern aus einem Nummernpool, die vergeben werden können. Weiterhin existiert eine Abfrage Persnr auf diese tblPersonalnummern, die alle freien Personalnummern, die nicht in der tblMitarbeiter belegt sind, aus diesem Nummernpool herausfiltert. Die tblPersonalnummern steht in Full Outer Join zu der tblMitarbeiter bezüglich des Feldes Personalnummer. Das Feld Personalnummer im frmMitarbeiter, in dem der Fehler beim Datensatz hinzufügen ausgelöst wird, bekommt den ersten Wert aus der Abfrage Persnr (erste freie Personalnummer) über die Funktion DLookup("Personalnummer","Persnr"), zeigt die richtige Personalnummer auch an und fügt, trotz der Fehlermeldung, den Datensatz auch mit dieser Personalnummer an die tblMitarbeiter an. Der Trigger fügt in der Folge, wie gewünscht, zu der passenden Personalnummer die 7 Datensätze für jeden einzelnen Wochentag an die tblSollstunden an. Da alle gewünschten Funktionen soweit reibungslos durchlaufen, kann ich mir die Fehlermeldung überhaupt nicht erklären. Ich hoffe, die Infos waren soweit ausreichend, um dahinter zu steigen.
mfg
Karsten

[Beaker s.a.]

Hallo Karsten,
Wo wird der Fehler denn ausgelöst?
In deinem unbekannten Code; - welche Zeile wird markiert?
Oder löst der Trigger den Fehler aus?
Ich muss allerdings dazu sagen, dass ich mich mit ADP,
und wahrscheinlich SQL-Server als Backend nicht auskenne.
Mit den Triggern (Datenmakros seit A2010) habe ich mich
noch nicht beschäftigt.
Ansonsten die brutale Methode, wenn denn scheinbar alles richtig ist; -
Fehler abfangen und mit Resume Next weiter im Text, äh, Code.
gruss ekkehard

[ellinho]

Hallo.
Habe den Trigger mal rausgenommen und die Fehlermeldung erscheint nicht mehr. Somit ist der Trigger die Fehlerursache. Hier der Trigger :

USE [PersonalSQL]
GO
/****** Object:  Trigger [dbo].[Sollstundenanfügung]    Script Date: 03/31/2012 14:15:33 ******/
SET ANSI_NULLS ON
GO
SET QUOTED_IDENTIFIER ON
GO
ALTER TRIGGER [dbo].[Sollstundenanfügung]
   ON  [dbo].[Mitarbeiter]
   AFTER INSERT
AS
BEGIN
   INSERT INTO dbo.Sollstunden (Personalnummer,Wochentag,Sollstd)
   SELECT I.Personalnummer,S.Wochentag,S.Sollstd
   FROM inserted I, Zahlentabelle S
   WHERE S.Wochentag IS NOT NULL
   SET NOCOUNT ON;

    -- Insert statements for trigger here

END

Wobei ich noch anfügen muss, dass die Zahlentabelle bisher folgendermaßen aufgebaut war :

Spalte Wochentag , Spalte Sollstd
1 , 0
2 , 0
3 , 0
4 , 0
5 , 0
6 , 0
7 , 0

Die Zahlentabelle habe ich mal um das Feld ID als Autowert und PK erweitert und bekomme nun die Fehlermeldung beim Anfügen des neuen Mitarbeiter-Datensatzes im Formular über die Schaltfläche "Datensatz hinzufügen":
Sie können nicht zu dem angegebenen Datensatz springen.

Bin ratlos.

mfg
Karsten

[Beaker s.a.]

Hallo Karsten,
Wie gesagt, kenne ich mich mit Triggern (noch) nicht aus.
Mir fällt aber Folgendes auf.

Code [Auswählen] Erweitern

  -- Insert statements for trigger here
Wenn ich das richtig interpretiere ist das doch eine Kommentarzeile, - oder?
Die gehört aber wohl, wie man hier sieht

Code [Auswählen] Erweitern

/****** Object:  Trigger [dbo].[Sollstundenanfügung]    Script Date: 03/31/2012 14:15:33 ******/
zwischen / /.
Versuch das mal, oder schmeiß die Zeile ganz raus. Deine "Insert  satements" hast Du ja (wenn ich das richtig verstehe).
Ist ja manchmal so, dass es an solchen einfachen Sachen (Komma statt Semikolon u.ä.) hapert.
hth
gruss ekkehard

[ellinho]

Hallo.

Habe den Fehler nun endlich gefunden. Der Trigger war tatsächlich falsch aufgebaut.

Die Zeile SET NOCOUNT ON; musste versetzt werden.

Hier die entscheidenden Zeilen :

SET NOCOUNT ON;

   INSERT INTO dbo.Sollstunden(Personalnummer, Wochentag ,Sollstd )
   SELECT I.Personalnummer,S.Wochentag,S.Sollstd
   FROM inserted I, Zahlentabelle S
   WHERE S.Wochentag IS NOT NULL


Vielen Dank für jegliche Tipps.

Gruß
Karsten