Hilfe! Kundennummern werden nicht mehr ordnungsgemäß generiert

Bei mir im Shop werden die Kundennummern nicht mehr richtig erstellt. Anstatt der fortlaufenden Nummer bekommt jeder Kunde nun folgende Kd-Nr.: 2147483647

Damit ist der Shop für mich so gut wie unbrauchbar, wenn den Kunden nicht automatisch eine Kundennummer zugewiesen wird.

An den Dateien im Admin-Ordner habe ich bisher keine Änderungen vorgenommen, deswegen wundert es mich dass ich auf einmal solch einen Fehler bekomme. Ich hoffe mir kann geholfen werden, da mein Problem sehr dringend gelöst werden muss.

… diese Kundennummer entspricht nämlich genau dem maximalen Wert eines 32 Bit signed DWord, nämlich 2.147.483.647. Im Klartext: der Shop ist mit den Kundennummern am Anschlag, höher geht nicht.

Oder wie MySQL so schön sagt: Warning: #1264 Out of range value adjusted for column ‘OXCUSTNR’ at row xxx wenn ich 2147483648 in die Datenbank prügeln will -> geht nicht, wird automatisch korrigiert und auf 2147483647 gesetzt. Der Shop muss sich irgendwann einmal einen Kundennummer mit Maximalwert eingefangen haben und kommt da jetzt nicht drüber weil in der Datenbank int(11) für oxcustnr vorgegeben ist. Deswegen bekommen jetzt alle Kunden diese Kundennummer.

Das sollte sicherheitshalber als Ticket an den Support gehen (ggf. mit Verweis auf den Post hier), damit die sich den Shop mal näher ansehen können.

Die Kundennummern müssen korrigiert werden …

Take my love, take my land
Take me where I cannot stand
I don’t care, I’m still free
You can’t take the sky from me …

Danke für deine Antwort Lythaan. Klingt sehr interessant was du geschrieben hast.

Ich werde die Kundennummern vorerst am besten manuell in der Datenbank ändern. Womit der Fehler jedoch immer noch nicht behoben ist, dass in Zukunft nicht wieder die falschen Kundennummern vergeben werden. Müsste da evtl. etwas in der Datenbank abgeändert werden?

also ich würde die anzahl der kunden checken, z.b. 42399 datensätze und würde den letzten in der liste mit 50000 starten lassen, so haste bis zu den 2.147.483.647 jede menge luft.

Grüße
Martina

www.bastelundhobbykiste.de www.kreative-buecher.de

http://twi

Nachdem ich allen Kunden mit der besagten Zahl eine neue Kundennummer gegeben habe, wird diese nun auch beim registrieren eines neuen Kundenkontos fortlaufend weitergeführt, so wie es sein soll. Allerdings habe ich bedenken, dass dieser Fehler wieder auftritt, deshalb wäre es gut wenn man die genaue Ursache dafür beseitigen könnte.

Hallo plexus,

Mit diesem Ansinnen müssten wir uns an den Erfinder der Datenbanken wenden :slight_smile:

Die Zahl 2.147.483.647 ist die größte Zahl, die ein Feld dieses Typs (integer) halten kann. Wenn Du also eigene Nummernkreise für Deine Kunden setzen möchtest, beschränk Dich am besten auf fünf Stellen.

Gruß


Marco Steinhäuser
Community Guide
OXID eSales AG

Hallo Leute,

die Lösung ist einfacher als man denkt.

Zu aller erst, Marco Steinhaeuser, hier bei uns in der Erwähnung liebevoll immer “Steini” genannt, hat völlig recht, was den Datentypen der SQL/MySQL Spalte angeht.

Die eine Lösung wäre, die Kundennummern niedriger anfangen zu lassen.

Was aber, wenn man schon tausende Kunden in der Datenbank hat und die Kundennummern weiterhin fortlaufend haben möchte?
Wir müssen den Datentypen erhöhen, damit weiter gezählt werden kann, d.h. wir machen aus dem Feld, das maximal bis 2.147.483.647 zählen kann ein Feld das noch viel höher zählen kann.

