zweimal AUTO_INCREMENT ?, bitte mal SQL-Profi Einstellungen

[mercurius]

hi,

eigentlich bräuchte ich in der DB-Tabelle "Orders" zweimal ein Datenbankfeld vom Typ "AUTO_INCREMENT"
- orders_id
- orders_invoice_number

Gibts da irgendeine Möglichkeit ?

Der Beitrag wurde von mercurius bearbeitet: 01.07.2010 09:46

[mercurius]

nein, das geht gar nicht mit AUTO_INCREMENT, da eine glöschte Nummer nicht neu besetzt sondern ausgelassen wird.
Also mal anders.... folgendes Problem.
Ich muss erreichen, dass erst beim schreiben in die DB die letzte vorhandene Nummer + 1 festgestellt wird.
Bisher wird die letzte Nummer +1 beim Aufruf der Seite ermittelt:

QUELLTEXT

  $last_invoice_number = tep_db_query("SELECT orders_invoice_number FROM " . TABLE_ORDERS ." ORDER BY `orders_invoice_number` DESC LIMIT 1");
  $last_in = mysql_fetch_array($last_invoice_number);
  if ($last_in['orders_invoice_number'] >= '900000') {
    $new_invoice_number = $last_in['orders_invoice_number']+1;
  } else {
    $new_invoice_number = '900000';
  }

und dann kann zweitversetzt diese Nummer per Button in die DB gehämmert werden:

QUELLTEXT

echo '<FORM method="POST" action="orders.php?' . tep_get_all_get_params(array('oID', 'action')) . '&oID=' . $orders['orders_id'] . '"><input name="orders_invoice_number" size="6" type="hidden" value="' . $new_invoice_number . '"><input type="Submit" value="OK"></FORM>';

So kann es aber auch zu doppelten Nummern kommen, wenn an mehreren Arbeitsplätzen gleichzeitig gearbeitet wird.
Wie kann ich denn das umgehen ? Irgendwie müsste die letzte Nummer erst ermittelt werden, wenn in DB geschrieben wird

Der Beitrag wurde von mercurius bearbeitet: 01.07.2010 10:17

[John Doswell]

dann mach doch oben bei der action auch eine db afrage nach der letzten nummer + 1 rein!???

greetz john

[mercurius]

dann mach doch oben bei der action auch eine db afrage nach der letzten nummer + 1 rein!???

greetz john

jajaja John, sehr guter Vorschlag.
Aber denkste denn, ich krieg das hin ?
Wie bastel ich die Abfrage da rein ?
Ich habs an dieser Stelle probiert, dat will aber nich:

QUELLTEXT

value="' . $new_invoice_number . '"

EDIT: ahhh... mooooment ich glaube ich habs


Der Beitrag wurde von mercurius bearbeitet: 01.07.2010 11:08

[mercurius]

ich habs einfach mal so probiert:

QUELLTEXT

'<FORM method="POST" action="orders.php?' . tep_get_all_get_params(array('oID', 'action')) . '&oID=' . $orders['orders_id'] . '"><input name="orders_invoice_number" size="6" type="hidden" value="' . $last_in = mysql_fetch_array($last_invoice_number) . $last_in['orders_invoice_number']+1 . '"><input type="Submit" value="OK"></FORM>'

das funzt nicht.
Also wie bau ich das da ein ?

[mrpellepelle]

oh oh oh, sorry, aber das ergibt keine Sinn was du da codest.

Wieso ist die Nummer eigentlich immer 900000 wenn <= 900000?

Wie John schon sagte, ermittle den maximalen Wert+1 erst wenn in die DB geschrieben wird, also dort wo der Action verarbeitet wird.

Der Beitrag wurde von mrpellepelle bearbeitet: 01.07.2010 11:54

[mercurius]

ermittle den maximalen Wert+1 erst wenn in die DB geschrieben wird, also dort wo der Action verarbeitet wird.

ein Stück Code würde helfen. Das es da rein muss dürfte klar sein
PS: die Nummer wird schon richtig ermittelt... nur leider eben nicht bei der action

