[PHP] PDO insert werkt enkel voor bepaalde waardes

[azerty]

Na een tijdje proberen toch maar een topic openen, want ik kom er echt niet meer aan uit...

Ik heb een functie die een waarde in een tabel moet wegschrijven:

PHP:

    public function setPreferenceForUser(User $user, $preferenceKey, $preference)
    {
        $uid = $user->getId();
        $preference = $preference ? 1 : 0;

        $this->pdo->setAttribute(PDO::ATTR_ERRMODE, PDO::ERRMODE_EXCEPTION);
        $stmt = $this->pdo->prepare("INSERT INTO user_settings (user_id, settings_id, `value`) VALUES (:uid, (SELECT `id` FROM settings WHERE `key` = :key), :preference)");
        $stmt->bindParam(":uid", $uid, PDO::PARAM_INT);
        $stmt->bindParam(":key", $preferenceKey, PDO::PARAM_STR);
        $stmt->bindParam(":preference", $preference, PDO::PARAM_INT);

        if($stmt->execute()){
            return $stmt->rowCount() === 1;
        }
        return false;
    }

Bovenstaande tabel heeft in mysql op de user_id en de settings_id foreign keys staan naar de respectievelijke user & settings tabel.

Het gekke (en rare) is dus, als ik de code 3 of 4 x na elkaar aanroep, met $preferenceKey en de $preference anders, hij maar 1 waarde daadwerkelijk opslaat, terwijl de functie elke keer true returnt.

Op één of andere manier voert hij de queries dus met succes uit (want geen PDO exception, geen error code of error info, execute returnt true, rowcount is 1), maar slaat hij ze uiteindelijk niet op

Als ik de query met $stmt->queryString(); dump en dan manueel de parameters vervang & uitvoer in phpmyadmin, werkt het uiteraard.

Heeft er iemand een idee waar het aan kan liggen? Er is geen transaction bezig, geen statement errors dus, query succesvol uitgevoerd, 1 rij ingevoegd, ...

[NMe]

Calling PDO::prepare() and PDOStatement::execute() for statements that will be issued multiple times with different parameter values optimizes the performance of your application by allowing the driver to negotiate client and/or server side caching of the query plan and meta information

Misschien dat er iets op een of andere ranzige manier fout gaat met caching? Kun je je variabelen (uiteraard alleen bij wijze van test) eens hard in je query afdrukken en de query daarna preparen/executen, kijken of dat verschil maakt?

[GlowMouse]

Kun je de db-server alle queries laten loggen, of een tcp-sniffer tussen de webserver en de dbserver inzetten?

[azerty]

NMe schreef op donderdag 25 februari 2016 @ 21:14:
[...]

Misschien dat er iets op een of andere ranzige manier fout gaat met caching? Kun je je variabelen (uiteraard alleen bij wijze van test) eens hard in je query afdrukken en de query daarna preparen/executen, kijken of dat verschil maakt?

Dat maakt helaas geen verschil

Heb de query aangepast (voorlopig, om te testen dus) naar het volgende:

PHP:

public function setPreferenceForUser(User $user, $preferenceKey, $preference)
    {
        $uid = $user->getId();
        $preference = $preference ? 1 : 0;

        $this->pdo->setAttribute(PDO::ATTR_ERRMODE, PDO::ERRMODE_EXCEPTION);
        $stmt = $this->pdo->prepare("INSERT INTO user_settings (user_id, settings_id, `value`) VALUES (".$uid.", (SELECT `id` FROM settings WHERE `key` = '".$preferenceKey."'), ".$preference.")");
        var_dump($stmt->queryString);

        if($stmt->execute()){
            return $stmt->rowCount() === 1;
        }
        return false;
    }

Dit levert het volgende op bij uitvoeren:

string(142) "INSERT INTO user_settings (user_id, settings_id, `value`) VALUES (159, (SELECT `id` FROM
settings WHERE `key` = 'test_setting'), 1)"
string(137) "INSERT INTO user_settings (user_id, settings_id, `value`) VALUES (159, (SELECT `id` FROM
settings WHERE `key` = 'test_setting1'), 1)"
string(141) "INSERT INTO user_settings (user_id, settings_id, `value`) VALUES (159, (SELECT `id` FROM
settings WHERE `key` = 'test_setting4'), 1)"

