[PHP/SQLite]

[Verwijderd]

Hallo,

Ik gebruik een sqlite3 database die dus aangeroepen moet worden met PDO functies. De SELECT statements werken gewoon, maar de insert/update statements niet. Het bestand heeft schrijfrechten, dus daar ligt het niet aan. Wanneer ik deze code heb krijg ik als output alleen het woord "Array" en wanneer ik de regel met het update statement weglaat dan krijg ik gewoon netjes een lijstje met dingen uit die database zoals het hoort.. iemand een idee? Ook de exec, prepare en al dat soort functies werken tot nog toe niet. Zit er al 3 dagen op te zoeken..

code:

<?php

    try 
    {
        $dbh = new PDO('sqlite:/var/www/test/trac.db');
    }
    catch (PDOException $e) 
    {
        echo $e->getMessage();
    }

    // Execute the query to get the usernames and actions
    $dbh->query("UPDATE permission SET action='actie' WHERE username='blabla'") or die($dbh->errorInfo());
    $results = $dbh->query("SELECT username, action FROM permission");

    while ($row = $results->Fetch(PDO::FETCH_ASSOC))
    {            
        echo "".$row['username']." ".$row['action']."<br>";
    }
                
?>

[ Voor 3% gewijzigd door Verwijderd op 08-09-2009 11:23 ]

[JeRa]

Je doet dan ook een die() op een array. Een PHP array omzetten naar een string levert het woord 'Array' op. Beter doe je zoiets:

PHP:

<?php

if (!$dbh->exec('...')) {
    print_r($dbh->errorInfo());
    exit();
}

?>

[ Voor 3% gewijzigd door JeRa op 08-09-2009 11:31 . Reden: voor een UPDATE is ::exec() natuurlijk ook geschikter... ]

[djluc]

print_r($row) om te debuggen?

[JeRa]

djluc schreef op dinsdag 08 september 2009 @ 11:26:
print_r($row) om te debuggen?

Dat levert toch geen informatie op over de update fout?

[ Voor 15% gewijzigd door JeRa op 08-09-2009 11:28 ]

[Creepy]

$dbh->errorInfo() is dan ook een array. Misschien handig om eerst de documentatie eens te lezen van de functies die je gebruikt.

Lees http://nl3.php.net/manual/en/pdo.errorinfo.php eens door. Daarin staat precies uitgelegd hoe je de daadwerkleijk foutmelding tevoorschijn kan halen. Daar ben je echt geen drie dagen aan bezig

[ Voor 8% gewijzigd door Creepy op 08-09-2009 11:29 ]

[curry684]

Ik denk dat het al enorm zou schelen als je even de documentatie van errorInfo zou lezen.

edit:
* curry684 mept Creepy maar weer eens

[ Voor 17% gewijzigd door curry684 op 08-09-2009 11:28 ]

[Verwijderd]

JeRa:
ik heb je raad opgevolgd en krijg nu hetvolgende: Array ( [0] => HY000 [1] => 14 [2] => unable to open database file )

Maar dat is vreemd, want met een select statement kan hij hem wel openen en met update niet?

[JeRa]

Verwijderd schreef op dinsdag 08 september 2009 @ 11:29:
JeRa:
ik heb je raad opgevolgd en krijg nu hetvolgende: Array ( \[0] => HY000 \[1] => 14 \[2] => unable to open database file )

Maar dat is vreemd, want met een select statement kan hij hem wel openen en met update niet?

Heb je schrijfrechten op het bestand?

[Hipska]

read-only permissies?

[curry684]

Heeft de account waaronder PHP cq. Apache draait ook schrijfrechten?

edit:
ik ga wel weer slapen of zo

[ Voor 28% gewijzigd door curry684 op 08-09-2009 11:33 ]

[Creepy]

offtopic:
* Creepy mept curry wakker

[djluc]

JeRa schreef op dinsdag 08 september 2009 @ 11:27:
[...]

Dat levert toch geen informatie op over de update fout?

Ik bedoelde uiteraard die error var., nu weetie tenminste wát er fout gaat.

[Verwijderd]

De fileowner is veranderd naar www-data wat eerst webuser was maar nog steeds dezelfde foutmelding..

[JeRa]

Verwijderd schreef op dinsdag 08 september 2009 @ 11:41:
De fileowner is veranderd naar www-data wat eerst webuser was maar nog steeds dezelfde foutmelding..

De owner heeft niet direct schrijfrechten als dat niet ingesteld is. Doe eens dit:

code:

chmod u+w /var/www/test/trac.db

[Verwijderd]

Gedaan, nog steeds geen resultaat

[JeRa]

Verwijderd schreef op dinsdag 08 september 2009 @ 11:46:
Gedaan, nog steeds geen resultaat

Apache/PHP draait ook daadwerkelijk onder www-data en niet onder webuser?

[Verwijderd]

webuser is de ftp user account, www-data is de user waar apache mee opgestart wordt..

[Creepy]

Oftewel: controleer eens onder welke user de webserver draait en controleer de rechten en owner van het bestand dat je probeert te openen. Ga dan zelf proberen op te zoeken hoe je dat recht kan trekken en pas als dat niet lukt: laat het weten en geef aan wat je zelf hebt geprobeerd Nu begint het topic nogal te neigen naar een "hou-m'n-handje-vast" topic.

[!null]

Ik zeg, chmod 777 als je het niet goed weet. Dan kun je snel zien of het werkt (of het dus aan de rechten ligt) en daarna weer terug naar de originele rechten en precies uitzoeken.
Maar alles wijst erop dat het de schrijfrechten zijn.

[Verwijderd]

Ik ga zelf nog wel even op onderzoek uit, tnx anyway
EDIT: Had dat laatste bericht nog niet gezien, maar de chmod staat nu op 777 hoor, alleen doet nog steeds niets

[ Voor 51% gewijzigd door Verwijderd op 08-09-2009 11:55 ]

[smesjz]

Je kan ook nog is_writable() doen. Maar misschien is het probleem wel dat jouw PHP versie een oude sqlite versie gebruikt en de database van Trac met een nieuwere sqlite versie is gemaakt.

Werkt het vanaf de commandline wel goed?

Als het een rechten kwestie is, zou ook Trac niet goed hebben gewerkt. Is dat het geval geweest?

[curry684]

Als safe mode aanstaat en die site niet vanuit /var/www/test draait heb je ook een probleem overigens.

Hoe dan ook zit je nu ergens in de regionen dat je met errorlogs aan de gang zal moeten want je zit nu met een omgevingsspecifiek probleem - de code klopt nu dus is het iets met je server.

[!null]

Verwijderd schreef op dinsdag 08 september 2009 @ 11:54:
Ik ga zelf nog wel even op onderzoek uit, tnx anyway
EDIT: Had dat laatste bericht nog niet gezien, maar de chmod staat nu op 777 hoor, alleen doet nog steeds niets

Ok, ga je de rechten wel weer terugzetten? (of weet je iig wat 777 voor foute boel inhoudt )