Der Beitrag wurde von mercurius bearbeitet: 01.07.2010 12:09

[Paulchen_Panther]

Hi,

vielleicht hilft dir dies:

QUELLTEXT

$nextpid_query = tep_db_fetch_array(tep_db_query("SHOW TABLE STATUS LIKE 'products'"));
$neu= $nextpid_query['Auto_increment'];

Gruß
Paul

Der Beitrag wurde von Paulchen_Panther bearbeitet: 01.07.2010 13:14

[mercurius]

Hi,

nö, das hilft leider nicht.
Ich muss das anscheinend komplett umbauen.
Ich krieg in dem FORM einfach nicht "action=update_order" unter.

Also werd ich es mal mit "tep_draw_form" probieren und den DB-Code oben in die action nehmen.
Aber das Ganze dann heute Abend/Nacht... hier ist im Moment einfach zuviel los.

Trotzdem Danke an Alle erstmal...

[mrpellepelle]

ein Stück Code würde helfen. Das es da rein muss dürfte klar sein
PS: die Nummer wird schon richtig ermittelt... nur leider eben nicht bei der action

Anscheinend ist es dir nicht ganz klar. Du versuchst es ja in die html Ausgabe zu drücken, das ist aber der falsche Platz.
Es muß dort hin, wo der Request dieses Htmlformulars verarbeitet wird. das ist irgendwo dort, wo die action Variable geswichted wird. Wo das in deinem Code ist weis ich nicht.

[mercurius]

Anscheinend ist es dir nicht ganz klar.

naja, klar ist mir das schon.
Ich wollte es eigentlich so schmal wie möglich machen weil ich diese Funktion zweimal in der orders.php habe.
Das ging so aber leider nicht.
Also zusätzliches case anlegen und vorhandenes case erweitern.
Nun hab ich eben nochmal 30 Zeilen mehr.
Danke an Alle

[aleb]

am leichtesten geht das mit einem Trigger (allerdings erst ab mySQL 5). Das hat den Vorteil, dass man in php nichts codieren muss:

QUELLTEXT

CREATE TRIGGER calcOrderNo  BEFORE INSERT ON meineTablle
FOR EACH ROW
SET NEW.new_invoice_number=
(SELECT MAX(new_invoice_number)+1 FROM meineTabelle)

Den Trigger fügt man mit z.B. mit phpMyAdmin in die DB ein ...

Ausserdem empfiehlt sich dann natürlich ein Index auf new_invoice_number

Der Beitrag wurde von aleb bearbeitet: 01.07.2010 22:21

[Ingo Malchow]

Aaaalso. Ihr habt schon einmal erkannt, daß es nur ein Datenfeld mit der Eigenschaft auto_increment geben kann,
Trotzdem kann man die Arbeit (fortzählen der Rechnungsnummer) dem Datenbankserver überlassen, indem man eine Hilfstabelle anlegt. Etwas so:

QUELLTEXT

CREATE TABLE `invoice_number` (
  `invoice_number` int(11) NOT NULL auto_increment,
  `orders_id` int(11) NOT NULL default '0',
  `invoice_date` date default NULL,
  PRIMARY KEY  (`invoice_number`),
  KEY `orders_id` (`orders_id`)
) ENGINE=MyISAM

Und schwups hat man eine fortlaufende Rechnungsnummer MIT Datum. Ein teil davon dürfte bereits in meinem osc45 enthalten sein.
Im Admin (Class order) kann man auch eine Abfrage einbauen, die das Objekt um entsprechende Eigenschaften erweitert.
Hier mal ein Ausschnitt aus unserem Shop:

QUELLTEXT

      $query = tep_db_query('select invoice_number, date_format(invoice_date, "%Y-%m-%d") as invoice_date from ' . TABLE_INVOICE_NUMBER . ' where orders_id = "' . intval($order['orders_id']) . '"');
      $result = tep_db_fetch_array($query);
      if (isset($result['invoice_number'])) {
        $this->info['invoice_number'] = intval($result['invoice_number']);
        $this->info['invoice_date'] = $result['invoice_date'];
        $this->info['invoice_filename'] = substr($result['invoice_date'], 0, 4) . '/' . substr($result['invoice_date'], 5, 2) . '/' . $result['invoice_number'] . '.pdf';
      } else {
        $this->info['invoice_number'] = '0';
        $this->info['invoice_date'] = date('Y-m-d');
        $this->info['invoice_filename'] = '';
      }