Zoals eerder vermeld, is het enkel de laatste (waar de key test_setting4 is) die daadwerkelijk opgeslagen wordt. Als ik enkel de eerste 2 doe, staat er niets in de user_settings tabel. De keys zijn nochtans allemaal in de settings tabel aanwezig (was het eerste wat ik uiteraard gecontroleerd had).

Heb nu ook per test de subquery in een IFNULL gewrapped, met een onmogelijke waarde daar, maar geen fouten... Dus de subquery lijkt goed te gaan.

Dit zijn trouwens de waardes in mijn 'settings' tabel (quick-n-dirty export als csv):

"id","key"
"1","test_setting"
"2","test_setting1"
"3","test_setting2"
"4","test_setting3"
"5","test_setting4"

---

GlowMouse schreef op donderdag 25 februari 2016 @ 21:22:
Kun je de db-server alle queries laten loggen, of een tcp-sniffer tussen de webserver en de dbserver inzetten?

Shared hosting pakket van PCExtreme, dus het 2e zeker niet. 1e zou ik waarschijnlijk na support aanvraag geregeld kunnen krijgen denk ik.

---

Edit:

Ook een transactie (inclusief commit) werkt niet

[mcDavid]

Lokaal gaat het wel goed?

[azerty]

mcDavid schreef op donderdag 25 februari 2016 @ 21:35:
Lokaal gaat het wel goed?

Hoezo lokaal?

* Als ik de query manueel in phpmyadmin uitvoer (met gelijk welke preferencekey), gaat het.
* Voer ik hem uit in de code met die ene specifieke preferencekey, werkt het ook.
* Voer ik hem uit in de code met gelijk welke andere preferencekey, geeft hij wel terug dat hij opslaat, maar werkt het dus niet.

[GlowMouse]

Welke storage engine gebruik je? Heb je ook een minimal working example van vijf regels code met twee queries?

[azerty]

GlowMouse schreef op donderdag 25 februari 2016 @ 21:39:
Welke storage engine gebruik je? Heb je ook een minimal working example van vijf regels code met twee queries?

Engine is InnoDB voor alle 3 de tabellen.

Minimal working sample? Dat is wat moeilijker gezien de complexere structuur... Maar goed, hier komt 'ie:

PHP:

class TestCase {
    protected $pdo;

    public function __construct(PDO $pdo)
    {
        $this->pdo = $pdo;
    }

public function setPreferenceForUser($uid, $preferenceKey, $preference)
    {
        $this->pdo->setAttribute(PDO::ATTR_ERRMODE, PDO::ERRMODE_EXCEPTION);
        $stmt = $this->pdo->prepare("INSERT INTO user_settings (user_id, settings_id, `value`) VALUES (:uid, (SELECT `id` FROM settings WHERE `key` = :key), :preference)");
        $stmt->bindParam(":uid", $uid, PDO::PARAM_INT);
        $stmt->bindParam(":key", $preferenceKey, PDO::PARAM_STR);
        $stmt->bindParam(":preference", $preference, PDO::PARAM_INT);

        $result = false;
        if($stmt->execute()){
            $result = $stmt->rowCount() === 1;
        }
        return $result;
    }
}

PHP:

$pdo = new PDO('mysql:dbname=;host=sql.pcextreme.nl','user','password');
$dbl = new TestCase($pdo);

$dbl->setPreferenceForUser(1, 'test_setting', 1);
$dbl->setPreferenceForUser(1, 'test_setting1', 1);
$dbl->setPreferenceForUser(1, 'test_setting4', 1);

En dan de database:

SQL:

CREATE TABLE IF NOT EXISTS `settings` (
  `id` int(2) NOT NULL AUTO_INCREMENT,
  `key` varchar(50) NOT NULL,
  PRIMARY KEY (`id`)
) ENGINE=InnoDB  DEFAULT CHARSET=latin1 AUTO_INCREMENT=6 ;

INSERT INTO `settings` (`id`, `key`) VALUES
(1, 'test_setting'),
(2, 'test_setting1'),
(3, 'test_setting2'),
(4, 'test_setting3'),
(5, 'test_setting4');

CREATE TABLE IF NOT EXISTS `user_settings` (
  `user_id` int(11) NOT NULL,
  `settings_id` int(2) NOT NULL,
  `value` tinyint(3) unsigned NOT NULL,
  PRIMARY KEY (`user_id`,`settings_id`),
  KEY `settings_id` (`settings_id`)
) ENGINE=InnoDB DEFAULT CHARSET=latin1;
ALTER TABLE `user_settings`
  ADD CONSTRAINT `user_settings_ibfk_2` FOREIGN KEY (`settings_id`) REFERENCES `settings` (`id`) ON DELETE CASCADE ON UPDATE CASCADE;

