Dotaz: Problem s prechodom z mysql 4 na mysql 5

[Andrea Tokárová]

Dobry den,

mam takyto problem s mysql verziou 5:

Mam tabulku vyrobkov roznych dodavatelov (tabulka : vyrobky). Primarnym klucom v tejto tabulke je ID kazdeho vyrobku, ktore je nasim internym udajom (t.j. nie je identicke s vyrobnym cislom vyrobku, nakolko tieto mozu byt u roznych dodavatelov rovnake, aj ked sa jedna o uplne iny tovar). Dodavatelia mi svoje databazy vyrobkov posielaju v dbf, pricom niektore vyrobky pri updatoch uplne vypadnu z databazy, niektore su tam uplne nove a u niektorych nastanu Moj software funguje tak, ze vzdy, ked dostanem dbf od konkretneho dodavatela (povedzme D), urobi toto:

1/ vyrobi z D.dbf tabulku "pripravna"
2/ do tejto tabulky preberie podla kluca "vyrobne_cislo=vyrobne_cislo and dodavatel="D" ID z tabulky vyrobky
3/ zmaze vsetky vyrobky z tabulky vyrobky where dodavatel="D"
4/ prida to tabulky vyrobkov zaznamy z tabulky pripravna

skript vyzera takto a v mysql 3 a 4 mi fungoval bez problemov:
system('mysqldump -t -c databaza pripravna | sed -e \'/^U*N*LOCK TABLES/d\' >> tmp/pripravna.sql');
system("cat tmp/pripravna.sql | sed -e 's/INSERT INTO pripravna/INSERT INTO vyrobky/' > tmp/pripravna.sql.sed");
$otazka = Qt::SqlQuery("delete from vyrobky where dodav=\"$dod\"");
system("mysql < tmp/pripravna.sql.sed");
this->accept();

tato cast skriptu mi vsak prestal fungovat, ked som updatla mysql na verziu 5 (zaznamy sa do tabulky vyrobkov nepridaju a system vypise : DUPLICATE ENTRY FOR KEY 1)

Dakujem Vam za radu!

ps. skript som nepisala ja, som len laik, ktory sa do programovania nevyzna, len chape principy,ale admina mam na dovolenke a ja ten skript nutne potrebujem mat chodiaci :)

Odpovědi

[Filip Jirsák]

Z té chybové hlášky to vypadá, že v tabulce už je jeden záznam s klíčem 1 a vy se pokoušíte přidat další. Opravdu tam nic takového není?

[Andrea Tokárová]

nie, nie je

prave o to ide, ze skript sa tvari, ako keby tam uz take ID bol, ale ked si dam vyselektovat zaznamy s danym ID, tak mi vrati empty set

tento skript mi 3 roky fungoval bez problemov a bez akehokolvek zasahu, problem nastal len teraz, ked som presla na vyssiu verziu mysql

[okbob]

Mezi 4 a 5 se zmenilo vychozi nastaveni COLLATE pro nektera kodovani. Pravdepodobne bude nyni CASE INSENSITIVE

[Andrea Tokárová]

viete mi, prosim, poslat link, kde sa o tom nieco blizsie pise? alebo aspon, pre ktore kodovania? pouzivam utf8

[okbob]

nepise se o tom nikde, ale resil jsem podobny problem.

[Andrea Tokárová]

a pomohlo to, co ste sem napisali vcera? :)

[okbob]

pomohlo explicitne nastavit collate pro primarni klic. Je na to nejaky alter

[svido]

Osobně bych se také přikláněl k tomu, že je duplicitní záznam. Nevidím důvod, proč by mělo mySQL vrátit chybu, když by tam nebyla. :-O

[Andrea Tokárová]

skutocne tam duplicitny zaznam nie je... chybu mi vypise hned pri prvom zazname tabulky pripravna, ktory ma ID=102456 a ked dam select * from vyrobky where ID=102456, tak mi vrati empty set

