Üdv!

A phpAdminban az adatbázis indexet kell módosítani.

yoku írta::
Üdv
Én a Unique Order Number v1.03-at szeretném feltenni.
A 2.1 es pontot nem értem.
2.2 világos, nem lesz baj...

Igen, én is pont itt akadtam meg!

=====================================================

2) In your MySQL database, make the following changes:

2.1) Turn off "auto_increment"

Turn off "auto_increment" in the "orders" table (edit your MySQL table)

2.2) Change Type for "order_id"

For the following tables (in MySQL database), change the "order_id" type

from "INT(11)" TO "BIGINT(11)" so that it will go higher than eleven:

- orders
- orders_products
- orders_products_attributes
- orders_products_download
- orders_status_history
- orders_total

=====================================================

Hali!

Adatbázist mentsetek, mert kegyetlenül el lehet szúrni!

Mi volt a gond? Nem lehet kikapcsolni?
Ezt a képet a vendég nem láthatja. A megtekintése csak regisztrált és bejelentkezett felhasználók részére engedélyezett.

vagy


Ha a 2.2 megy akkor ennek is kellene.

Az INT(11) értéket pedig BIGINT(11)-re kell változtatni az összes felsorolt táblában.

pl:

Kedves tgely!

ÍGY már érthető, mit is kell csinálni egyáltalán...
Yoku és én is ezt nem értettük, mit és hogyan kellene csinálnunk az adatbázisban?

(Bocs, de nem mindenki tanulta ezeket a dolgokat, honnan kellene tudnunk? De ha valaki érthetően elmagyarázza és megmutatja, akkor már tudni fogjuk.)

Köszönöm a segítséget!

Üdv

Igen, köszi szépen. Így már érthető, hol kell átkapcsolni a cuccost...
Egy költözés után vagyok, még meg kell valamit csinálnom, és utána megcsinálom ezt is.

Szerk:
Megoldva, most állok neki én is ennek.
Köszi

Belba írta::


...

Ilyen a levél, amit a Vevőktől kapok a "Levélküldőből" :


Ezt a képet a vendég nem láthatja. A megtekintése csak regisztrált és bejelentkezett felhasználók részére engedélyezett.

...



Szia.
Valahogy kapcsolatba lehet veled lépni?
Köszi.
Üdv

Ja,...
A "Profil"-adataimnál ideiglenesen kitettem az email-címem.

Van egy nagyon egyszerű módja, hogy a rendelési számok ne legyenek kiszámíthatóak.

A checkout_process.php fájlba ez után a sor után ami így kezdődik:



Ezt szúrd be:

Vakondka!

Én most gyorsan kipróbáltam, de nálam nem történt semmi, ugyanúgy a következő sorszámot kapta a leadott megrendelés...
Lehet, valamit nem jól csináltam???

Ez volt eredetileg a shop/checkout_process-php fájlban :

// send emails to other people
if (SEND_EXTRA_ORDER_EMAILS_TO != '') {
tep_mail('', SEND_EXTRA_ORDER_EMAILS_TO, $new_mail_subject, $email_order, STORE_OWNER, STORE_OWNER_EMAIL_ADDRESS);
}

Ilyen lett beillesztés után :

// send emails to other people
if (SEND_EXTRA_ORDER_EMAILS_TO != '') {
tep_mail('', SEND_EXTRA_ORDER_EMAILS_TO, $new_mail_subject, $email_order, STORE_OWNER, STORE_OWNER_EMAIL_ADDRESS);
srand((double)microtime()*1000000);
$rand= rand(1,50);
$new_id=$rand+ $insert_id;
$sql="ALTER TABLE `orders` AUTO_INCREMENT =".$new_id;
tep_db_query($sql);
}

Mit nem csináltam jól?

=================================

HELYESBÍTEK!!!

Próbaképpen 4 teszt-megrendelés adtam le egymás után (nem akartam elhinni, hogy a kód nem működik) és TÉNYLEG változó megrendelési számokat ad a rendszer!!!

Elsőre "véletlenül"pont a soronkövetkező számot adta (ezért hittem, hogy nem működik), de utána már össze-vissza számok jöttek!

4181
4182
4183
4184*
4188*
4213*
4224*


KÖSZI, Vakondka!
Ez SZUPERJÓ!
És sokkal egyszerűbb betenni, mint a másik bővítményt!

Háááát ennek a valószínűsége nagyon minimális....
De ha gondolod írd át ezt a sort:
$rand= rand(1,50);

Erre:
$rand= rand(3,50);

Így minimum 3-at fog "ugrani" a sorszám.

Persze hogy könnyebb beépíteni...én írtam

Na, most 3 shopnál tettem be ezt a kis bővítményt és képzeld : mindháromnál az történt, hogy a telepítés után leadott első megrendelés sorszáma +1-el nőtt (vagyis a soron következő sorszám íródott be).

De utána már működött mindenhol a véletlenszám generáló : +4, +25, +11, +41, +34, +15-tel nőttek a számok!