[GlowMouse]

Ik heb dit voorbeeld net gedraaid op servers van pcextreme (web09.vhosting.pcextreme.nl / sql3) en krijg gewoon drie entries in user_settings.

[Voutloos]

NMe schreef op donderdag 25 februari 2016 @ 21:14:
[...]

Misschien dat er iets op een of andere ranzige manier fout gaat met caching? Kun je je variabelen (uiteraard alleen bij wijze van test) eens hard in je query afdrukken en de query daarna preparen/executen, kijken of dat verschil maakt?

Die notitie legt het hele nut van prepare() uit? Ik denk dat je iets over query cache er in leest maar dat staat er dus totaal niet.

---

azerty schreef op donderdag 25 februari 2016 @ 21:53:
PRIMARY KEY (`user_id`,`settings_id`),

Je rows zijn niet unique voor de eerder ge-vardumpte queries. Nee, shit, die zijn met dubbele values ipv settings_id.

[ Voor 6% gewijzigd door Voutloos op 25-02-2016 22:12 ]

[azerty]

Voutloos schreef op donderdag 25 februari 2016 @ 22:07:
[...]

Je rows zijn niet unique.

Toch wel... 1,1 is toch unique t.o.v. 1,2 etc. ?

En in dat geval zou hij een fout moeten gooien, wat het geval ook niet is.

---

GlowMouse schreef op donderdag 25 februari 2016 @ 22:07:
Ik heb dit voorbeeld net gedraaid op servers van pcextreme (web09.vhosting.pcextreme.nl / sql3) en krijg gewoon drie entries in user_settings.

Had ik zien aankomen

nl04.pcextreme.nl & sql8 is het bij mij blijkbaar

[ Voor 7% gewijzigd door azerty op 25-02-2016 22:27 ]

[Voutloos]

En var_dump() van return value in je minimum testcase is echt 2x false?

[azerty]

Voutloos schreef op donderdag 25 februari 2016 @ 22:16:
En var_dump() van return value in je minimum testcase is echt 2x false?

Dat is het hem juist...

code:

$dbl->setPreferenceForUser(1, 'test_setting', 1);
$dbl->setPreferenceForUser(1, 'test_setting1', 1);
$dbl->setPreferenceForUser(1, 'test_setting4', 1);

3x true, enkel laatste (met preferenceKey 'test_setting4') staat in de db

code:

$dbl->setPreferenceForUser(1, 'test_setting', 1);
$dbl->setPreferenceForUser(1, 'test_setting1', 1);

2x true, niks in de tabel.

code:

$dbl->setPreferenceForUser(1, 'test_setting4', 1);

1x true, staat in db.

code:

$dbl->setPreferenceForUser(1, 'test_setting', 1);

1x true, niks in de databank.

[ Voor 13% gewijzigd door azerty op 25-02-2016 22:22 ]

[Voutloos]

Is die ene tabel wel leeg bij begin test? Wat gebeurt er als je express niet bestaande key gebruikt? Kijk je niet stiekem wie PhpMyAdmin of zo naar de verkeerde tabel, met een filterende query ingesteld, of meerdere pagina's?

[ Voor 6% gewijzigd door Voutloos op 25-02-2016 22:31 ]

[Depress]

Kloppen de waardes die van de Key die je mee geeft, dus de bij behorende records in de settings tabel? Wellicht een spatie of iets dergelijks wat per ongeluk ergens is beland?

[azerty]

Voutloos schreef op donderdag 25 februari 2016 @ 22:29:
Is die ene tabel wel leeg bij begin test? Wat gebeurt er als je express niet bestaande key gebruikt? Kijk je niet stiekem wie PhpMyAdmin of zo met een filterende query ingesteld of meerdere pagina's?

de user_settings tabel is quasi leeg (zeker met de user_id waar ik probeer mee te inserten).

Als ik de user id vastzet op 999 (bestaat niet):

