Pouziti autoincrementu

[Petr Vileta]

> > create table test(cislo int(10) autoincrement, neco varchar(20));
> > insert into test set neco='ABC';
> > insert into test set neco='DEF';
>
> Ufff, piste prosim ty priklady tak, aby si to lidi mohli vzit mysi
> a vyzkouset ...
Co je spatne? Ja to takhle vzal z DOS okna a Ctrl-V :-)

> > Evidentne jsem chtel smazat posledni zaznam a pridat dalsi, ale tak aby
rada
> > navazovala. Jenze bez sachovani s last_insert_id() se mi to nepodari. A
to
>
> No, evidentne jste chtel, aby kdyz smazete cislo z prostredka, aby Vam
> databazovy stroj precisloval vsechna cisla nad tim? To snad ne.
Ne, chtel jsem smazat posledni zaznam, to se v ucetnictvi dost casto
pouziva, ze se maze naposledy zapsany zaznam a jeho misto se znovu pouzije,
vcetne ocislovani. Zkuste libovolny ucetni program (Ucto, Kalkul) a
zjistite, ze kdyz chcete smazat predposledni fakturu, musite napred smazat
posledni a pak teprve tu predposledni. Nelze mazat kdekoliv ale prave a jen
posledni zaznam. No a cele se to musi pak chovat tak, jako kdyby tam ten
smazany zaznam nikdy nebyl. To je pozadavek na chovani programu a
programator to musi nejak zaridit, aby se to tak chovalo.

> To chovani, ktere popisujete, melo MySQL asi pred tremi lety, a byla
> to chyba, a byla opravena. Protoze pokud ma byt auto_increment aspon
> trosku jako sekvence, tak nesmi vydat jedno cislo dvakrat po sobe.
No to jsem zjistil zrovna ted, kdyz to zkousim. Takze jak se v nove verzi
vlastne zjisti posledni pridelena hodnota typu autoincrement? Kdyz dam
SELECT LAST_INSERT_ID() tak mi to k memu zdeseni prideli dalsi cislo, misto
abych se dozvedel, jake to pridelilo naposledy. Takze mi vysvetlete jak
resit nasledujici pripad, rad se naucim neco noveho.
Mam 2 tabulky, ktere jsou svazany nejakym ID. V jedne tabulce to ID je
primarni klic, v dalsi muze byt duplicitni (napriklad cislo kancelare je
unikatni v tabulce kancelari, ale duplicitni v tabulce inventare)
Takze potrebuji zapsat novou kancelar (pridelit unikatni ID) a toto ID
potrebuji znat, abych jej pouzil pro seznam inventare v druhe tabulce.

> nastesti ale zase bez zamykani tabulek. Namatkou: vygenerujte si ta
> cisla dokladu do tabulky
>
> id_dokladu integer unique
> cislo_dokladu integer not null primary key
>
> a cislo dokladu pak nove vytvorenemu zaznamu v tabulce zaznamu
> pridelite jedinym nezamykacim updatem.
Tomu nejak nerozumim. Jak updatem dostanu to cislo do aplikace? Malokdy
clovek vystaci s tim, ze ma jednu tabulku, kde je nutne unikatni cislo.
Mnohem casteji je jedna tabulka s unikatnim klicem, ale totez pole je v jine
tabulce jako neunikatni klic, aby se ty tabulky daly provazat. Priklad:
1) seznam faktur - unikatni ID je cislo faktury
2) seznam pohledavek - ma vlastni cislovani (ID), ale protoze krome faktur
vystavuji i uctenky, tak u kazde pohledavky musi byt pole "typ_dokladu"
(faktura/uctenka) a "cislo_dokladu", kde se musi ulozit to unikatni cislo
faktury.
3) seznam polozek faktury - zde je cislo faktury duplicitni v kazdem
pripade, dokonce je duplicitni i objednaci cislo zbozi, dokonce i kdyz
spojim do klice cislo_faktury+cislo_zbozi muze to byt duplicitni, protoze
proste nektere zbozi je na fakture zapsano 2x. Jednou 2 kusy, a pak si
zakaznik vzpomel, ze chce vlastne 3, ale je rychlejsi proste dopsat jeste
jednou tutez polozku x 1kus, nez opravovat jiz zapsanou na 3 kusy (rychlejsi
pro obsluhujiciho).
Neni mi jasne, jak pomoci UPDATE dostanu do aplikace unikatni cislo faktury
;-)


> Mimochodem, i kdybych pristoupil na Vasi hru, ze chcete, aby nederava
> sekvence prezila delete, tak delete rozhodne neni korektni operace nad
> ucetnimi doklady, ze, narozdil od storna a dobropisu a jinych.
Delete se pripousti prave na posledni zaznam. Nevim jstli to je primo v
zakone, ale rozhodne to je v internich smernicich FU. Neco pisete, udelate
preklep a ulozite to. Jenze v dalsi sekunde zjistite svou chybu, tak se
proste posledni zaznam smaze a zapise znovu. Kdyby se ani tohle
nesmelo/netolerovalo, tak by ucetni knihy byly plne zaznamu "storno - chybny
zapis" :-)
--
Petr