[mercurius]

Trotzdem kann man die Arbeit (fortzählen der Rechnungsnummer) dem Datenbankserver überlassen, indem man eine Hilfstabelle anlegt.

Na so ein Dreck. Das wars, was ich im Hinterkopf hatte aber eben nicht mehr genau wusste wie es geht.
Im Netz hatte ich auch zwei Threads dazu gefunden, die aber ohne Erfolgsmeldung offen blieben.
Dennoch bleibt eine wichtige Frage offen:
Was passiert bei Korrekturen in der Datenbank ?
Im seltensten Fall (der eigentlich nicht eintreten sollte) muss z.B. die letzte Rechnung-Nummer gelöscht werden.
Wie schauts dann aus mit deiner Lösung ? Bei "AUTO_INCREMENT" wird die gelöschte Nummer ausgelassen und weitergezählt.
Das hat zur Folge, dass dir irgendwann eine Rechnung-Nummer fehlt.

Wie dem auch sein, ich habe jetzt ein zusätzliches Case angelegt.
Nun wird immer die letzte Rechnung-Nummer ermittelt und auch gecheckt, ob eine Rechnung-Nummer für die Order schon existiert:

QUELLTEXT

case 'update_invoice':
        $oID = tep_db_prepare_input($_GET['oID']);
        $orders_invoice_number = tep_db_prepare_input($_POST['orders_invoice_number']);
        $check_invoice_query = tep_db_query("SELECT orders_invoice_number FROM " . TABLE_ORDERS . " WHERE orders_id = '" . (int)$oID . "'");
        $check_invoice = tep_db_fetch_array($check_invoice_query);
        $last_invoice_number = tep_db_query("SELECT orders_invoice_number FROM " . TABLE_ORDERS ." ORDER BY `orders_invoice_number` DESC LIMIT 1");
        $last_in = mysql_fetch_array($last_invoice_number);
        $new_invoice_number = $last_in['orders_invoice_number']+1;
        if ($check_invoice['orders_invoice_number'] == '0') {
          tep_db_query(" update " . TABLE_ORDERS . " set orders_invoice_number = '" . tep_db_input($new_invoice_number) . "', orders_invoice_date = now(), last_modified = now() where orders_id = '" . tep_db_input($oID) . "'");
        }  
        tep_redirect(tep_href_link(FILENAME_ORDERS, tep_get_all_get_params(array('action'))));
        break;

Somit können jetzt an mehreren Arbeitsplätzen Rechnungen ohne Komplikationen erstellt werden.

[mrpellepelle]

Was passiert bei Korrekturen in der Datenbank ?

Was meinst du genau?

Im seltensten Fall (der eigentlich nicht eintreten sollte) muss z.B. die letzte Rechnung-Nummer gelöscht werden.

Rechtlich überhaupt zulässig?
Ich würde die Rechnungnummer erst setzen sobald die Rechung in irgendeiner Form, gedruckt / abgeschlossen ist.

Fals doch muß man eben mit ALTER TABLE ran.

[mercurius]

Rechtlich überhaupt zulässig?
Ich würde die Rechnungnummer erst setzen sobald die Rechung in irgendeiner Form, gedruckt / abgeschlossen ist.

Probleme gibts natürlich, wenn eine Nummer zwischendurch fehlt.
Sollte eine Rechnung dem Kunden überlassen oder in der FiBu gebucht worden sein, sollte/muss in jedem Fall ein zweiter Vorgang (Storno oder Gutschrift) erstellt werden.
Aber: solange die Rechnung weder gebucht noch dem Kunden überlassen wurde, kannst du doch damit machen was du willst.
Gerade eben bei den ganzen Test habe ich immer wieder 2, 3 Rechnungen erstellt und in der Datenbank anschliessend die Nummern wieder rausgenommen.