Fatal error: Uncaught exception 'PDOException' with message 'SQLSTATE[23000]: Integrity constraint violation: 1452 Cannot add or update a child row: a foreign key constraint fails (`user_settings`,
CONSTRAINT `user_settings_ibfk_1` FOREIGN KEY (`user_id`) REFERENCES `user` (`id`) ON DELETE CASCADE ON UPDATE CASCADE)

Als ik de preferenceKey op 'lol' vastzet (bestaat niet in DB):

Fatal error: Uncaught exception 'PDOException' with message 'SQLSTATE[23000]: Integrity constraint violation: 1048 Column 'settings_id' cannot be null'

Lijkt me dus zijn werk te doen; Als ik het uitvoer met de live variabelen is er geen enkele fout.

En nee, geen filter... Standaard (SELECT * FROM user_settings) view, er zijn 14 rijen, en standaard toont hij de eerste 30, dus geen ontbrekende rijen ofzo.

---

Depress schreef op donderdag 25 februari 2016 @ 22:35:
Kloppen de waardes die van de Key die je mee geeft, dus de bij behorende records in de settings tabel? Wellicht een spatie of iets dergelijks wat per ongeluk ergens is beland?

Ik heb de waardes gedumpt, en die kloppen... Zoals gezegd, als ik ze er hard inzet (zoals gesuggereerd door NMe) en de gedumpte query in phpmyadmin uitvoer, werkt hij, voert PDO hem uit werkt het niet.

---

Edit:

Zojuist de ganse tabel weggeflikkerd en opnieuw aangemaakt, werkt het nog steeds niet

[ Voor 6% gewijzigd door azerty op 25-02-2016 23:00 ]

[DJMaze]

quote: http://php.net/manual/en/pdostatement.execute.php

Note:
Some drivers require to close cursor before executing next statement.

Lukt het daarmee wel?

[gekkie]

En how about ... expliciet printen van de return van $stmt->execute() ...
en er een try catch met print omheen zetten ...
Je weet maar nooit met PHP voodoo casting en eventueel een try catch in aanroepende code die zaken onder het tapijt veegt ?
Neem aan dat je connectie verder gewoon op autocommit staat ?
En werkt het wellicht wel als je de errors niet op exceptions zet ?

[ Voor 21% gewijzigd door gekkie op 25-02-2016 23:05 ]

[azerty]

DJMaze schreef op donderdag 25 februari 2016 @ 23:02:
[...]

Lukt het daarmee wel?

Helaas, $stmt->closeCursor() heeft ook geen enkel effect

---

gekkie schreef op donderdag 25 februari 2016 @ 23:02:
En how about ... expliciet printen van de return van $stmt->execute() ...
en er een try catch met print omheen zetten ...
Je weet maar nooit met PHP voodoo casting en eventueel een try catch in aanroepende code die zaken onder het tapijt veegt ?
Neem aan dat je connectie verder gewoon op autocommit staat ?

Expliciet printen levert altijd 'bool(true)' op.

