nächste "freie" Zahl finden

[Hansi]

Hey,

Ich möchte ganzzahlige Nummern für Artikel vergeben; Nun soll über eine Schleife so lange gesucht werden bis die nächste noch nicht vergeben Nummer gefunden ist und diese dann dem nächsten Artikel als Artikelnummer vorschlagen.

Wie bekomme ich das mit der Schleife hin, dass er über prüft ob die Nummer in der DB nicht schon vergeben ist?

[Jens Schumann]

Hallo,
in dem Du das Feld in der Datenbank als UNIQUE deklarierst.
Dann kommt bei Versuch die Nummern einzutragen eine Exception.

[SirThornberry]

in datenbanken gibt es dafür eigentlich die Eigenschaft "AutoIncrement" (kann man den Feldern zuordnen). Damit spaarst du dir das manuelle heraussuchen.

[Hansi]

Das Autoincrement kenne ich schon nur möchte ich nicht, dass die Artikelnummer gleich dem Zähler ist. Ich möchte auch selber die Artikelnummer eingeben können.

Könnt Ihr mir ein kleines Bsp für die Schleife geben?

[Robert_G]

Zitat:

Zitat von SirThornberry

in datenbanken gibt es dafür eigentlich die Eigenschaft "AutoIncrement" (kann man den Feldern zuordnen). Damit spaarst du dir das manuelle heraussuchen.

Das gibt es eigentlich nur im SQL Server, alle andere "Programme", die diese (ungemein unflexible) Lösung verwenden sind ja eigentlich nur Desktop spielzeuge. ;)

@Hansi, du hast hier eindeutig einen Thread für die Sparte "Datenbanken" erstellt. Wenn du auf das "!" rechts oben klickst kannst du damit einen Mod fragen, ober er den Thread dahin verschiebt.

Wenn er dann dort angekommen ist, solltest du in die speziellen Felder eintragen welche DB du nutzt und wie du darauf zugreifst.

In deinem Fall würde es nämlich davon abhängen, ob du dir einen Wert aus einem Generator, einer Sequence oder vom Bäcker nebenan holen musst.
Ohne die DB zu kennen können wir das nicht wissen. ;)

[jfheins]

Wie wäre es mit

Code:

while (Artikelnummer in DB) do Inc (Artikelnummer);

Ob die Nummer vorhanden ist, kann man z.B. mit einem Select (oder so) herausfinden :wink:

[yankee]

Jo, allerdings sollgtest du dich daran gewöhnen mit hohen Zahlen zu leben udn ein Primärschlussel zu verwenden. Mir war das am Anfang auch suspekt, aber stell dir mal vor, du verkaufts einen Artikel und später, nimmst du den Artikel aus dem Sortiement. Aus irgendeinem Grund willst du zu der Artikelnummer, die mittlerweile gelöscht ist nochwas nachschauen. Da die Artikelnummer aber mitllerweile von einem anderen Artikel übernommen wurde, findest du die unpassenden Informationenn und das kann führ verwirrung in automatisch verarbeitenden Skripten führen.
Was ja mal interessant wäre, ist, wie sich ein DB verhält, wenn der Primärschlüsselbereich ausgeschöpft ist. Also unter der Vorraussetzung, dass massenhaft "slots" mit kleinerer Id frei sind. Fängt die dann wieder unten ann aufzufüllen?
Naja, ich glaube das probioere ich demnächst mal rauszufinden...

[Jasocul]

Ich rate von dem Verfahren dringend ab.
Mir fallen ad hoc nur zwei Möglichkeiten, sowas zu realisieren.
1. Mit jeder Zahl prüfen, ob diese schon in der Tabelle existiert.
2. Eine Verwaltungstabelle zu führen, die beinhalten, von wo bis wo freie Bereiche verfügbar sind.

zu 1.
Im schlimmsten Fall hast du so viele DB-Zugriffe, wie du Datensätze hast. Wenig sinnvoll.
zu 2.
Willst du wirklich soviel Aufwand treiben?

Das andere Problem, mit schon mal verwendeten Nummern ist auch zu berücksichtigen. Glaub mir, das ist sehr problematisch. Ich hatte mal eine Anwendung, in der die Anwender Kundennummern immer wieder neu belegen konnten (der Anwender bestand darauf). Die Statistiken über die Kunden waren dann irgendwann sehr interessant. Ein neuer Kunde hatte plötzlich Umsätze über mehrere Jahre in seiner Statistik. Ähnliche Probleme dürftest du mit deinen Artikeln bekommen.

[Robert_G]

@Peter
klingt übel... :pale:
Warum hast du nicht intern einen konsistenten Schlüssel benutzt? Die können in ihrer Maske irgendeine Nummer eingeben...
Wenn du aber einen konsistenten, somit von sämtlichen Daten unabhängigen, stur hochzählenden Schlüssel benutzt, sehen sie vielelicht 5-mal die gleiche Nummer. Aber die Verknüpfungen wären weiterhin konsistent. ;) (Der User sollte den PK eh nie zu Gesicht bekommen.. wofür auch? ;) )

[Hansi]

@Jasocul

genau Variante 1 hatte ich vor. Bin gerade am überlegen nicht meine Artikelnummern einfacher zu machen...

[DP-Maintenance]

Dieses Thema wurde von "Sharky" von "Object-Pascal / Delphi-Language" nach "Datenbanken" verschoben.
Auch ohne klick auf das ! habe ich den Thread jetzt mal verschoben. ;-)

[Jasocul]

@Robert_G:
Die statistischen Auswertungen haben den Anwender überzeugt. :lol:
Die haben nämlich einfach die alten Adressdaten überschrieben. Da nützt mir das mit PK auch nichts. Ich benutze fast immer einen internen PK, den der Anwender nie zu sehen bekommt.

@Hansi:
Eine strukturierte (sprechende) ArtikelNr könnte eine Lösung sein (Ist nur ein Vorschlag!).
Z.B.: Materialschlüssel, Artikelgrupppe, Abmessung. Das ganze wird sinnvoll von dir zusammengesetzt. Wenn du dann den Datensatz einfügen willst und du hast einen Unique-Key auf diese Kombination gelegt, bekommst du eine Exception. Dann kannst du dem Anwender mitteilen, dass es diesen Artikel schon gibt.