Im täglichen Betriebsablauf (gerade wenn auch weitere Mitarbeiter beteiligt sind) sollte man das besser "Idiotensicher" gestalten.
Bei mir kann dann auch niemand eine vergebene Nummer manipulieren.

[Paulchen_Panther]

Ein teil davon dürfte bereits in meinem osc45 enthalten sein.
Im Admin (Class order) kann man auch eine Abfrage einbauen, die das Objekt um entsprechende Eigenschaften erweitert.
Hier mal ein Ausschnitt aus unserem Shop:

QUELLTEXT

      $query = tep_db_query('select invoice_number, date_format(invoice_date, "%Y-%m-%d") as invoice_date from ' . TABLE_INVOICE_NUMBER . ' where orders_id = "' . intval($order['orders_id']) . '"');
      $result = tep_db_fetch_array($query);
      if (isset($result['invoice_number'])) {
        $this->info['invoice_number'] = intval($result['invoice_number']);
        $this->info['invoice_date'] = $result['invoice_date'];
        $this->info['invoice_filename'] = substr($result['invoice_date'], 0, 4) . '/' . substr($result['invoice_date'], 5, 2) . '/' . $result['invoice_number'] . '.pdf';
      } else {
        $this->info['invoice_number'] = '0';
        $this->info['invoice_date'] = date('Y-m-d');
        $this->info['invoice_filename'] = '';
      }

Hallo Ingo,

also der Teil ist in Deinem osc45 leider nicht enthalten...

Gruß
Paul

[Ingo Malchow]

...Hier mal ein Ausschnitt aus unserem Shop...

[John Doswell]

Rechtlich überhaupt zulässig?

das ist die gute frage, ob es generell zulässig ist.. osC als WaWi zu verwenden...
es gibt ja heute immernoch leute die ihre rechnungen in word oder exel ausdrucken!
so lange die rechnungen in reihenfolge sind und im falle einer prüfung dann auch übereinstimmen...
man reicht ja auch nicht seinen shop beim steuerberater ein, aber dazu findet sich ja schon bereits einiges hier in der suche *kicher*

greetz john

[Ingo Malchow]

Ich weiß jetzt nicht, wo die fortlaufende Rechnungsnummer in einem Gesetzestext gefordert wird. Es gibt allerdings genügend Beispiele, daß damit nicht automatisch eine numerisch ununterbrochene Reihenfolge verbunden ist.
Unbeanstandet bleiben dabei regelmäßig mehrere Nummerkreise. Sogar wilde Nummersysteme ohne Zusammenhang sind wohl möglich, wenn über ein weiteres System eine ununterbroche Reihenfolge nachgewiesen werden kann.
Aber zurück zum Thema. Meist entscheidend ist eine Aktion, die einem Auftrag eine Rechnungsnummer zuweist und danach diese Aktion unmöglich macht. In meinem Beispiel bedeutet das, daß in die (Hilfs-)Tabelle nur Aufträe (orders_id) aufgenommen werden, die es darin noch nicht gibt. Anschließend darf der Auftrag nicht mehr bearbeitet werden. Nicht daß jemand auf die Idee kommt, Produkte des Auftrags zu ändern oder zB. das Land der Lieferadresse zu ändern. Wenn, wie bei uns, etwa 10 Personen Zugriff auf die Auftragsdaten haben, kommt man um ein Rechte-management nicht herum. Ich darf alles, die anderen nicht. (Trotzdem kommen haarsträubdende Änderungswünsche zu mir. Gut daß die Leute das nicht selbst können.)
Lange Rede - kurzer Sinn. Es gibt wohl eher keine allgemeingültige Lösung, die alles abdeckt.
Und zurück zum Thema: Diese Hilfstabelle sorgt für die fortlaufende Nummer. Wenn man wirklich die höchste Nummer löschen will, kann man das auto_increment auf den Wert davor setzen. Soll diese Hilfstabelle nicht benutzt werden, kann man diese Funktionalität zum Teil mit select max(nummer)... nachbilden.