En zoals gezegd, er is GEEN enkele fout (niet met de PDO exception, niet in $stmt->errorCode(), niet in $stmt->errorInfo()...

Autocommit is ingesteld, ja (var_dump($this->pdo->getAttribute(PDO::ATTR_AUTOCOMMIT)); => int(1) )

---

Edit:

ondertussen de subquery apart verplaatst (apart stmt), en die werkt:

int(1)
int(2)
int(3)
int(5)

En zelfs in dat geval voegt hij dus enkel de laatste in...

[ Voor 16% gewijzigd door azerty op 25-02-2016 23:13 ]

[gekkie]

azerty schreef op donderdag 25 februari 2016 @ 23:07:
[...]
Helaas, $stmt->closeCursor() heeft ook geen enkel effect

---

[...]
Expliciet printen levert altijd 'bool(true)' op.

En zoals gezegd, er is GEEN enkele fout (niet met de PDO exception, niet in $stmt->errorCode(), niet in $stmt->errorInfo()...

Autocommit is ingesteld, ja (var_dump($this->pdo->getAttribute(PDO::ATTR_AUTOCOMMIT)); => int(1) )

Wat is er verder nog te bedenken ... je tabel en query zo versimpelen dat het echt echt echt niet fout kan ... werkt het dan wel ?

Dus als je de constraints eens tijdelijk laat varen ... en het gewoon echt dom inserten laat zijn in 1 tabel ... werken die inserts dan wel via PDO ?

[azerty]

gekkie schreef op donderdag 25 februari 2016 @ 23:12:
[...]

Wat is er verder nog te bedenken ... je tabel en query zo versimpelen dat het echt echt echt niet fout kan ... werkt het dan wel ?

Dus als je de constraints eens tijdelijk laat varen ... en het gewoon echt dom inserten laat zijn in 1 tabel ... werken die inserts dan wel via PDO ?

De foreign keys gedropt, en zelfs dan werkt de insert niet

Meer basic dan dit kan ik de query toch niet krijgen?

SQL:

INSERT INTO user_settings (user_id, settings_id, `value`) VALUES (:uid, :sid, :preference)

Dus op dit moment heb ik bovenstaande SQL statement, geen constraints. De settings_id haal ik via een apart statement op, en dit is hetgeen ik verwacht.

Bij invoegen nog steeds hetzelfde verhaal: als de settings_id in de php code geen 5 is, werkt de insert niet, desondanks het feit dat er geen fouten zijn (geen exception, statement execute, statement rowcount 1 is).

[ Voor 23% gewijzigd door azerty op 25-02-2016 23:23 ]

[gekkie]

Vanwaar de quotes om 'value' eigenlijk ?
En die vage autoincrement die bij je tabel creation op id=6 begint .. en daarna insert je waarden id< 5 ?

En als je die settings_id niet ophaald maar er hardcoded als echte integer in zet ?
(zou toch geen voodoo string naar int cast gedoe zijn)

[ Voor 89% gewijzigd door gekkie op 25-02-2016 23:30 ]

[azerty]

gekkie schreef op donderdag 25 februari 2016 @ 23:26:
Vanwaar de quotes om 'value' eigenlijk ?
En die vage autoincrement die bij je tabel creation op id=6 begint .. en daarna insert je waarden id< 5 ?

Wanhoop

Als er geen logische stappen meer overschieten, probeer je dingen waarvan je weet dat ze toch niets uithalen

En uiteraard ook omdat het gereserveerd is...

Edit:

die auto-increment is omdat ik de tabel gedumpt heb... Niet van mijzelf, maar het maakt in mijn geval niks uit...

[ Voor 17% gewijzigd door azerty op 25-02-2016 23:31 ]

[CH4OS]

gekkie schreef op donderdag 25 februari 2016 @ 23:26:
Vanwaar de quotes om 'value' eigenlijk ?

Value is ook een functie of gereserveerde, door een backtick of single quote wordt het dan een string.

[ Voor 38% gewijzigd door CH4OS op 25-02-2016 23:30 ]

[gekkie]

CptChaos schreef op donderdag 25 februari 2016 @ 23:29:
[...]
Value is ook een functie of gereserveerde, door een backtick of single quote wordt het dan een string.

Ik snap .. wist niet dat het in mysql een functie en daarmee ook gereserveerd was
Postgres houdt zich niet aan de regels .. kennelijk kijkt de parser er daar ook nog even naar of het gebruikt wordt als functie()

[ Voor 15% gewijzigd door gekkie op 25-02-2016 23:36 ]

[gekkie]

azerty schreef op donderdag 25 februari 2016 @ 23:29:
[...]


Wanhoop

Als er geen logische stappen meer overschieten, probeer je dingen waarvan je weet dat ze toch niets uithalen

En uiteraard ook omdat het gereserveerd is...

Edit:

die auto-increment is omdat ik de tabel gedumpt heb... Niet van mijzelf, maar het maakt in mijn geval niks uit...

Dan hou ik over dat er bij pcexterme een lolbroek is die een trigger heeft geschreven die at random dingen naar /dev/null stuurt.

[azerty]

gekkie schreef op donderdag 25 februari 2016 @ 23:37:
[...]

Dan hou ik over dat er bij pcexterme een lolbroek is die een trigger heeft geschreven die at random dingen naar /dev/null stuurt.

Ik durf het al niet meer uitsluiten

Alhoewel het raar blijft dat het niet werkt bij een id <> 5, en bij id == 5 wel

[ Voor 12% gewijzigd door azerty op 25-02-2016 23:39 ]

[gekkie]

azerty schreef op donderdag 25 februari 2016 @ 23:39:
[...]


Ik durf het al niet meer uitsluiten

Alhoewel het raar blijft dat het niet werkt bij een id <> 5, en bij id == 5 wel

Mjah dat vindt ik dus ook .. vandaar dat ik op die auto increment .. eventueel in bizarre combi met string naar integer casting ergens kwam. En dacht als je dus een tabel .. zonder vage autoincrement .. zonder constraints .. gewoon echt simpeler dan simpel doet. Dat zou moeten werken .. en vervolgens vanaf daar weer gaan opbouwen met je fratsen

Maar gewoon met hardcoded integer als settings_id doet het dus ook nog niets ?

[ Voor 30% gewijzigd door gekkie op 25-02-2016 23:43 ]

[azerty]

gekkie schreef op donderdag 25 februari 2016 @ 23:41:
[...]

Mjah dat vindt ik dus ook ..
Maar gewoon met hardcoded integer als settings_id doet het dus ook nog niets ?

Zelfs hardcoded doet het niets tenzij de settings_id 5 is.

[gekkie]

azerty schreef op donderdag 25 februari 2016 @ 23:48:
[...]


Zelfs hardcoded doet het niets tenzij de settings_id 5 is.

Ook als je een tabel maakt zonder autoincrement of gewoon vanaf de defautl begint ?

Hmm en dan ben je nog niet eens bezig met dingen waarmee je in de rest van de valkuilen van PDO stapt ... je probeert niet meerdere parameters op naam te binden met 1 value .. je probeert niet later iets te comparen met je gebonden value wat nou ineens gecast is naar een string tijdens de executie.
Krijgt wel hoofdpijn van het lijstje met potentiele ellende te proberen te vergelijken met je queries

[azerty]

gekkie schreef op donderdag 25 februari 2016 @ 23:56:
[...]

Ook als je een tabel maakt zonder autoincrement of gewoon vanaf de defautl begint ?

Hmm en dan ben je nog niet eens bezig met dingen waarmee je in de rest van de valkuilen van PDO stapt ... je probeert niet meerdere parameters op naam te binden met 1 value .. je probeert niet later iets te comparen met je gebonden value wat nou ineens gecast is naar een string tijdens de executie.
Krijgt wel hoofdpijn van het lijstje met potentiele ellende te proberen te vergelijken met je queries

De tabel settings dus ook weggegooid, en de 6 settings manueel terug ingevoerd. Nog steeds hetzelfde probleem

Volgens mij heeft het niks te maken met de settings tabel, maar is er iets (grondig) mis met de user_settings tabel voor god weet welke reden.

[Orthodroom]

Waarom bind je die key als str en niet int?

[azerty]

Orthodroom schreef op vrijdag 26 februari 2016 @ 00:09:
Waarom bind je die key als str en niet int?

Omdat die key een string is? De subquery returnt het id, wat uiteraard een int is.

azerty schreef op donderdag 25 februari 2016 @ 21:53:

SQL:

CREATE TABLE IF NOT EXISTS `settings` (
  `id` int(2) NOT NULL AUTO_INCREMENT,
  `key` varchar(50) NOT NULL,
  PRIMARY KEY (`id`)
) ENGINE=InnoDB  DEFAULT CHARSET=latin1 AUTO_INCREMENT=6 ;

[ Voor 40% gewijzigd door azerty op 26-02-2016 00:13 ]

[gekkie]

azerty schreef op vrijdag 26 februari 2016 @ 00:07:
[...]


De tabel settings dus ook weggegooid, en de 6 settings manueel terug ingevoerd. Nog steeds hetzelfde probleem

Volgens mij heeft het niks te maken met de settings tabel, maar is er iets (grondig) mis met de user_settings tabel voor god weet welke reden.

Nieuwe DB maken .. en basic beginnen met alleen die user_settings tabel zonder fratsen en kijken of je met PDO een simpele query met bindparam erin krijgt ?

[azerty]

gekkie schreef op vrijdag 26 februari 2016 @ 00:12:
[...]

Nieuwe DB maken .. en basic beginnen met alleen die user_settings tabel zonder fratsen en kijken of je met PDO een simpele query met bindparam erin krijgt ?

Vraag ik morgen... Kan vanuit phpmyadmin met mijn rechten geen aanmaken

[mcDavid]

azerty schreef op vrijdag 26 februari 2016 @ 00:14:
[...]


Vraag ik morgen... Kan vanuit phpmyadmin met mijn rechten geen aanmaken

Kan meestal vanuit je adminpanel. Maar srsly je hebt toch wel ergens een test omgeving die je gewoon zelf kunt configureren? Zo moeilijk is het niet mariadb te installeren op je eigen PC hoor.

[azerty]

mcDavid schreef op vrijdag 26 februari 2016 @ 08:47:
[...]

Kan meestal vanuit je adminpanel. Maar srsly je hebt toch wel ergens een test omgeving die je gewoon zelf kunt configureren? Zo moeilijk is het niet mariadb te installeren op je eigen PC hoor.

Ik heb geen toegang tot dat adminpanel, want het is een hostingaccount van een vriend.

En uiteraard heb ik het lokaal getest, wat dacht je? De minimal testcase werkt ook gewoon lokaal, maar niet remote.

---

Update:

Nieuwe database: minimal sample werkt
Huidige database: minimal sample werkt niet...

Dus er moet ergens iets qua configuratie anders zijn ofzo

[ Voor 14% gewijzigd door azerty op 26-02-2016 09:38 ]

[gekkie]

Whoot .. toch een aardige suggestie dus.
Toevallig gekeken of je niet nog ergens een antieke trigger mee hebt genomen met het inladen van die DB van ergens anders ?
Die loopt dan vast buiten de fout context van je query .. maar kan de meuk potentieel wel omzeep helpen.

[ Voor 24% gewijzigd door gekkie op 26-02-2016 09:45 ]

[azerty]

gekkie schreef op vrijdag 26 februari 2016 @ 09:44:
Whoot .. toch een aardige suggestie dus.
Toevallig gekeken of je niet nog ergens een antieke trigger mee hebt genomen met het inladen van die DB van ergens anders ?

Er is 1 trigger, maar die is niet actief op de tabellen waar ik problemen mee heb. Wat ik wel zojuist gezien heb:



De vraag is nu hoe ik dat opgelost krijg

Tabel opnieuw aanmaken helpt niks wat dat betreft (zoals je kunt zien heb ik dat zojuist al geprobeerd, met exact dezelfde SQL code voor beide databases nu)

[gekkie]

Als ik kijk op http://stackoverflow.com/...dinality-in-mysql#2566248 zou dat alleen wat voor je planner moeten maken.
En die trigger zit ook in beide databases ?

En anders zou ik zeggen doe de fullblown handel in de nieuwe DB ... en kijk of je die ook over de zeik krijgt.
Zo ja .. dan zit het toch in de meuk die je er in laad ..

[ Voor 31% gewijzigd door gekkie op 26-02-2016 09:56 ]

[azerty]

gekkie schreef op vrijdag 26 februari 2016 @ 09:55:
Als ik kijk op http://stackoverflow.com/...dinality-in-mysql#2566248 zou dat alleen wat voor je planner moeten maken.
En die trigger zit ook in beide databases ?

Het viel me plots op... Ik heb totaal geen idee meer waar het te zoeken op dit moment.

Trigger zit uiteraard niet in de nieuwe DB, maar ik zie niet in hoe een trigger op een andere tabel deze tabel kan beïnvloeden?

[gekkie]

azerty schreef op vrijdag 26 februari 2016 @ 09:57:
[...]


Het viel me plots op... Ik heb totaal geen idee meer waar het te zoeken op dit moment.

Trigger zit uiteraard niet in de nieuwe DB, maar ik zie niet in hoe een trigger op een andere tabel deze tabel kan beïnvloeden?

Ik ook niet zo 123 .. maar je kunt hem eens droppen in je oude natuurlijk ... alles aan iets meer geavanceerde dingen zoals functies en triggers en weet ik het al wat niet meer nog kan in mysql.

Als het allemaal klopt wat je doet lijkt het me dus onwaarschijnlijk dat het een PDO only bug is.
Aangezien simpele queries het in de ene DB wel doen en de andere niet. En zoals gezegd .. lijkt een trigger me buiten de fout context van een query te vallen. Zou je dan wel in een mysql log moeten kunnen terug vinden .. maarja hosting .

Anders gewoon eens op een lokale mysql instance testen met die oude DB zodat je alles op full logging kan mikken ?

[Gomez12]

azerty schreef op vrijdag 26 februari 2016 @ 09:50:
[...]


Er is 1 trigger, maar die is niet actief op de tabellen waar ik problemen mee heb. Wat ik wel zojuist gezien heb:

Wie of wat heeft de database gemaakt?

Want 1 trigger vind ik over het algemeen verdacht, of iemand werkt met triggers en dan hangen er meerdere in de database (en wellicht andere dingen) of iemand werkt niet met triggers en dan hangen er 0 in de database.

Maar praktisch gezien zie ik bij serieuze projecten erg weinig dat er daadwerkelijk maar 1 trigger inzit en als ik het al zie dan is het over het algemeen een test-foutje of een overblijfseltje. En dan zou ik eens met de db-designer gaan praten over wat hij nog meer getest heeft en wat er nog meer kan zijn blijven hangen.

Maar anders zou ik als praktische probleemoplossing gewoon een backup van de db maken, die lokaal neerzetten en dan in de logs kijken.
Vind je dan nog niets, dan een export van de tabel-structuren etc maken (alles behalve data) en dan daarmee een nieuwe database opbouwen en kijken of het zich dan alsnog voordoet.
En anders gewoon tabel voor tabel de kopie opbouwen en kijken waar het fout gaat.

[azerty]

Gomez12 schreef op vrijdag 26 februari 2016 @ 10:04:
[...]

Wie of wat heeft de database gemaakt?

Want 1 trigger vind ik over het algemeen verdacht, of iemand werkt met triggers en dan hangen er meerdere in de database (en wellicht andere dingen) of iemand werkt niet met triggers en dan hangen er 0 in de database.

Maar praktisch gezien zie ik bij serieuze projecten erg weinig dat er daadwerkelijk maar 1 trigger inzit en als ik het al zie dan is het over het algemeen een test-foutje of een overblijfseltje. En dan zou ik eens met de db-designer gaan praten over wat hij nog meer getest heeft en wat er nog meer kan zijn blijven hangen.

Maar anders zou ik als praktische probleemoplossing gewoon een backup van de db maken, die lokaal neerzetten en dan in de logs kijken.
Vind je dan nog niets, dan een export van de tabel-structuren etc maken (alles behalve data) en dan daarmee een nieuwe database opbouwen en kijken of het zich dan alsnog voordoet.
En anders gewoon tabel voor tabel de kopie opbouwen en kijken waar het fout gaat.

Trigger is van mij om migratie tussen 2 tabellen te vergemakkelijken, en verdwijnt als de nieuwe versie van het project gereleased wordt.

Ga een volledige dump nu eens lokaal draaien.

---

Edit:

Lokale kopie werkt (inclusief de trigger)

Nu maar eens de dump van de oude restoren naar de nieuwe, en zien of het daar werkt Nee dus

---

In de kloon gaat het met een minimale setup (settings tabel, user tabel, user_settings tabel) ook al weer mis... Kijken of ik nog verder kan beperken dan maar -_-

[ Voor 10% gewijzigd door azerty op 26-02-2016 11:25 ]

[gekkie]

En al een oude man met grijze baard geworden ... kortom .. al iets wijzer ?

[DJMaze]

Oh wacht even.....

Hoe zit het met de charset en collation van alle tabellen en kolommen?
En met de charset van je verbinding?

[ Voor 17% gewijzigd door DJMaze op 02-03-2016 20:28 ]

[azerty]

gekkie schreef op woensdag 02 maart 2016 @ 13:49:
En al een oude man met grijze baard geworden ... kortom .. al iets wijzer ?

PEBKAC

Zoals gewoonte. Als je een insert uitvoert (waar ik dacht dat het probleem zat), en daarna een fout hebt in een delete statement wat verder in de code...

[gekkie]

Ah dus je zat zelf direct de meuk er weer uit te wissen hendig ... wel creatief dat het bij gevalletje 5 je delete dan niet doorging

[azerty]

gekkie schreef op woensdag 02 maart 2016 @ 21:24:
Ah dus je zat zelf direct de meuk er weer uit te wissen hendig ... wel creatief dat het bij gevalletje 5 je delete dan niet doorging

Was de laatste in de loop

Ging als volgt:

Element 1: invoegen
Element 2: invoegen
Element 3: alles wissen (ipv enkel dat ene element)
Element 4: alles wissen (ipv enkel dat ene element)
Element 5: invoegen

En als ik dus element 5 niet invoegde, ging het als volgt:

Element 1: invoegen
Element 2: invoegen
Element 3: alles wissen (ipv enkel dat ene element)
Element 4: alles wissen (ipv enkel dat ene element)
Element 5: alles wissen (ipv enkel dat ene element)

Het gedrag dat ik beschreef is daarmee dus volledig te verklaren

[gekkie]

Hmm hm .. en dat het met losse queries wel werkte