Dazu gibt es vier Wege:

  1. Man meldet sich in der OXID Administration an, navigiert über “Service” -> “Tools” zu den SQL-Tools und gibt in das Feld “SQL ausführen” folgenden Befehl ein

    • ALTER TABLE oxuser CHANGE OXCUSTNR OXCUSTNR BIGINT( 21 ) NOT NULL DEFAULT ‘0’
  2. Man meldet sich über die Commandline auf seinem Server an und gibt im MySQL folgenden Befehl ein

    • ALTER TABLE oxuser CHANGE OXCUSTNR OXCUSTNR BIGINT( 21 ) NOT NULL DEFAULT ‘0’
  3. Im phpMyAdmin klickt man in der Tabelle oxuser rechts neben der Spalte OXCUSTNR auf den “Ändern” Link und wählt in der Selectbox Typ “BIGINT” aus und gibt in das Feld Länge/Set “21” ein

  4. Im phpMyAdmin klickt man im Rechten Frame oben auf SQL und gibt dort den folgenden Befehl ein:

    • ALTER TABLE oxuser CHANGE OXCUSTNR OXCUSTNR BIGINT( 21 ) NOT NULL DEFAULT ‘0’

Nun klappts auch mit dem Nachbarn :slight_smile:

hier bei uns in der Erwähnung liebevoll immer “Steini” genannt

:smiley:

Ansonsten - coole Idee. Ich hätte nur Angst, dass man bei Änderung des Datentyps irgendwo anders unerwünschte Effekte hervorruft…

Gruß
Steini

Kann ich mir nicht vorstellen, da wir ja jetzt nicht aus dem Integer ein Float oder gar ein String/Varchar oderso machen.

Wir vergrößern nur den Interger Bereich, das sollte nirgends kollidieren.
Ich hab die DB auch nochmal überflogen und keine weiteren Felder gefunden wo die Kundennummer nochmals abgelegt werden könnte, daher würde ich entwarnen :wink:

Guten Morgen,

ist zwar schon älter aber ich habe genau das gleiche problem mit meinen Rechnungsnummern. Ist mir grade zufällig aufgefallen das seit einem Monat alle die Rechnungsnummer 2147483648 bekommen.

Ich hoffe das die vom Finanzamt das nicht bemerken sonnst gibs bestimmt Ärger:(

Aber egal. Wie kann ich das am besten wieder reparieren. Ich habe erst ca. 3000 bestellungen im Shop. Von wo sucht Oxid sich die nächste Nummer zum Hochzählen?

Kann ich da irgendwo einen Initialwert setzen?

Ich würde dann einfach ab 5000 weitermachen wenn es möglich ist.

mfg

das wird ein wenig schwierig, weil der Shop immer die höchste vorhandene Nummer sucht und von dort eins weiter zählt

Entweder also von Hand alle zu großen Nummern ändern, oder den Feldtyp in der Datenbank wie von Karatag beschrieben ändern.

könnte mir Jemand ganz spontan eine sql-abfrage basteln die:

  • alle Rechnungsnummern mit 2147483648 löscht
  • die höhste richtige Rechnungsnummer sucht
  • allen Bestellungen die dann keine Nummer haben in der Reihenfolge der Bestellnummern die Rechnungsnummern ab der höhsten vorhanden vergiebt

Ich hoffe das ist verständlich und auch logisch so richtig. Rein theoretisch müsste ich dann noch bei allen neu zugewiesenen Nummern die Rechnungen nochmal an die Kunden raussenden mit dem vermerk das es einen Fehler gab.

Dann müsste auch das Finanzamt wieder glücklich sein.

Ich bitte um Ratschläge für die umsetzung.

mfg

Guten Morgen

irgendwie klappt das nicht. ich habe erst mal die falschen nummern gelöscht

UPDATE `oxorder` 
Set `OXBILLNR` =''
WHERE `OXBILLNR` LIKE '2147483648'

wenn ich dann aber eine neue rechnung erstelle kommt wieder genau die gleiche nummer.

das war bei mir auch varchar(128). die umstellung auf int(11) brachte aber auch nix.

Moin krankes äffchen,

bei dir wirds dann auch die Rechnungnummern 2147483647, 2147483646 etc. geben.
Und bei der nächsten Rechnung zählt der Shop dann eben wieder hoch…
Die einfach auch noch ändern (mit einem grosszügigerem Bereich).

Beste Grüsse

Thomas

hallo,

du hattest Recht die Nummern waren auch noch vorhanden.

Jetzt geht wieder alles. Ich habe auch den Fehler gefunden, der das Verursacht hat.

Es war unsere Praktikantin :smiley:

Sie hatte wohl versehentlich die Trackingnummer in das Rechnungsfeld kopiert, was ja genau darüber liegt.

vielen Dank für eure Hilfe.

mfg