Úgyhogy, nagyon jól működik!!!

Kicsit OFF a topicban, de itt tárgyaltuk ki az idő+dátum alapján előállított order_id-t is, ezért bátorkodom ide írni. Szóval, nekem az alábbi gondom van:

Ha valaki lead egy rendelést, akkor az emailben pl a 02122010143842
order id-t kapja, azonban az adatbázisban 0 nélkül jelenik meg (2122010143842). De nem sok ez a 13 meg 14 karakter a bigint(11)típusú db.orders.orders_id táblában? Nem 11 karakternek kéne lennie?

KÉP: kepfeltoltes.hu/100212/osc_www.kepfeltoltes.hu_.png


S így az admin menüben se tudom megnézni/módosítani a rendeléseket ( HIBA!: Rendelés nem létezik!)

Mit ronthattam el, plz help.
Köszi

Szerintem egyáltalán nem jó ötlet, hogy a dátum és az idő legyen a rendelési szám...nem hiába tervezték meg így az adatbázis szerkezetet eredetileg.
több helyen szükség van erre az azonosítóra, csak egész szám lehet és nullával nem kezdődhet.

Esetleg ha az évszám lenne az első szám akkor valószínűleg nem kezdődne nullával és nyílván ha kevés a 11 karakter akkor meg lehet változatni a phpmyadmin segítségével.

Szóval elméletben meg lehet csinálni, gyakorlatban nem látom semmi értelmét a dolognak, hiszen a entebb leírt módszerem segítségével egyszerűen megoldható, hogy ne egymás után következzenek a rendelési számok, vagyis ne egyesével nőjenek.

Yoku!

Ennek az általad feltett bővítménynek a leírásában (fenn) van egy magyarázó szöveg, amiből kiderül, hogyan van kódolva a megrendelés szám (dátum-óra-perc-másodperc)...

The order number will consist of: Month, Year, Hour, Minute, Second. Basically:

date("mdYHis") = mmddyyyyhhmmss (14 DIGITS)

Látom, te ezt használtad, pedig lehetne a magyar dátum beállítás szerint is használni a kódot :

date("ymdHis") = yymmddhhmmss (12 Digits)
--> 080324034216 --> 2008 Március 24. 03:42:16


date("YmdHis") = yyyymmddhhmmss (14 Digits)
--> 20080324034216 --> 2008 Március 24. 03:42:16

Ha az utolsó kódot használnád, akkor nem kezdődne soha a megrendelési számod nullával!!!

Próbáld ki, hogy ezt a kódot átírod a catalog/checkout_process.php fálban erre : date("YmdHis")


Amúgy én Vakondka megoldását tettem fel, remekül működik, alig pár perc alatt telepíthető volt!

Üdv.
Pontosan ugyan ezt próbáltam én is pár perccel ezelőtt. Sajnos így sem jó. Próbáltam kis y-nal is, hogy 2 jegyű legyen az évszám, de úgy tűnik nem ez a hiba forrása.

Közben rájöttem hogy a bigInt(x) nem azt jelenti, hogy x jegyű lehet a szám, hanem x+n , azaz TÖBB mint 11 jegyűnek kell lennie. Így nem is azzal van a gond, hogy 13 vagy 14 jegyű a megrendelés száma, és nem is a 0-van kezdés. Máshol kell keresnem a hibát

A törlés és a számlázás működik rendesen admin felületen. Utóbbiban van egy kis elírás, ezt szerintem Vakondka javítani fogja:
KÉP:
kepfeltoltes.hu/100212/osc2_www.kepfeltoltes.hu_.png
Azaz, ha az admin felületen rákattintok a számlázásra, akkor fordított sorrendben vannak a dolgok. Vagy ez csak nálam van?

Érdekes, hogy a a törlés működik, de a módosítás nem akar, pedig ugyan az a hivatkozás:
.../adm/orders.php?page=1&oID=20100212164442&action=delete Müxik
.../adm/orders.php?page=1&oID=20100212164442&action=edit Nem müxik

Ebből én arra következtetek, hogy nem az adatbázissal van a gond.

Talán az bekavarhat, hogy az USA-ban van a szerver, és az ottani szerver időt kapja meg és nem a helyit a megrendelés? (2010.02.12. 16:44:42 miközben a próbarendelést kb 22:55 kor adtam le)

Igazából nem életbevágó ez az egész, nem nagy shop, inkább csak tanulgatni szeretnék, és ezért választom általában a nehezebb utat (pl extra info...)


Üdv

Szerk:
Azt hiszem, megvan a hiba forrása. (kop kop kop, csak nehogy elkiabáljam.)
Leszedtem az Unique Order Number v1.03 - FULL PACKAGE & Bug Fix (addons.oscommerce.com/info/4732) csomagot, és az admin/orders.php-t lecseréltem. Egyenlőre minden müxik rendesen.
Most összehasonlítom a 2 fájlt, és megnézem miben különböznek