Darkchild, ist das da echt Dein Ernst ?
Du versuchst etwas zu machen, was man eine "sprechende Nr." nennt. Der Name hört sich echt komisch an, aber eventuell hätte dein Opa das auch noch so gemacht.
Die haben sich früher Codes ausgedacht und das ergab z.B. ellenlange Artikelnummern. Textilbereich ist immer gutes Beispiel : erst mal eine Art.Nr., dann wurde eine Lieferantennr., die Farbe, die Größe usw. so drangebaut, dass der ders weiß lediglich anhand der reinen Art.Nr. wissen konnte : der sucht ein T-Shirt von XY und zwar in weinrot und Größe XXL. Dann sieht er noch : hinten ist eine 1, also kein T-Shirt, sondern langer Arm.
Bei Deinem konkreten Problem fangen in der Richtung auch schon gleich die Probleme mit dieser Vorgehensweise an : du haust die Felder genauso zusammen, wie die damals. Mittlerweile fehlt aber der Grund dazu ! Ich habe z.B. auf den ersten Blick nicht mal gesehen, wo der Unterschied bei den 2 Bsp.-Nummern liegt. Man sieht tatsächlich heute in der Praxis aber auch noch solche Ansätze. Im konkreten Fall allerdings sind die Probleme in Richtung Trigger usw. so nicht zu lösen. Warum ? Man kriegt durch die Verwurstung von 2 Feldern, zumindest in dieser Weise mit Datum usw., keine fortlaufenden Nummern hin.
Allerdings ist mir jetzt klar, wie der Generator ins Spiel kam. Muss noch ein Bsp. bringen. Die ProjektNr. lautet z.B. jetzt im Moment (Jahr usw. egal) : 101105. 5 steht dabei für laufende Nr. Nicht Jahr ! Was ist jetzt mit dem Generator am Montag ? Beim ersten mal müßte er lauten : 131101. Wie bringe ich nun den Trigger dazu, den genau auf diesen Wert zu setzen ?
Geht nicht. Nimm besser wirklich eine Table mit 2 Feldern, wie bereits gesagt und lasse bloß die Generatoren in Ruhe.
Die sind nämlich ziemlich dumm. Als einzige unterliegen sie nicht der Transaktionskontrolle. Wert gesetzt, dann ist der eben so. Was heißt : nix Rollback, Commit usw. Könnte tödlich sein für
DB. 8) Diese Dinger manuell oder vom Programm aus zu manipulieren, das würde ich mir nicht angewöhnen.