opakujem, ze tento skript mi tri roky bezal bez akehokolvek problemu, vobec nic sa nemenilo, ani na nasom softe ani na databaze od dodavatela, proste, standardna vymena databazy daneho dodavatela, ake som predtym robievala desiatky mesacne a teraz, po update mysql z verzie 4 na verziu 5 mi vypisuje takuto cybu...

[Filip Jirsák]

A je tam unikátní index opravdu jen na ID? Je možné sem dát třeba Strukturu příslušné tabulky (nejlépe CREATE TABLE, který jí vytváří) a třeba jeden rádek INSERTu?

[Andrea Tokárová]

tu je kusok kodu (zaciatok suboru pripravna.sql.sed:

use databaza;

-- MySQL dump 10.10 -- -- Host: localhost Database: databaza -- ------------------------------------------------------ -- Server version 5.0.22-Debian_3-log

/*!40101 SET @OLD_CHARACTER_SET_CLIENT=@@CHARACTER_SET_CLIENT */; /*!40101 SET @OLD_CHARACTER_SET_RESULTS=@@CHARACTER_SET_RESULTS */; /*!40101 SET @OLD_COLLATION_CONNECTION=@@COLLATION_CONNECTION */; /*!40101 SET NAMES utf8 */; /*!40103 SET @OLD_TIME_ZONE=@@TIME_ZONE */; /*!40103 SET TIME_ZONE='+00:00' */; /*!40014 SET @OLD_UNIQUE_CHECKS=@@UNIQUE_CHECKS, UNIQUE_CHECKS=0 */; /*!40014 SET @OLD_FOREIGN_KEY_CHECKS=@@FOREIGN_KEY_CHECKS, FOREIGN_KEY_CHECKS=0 */; /*!40101 SET @OLD_SQL_MODE=@@SQL_MODE, SQL_MODE='NO_AUTO_VALUE_ON_ZERO' */; /*!40111 SET @OLD_SQL_NOTES=@@SQL_NOTES, SQL_NOTES=0 */;

-- -- Dumping data for table `pripravna` --

/*!40000 ALTER TABLE `pripravna` DISABLE KEYS */; INSERT INTO `pripravna` (`POCET`, `OC`, `NOSIC`, `INTERPRET`, `TITUL`, `CP`, `ZANER`, `label`, `DATVYD`, `DODAV`, `CKOD`, `CN`, `CDOP`, `DPH`, `DOD_DOBA`, `sklad`, `CAKCIOVA`, `AKCIA_DO`, `EAN`, `POPIS`, `KAT`, `CBUZNOST`, `ZMENA`, `POPIS_NOS`, `ID`) VALUES (0,'010014-2','CD','VISACI ZAMEK','02 START',150,'R','EMI / Monitor Czech

ono to vlastne funguje tak, ze v tom dumpe sa retazec "INSERT INTO pripravna" nahradi reťazcom "INSERT INTO vyrobky"

a tento sa potom prezenie cez mysql

Vcera som skusila urobit to, ze som vsetky vyrobky z tabulky pripravna nahodila do tabulky vyrobky rucne, prikazom: INSERT INTO vyrobky SELECT * FROM pripravna ORDER BY id;

( poradil mi to kamarat, ktory mi napisal, ze 'To "ORDER BY id" je tam preto, lebo v MySQL je asi nejaký bug a bez toho to poriadne neprejde.')

Takto viem v pohode vlozit dane tituly. Nejde to len cez skript.

[miso]

V tom skripte (PyQt?) ma zaujal riadok
$otazka = Qt::SqlQuery("delete from vyrobky where dodav=\"$dod\"");
Maju vsetky riadky v dumpe rovnaky 'dodav'?

[Andrea Tokárová]

ano, maju

v tabulke vyrobky sa ale mozu deletovat len tie, ktorych sa tyka vymena, ostatnych dodavatelov sa to nedotkne

[miso]

Mohli by ste sem dat par riadkov z dumpu 'pripravena'?
Mozno je nejaky problem v zmene syntaxe dump/import