Palaan vanhaan keskusteluun, jossa yritin tehdä varmistustaulukkoa, mutta ehdotettiin käytettäväksi 'foreign key' -toimintoa. (https://www.ohjelmointiputka.net/keskustelu/
Taulukot asiakas ja tapahtumat. Jos asiakas -taulukossa oleva asiakasnumero muuttuu tai poistetaan niin tapahtumissa olevat tapahtumat ko. asiakasnumerolla pitäisi päivittyä uuteen (tai poistua.)
Kun annan komennon:
alter table Tapahtumat add foreign key (ASIAKASNRO) references Asiakas (ASIAKASNRO) ON UPDATE CASCADE;
Saan virheilmoituksen:
ERROR 1005 (HY000): Can't create table './WERRO/#sql-368c_1.frm' (errno: 150)
Kummassakin taulukossa asiakasnro:n tyyppi on int(10). Mitä teen väärin tai mitä pitäisi muuttaa, jotta saan tapahtumat päivittymään? (käytössä innodb)
- AnttiK
Virheilmoitus sanoo että foreign key:n määrityksessä on virhe.
Lähinnä tulee mieleen, että toteutuuko kaikki foreign keyn vaatimukset, jotka on listattu täällä: http://dev.mysql.com/doc/refman/5.0/en/innodb-foreign-key-constraints.html
Eli esimerkiksi onhan molemmissa tauluissa tuo kenttä indeksoitu, yms.
Asiakas -taulukossa asiakasnro on unique index, koska voi olla vain yksi asiakas samalla numerolla. Tapahtumat -taulukossa asiakasnumeroon on lisätty index.
Homma toimii kyllä, jos kummassakin taulukossa asiakasnumero on unique, mutta tapahtumia voi olla samalla asiakkaalla monta, joten en voi käyttää uniqueta tapahtumat taulukossa.
Miksi muuten asiakasnumeroa pitää pystyä muuttamaan? Eli itse kyllä kyseenalaistaisin tuon ON UPDATE CASCADE tarpeellisuuden.
Asiakas luodaan väliaikaisella asiakasnumerolla, jotta tapahtumia saadaan kirjattua asiakkaan alle heti. Kun "saadaan" virallinen asiakasnumero, niin asiakkaan tiedoista päivitetään asiakasnumero uuteen, jolloin tapahtumat pitää päivittyä uuden asiakasnumeron alle.
Voisiko kyseisen toteuttaa ehkäpä php/mysql:lla? Jos asiakasnumero vaihtuu niin php/mysql etsii tapahtumista kaikki vanhalla asiakasnumerolla olleet tapahtumat ja vaihtaa ne uusiin? :)
En tiedä onnistuuko foreign keyn luonti tapauksessasi ilman tuota cascadeakaan, mutta jos onnistuu niin tekisin itse varmaan juuri noin: Loisin sen lopullisen asiakasnumeron ja erikseen käskisin kantaa päivittämään tilapäiselle numerolle kirjatut tiedot lopulliselle numerolle, jonka jälkeen poistaisin sen tilapäisnumeron.
En kyllä dokumentaatiossa huomannut mitään vaatimusta, että jos viitatussa taulussa on primary key, niin sellainen pitäisi olla viittaavassakin taulussa. Sehän on aika järjen vastaista. Ilmeisesti kuitenkin kokeilit ja totesit että näin on...
Sain toimimaan hommelin, tosin luomalla taulukot uusiksi. Ei onnistunut pelkällä alter -komennolla. Nyt tapahtumien asiakasnumerot vaihtuvat, jos asiakastiedoissa oleva asiakasnumero vaihtuu.
Aihe on jo aika vanha, joten et voi enää vastata siihen.