Ik begrijp niet waar dit fout gaat.

Oeps! Sorry!

Ach, toch gevonden.
Het lag aan een extra test-aanroep die ik over het hoofd gezien had.



Misschien is het voor de liefhebbers wel handig om te vertellen wat er aan de hand was?
ja ben ook nieuwsgierig
Ja, jullie hebben gelijk.
(Ik wilde het bericht wissen maar dat ging niet.)

aLijst wordt uit een db opgehaald, op- of aflopend


 function __construct($status = '9', $volgorde = 'asc', $begin = '-', $eind = 'z') {
        $this->fillLetters();
        $eind = $eind . 'zzzz';
        $q = " select * from lemmaas where lemma >= '$begin' and lemma <= '$eind' ";
        if ($status < '9')
            $q = $q . " and status='$status' ";
        if ($volgorde == 'asc')
            $q = $q . " order by lemma asc ";
        else
            $q = $q . " order by lemma desc ";
        $db = openDB('otn');
        $p = $db->query($q);
        while ($row = $p->fetch_array()) {
// deze dus
            $this->aLijst[] = array($row[0], $row[1], $row[2]);
        }
        $db->close();
    }


Vervolgens wordt aLijst gebruikt om meerdere gegevens uit andere bronnen op te halen.
en omdat aLijst als 'foreach loop' gebruikt wordt zou die volgorde ook in aAlleRecodrs gehandhaafd worden.
Dat bleek niet zo te zijn.



 private function alleRecords() {
        $db = openDB('otn');
//aLijst staat in de juiste volgorde
        foreach ($this->aLijst as $aLemma):
            $lid = $aLemma[0];
            $aVarianten = array();
            $p = $db->query(" select * from varianten where lid='$lid' order by volgnr ");
            while ($row = $p->fetch_array())
                $aVarianten[] = $row;
            $aVervangers = array();
            $p = $db->query(" select * from vervangers  where lid='$lid' order by vervanger ");
            while ($row = $p->fetch_array())
                $aVervangers[] = $row;
// dan zou dit toch ook dezelfde volgorde moeten hebben?
            $this->aAlleRecords[] = [$aLemma, $aVarianten, $aVervangers];
        endforeach;
        $db->close();
    }


Tot mijn stomme verbazing gaf deze hulpfunctie de omgekeerde volgorde!


 public function printBoeklijst() {
        $this->alleRecords();
// verkeerde volgorde
        foreach ($this->aAlleRecords as $aR)
            print "<br/>" . $aR[0][1];
        $this->boekLijst();
// dus deze ook
        foreach ($this->aBoekRegels as $r)
            print "<br/>$r";
    }



Denkend ergens iets over het hoofd te hebben gezien of een eigenaardigheid van PHP niet te kennen, besloot ik ten einde raad dit forum te bevragen.
En terwijl ik na het posten de testcode die deze classLemmaLijst gebruikt opschoon en naloop, zie ik dat er na de 'actieve' test-variabele (instantie, object?) achteraan nog een vergeten aanroep staat. Dus:
1. Ik test aLijst bewust en correct.
2. Ik test onbewust aAlleRecords via een andere aanroep.

Zoiets heb ik ook al eens met css gehad. Dat ik me tot gekwordens toe afvraag wat er verkeerd gaat, en dan pas later zie dat ná mijn inspanning dezelfde selector nog en keer voorkomt....

Ja lach maar. Wees maar blij dat jullie die zeer zeldzame aandoening niet hebben. :-)


Toch grappig, open je serieus in elke functieaanroep een nieuwe databaseverbinding? Daar zou ik als ik jou was vooral ook eens naar kijken.
Nee, niet in elke functieaanroep.
Alleen op het moment dat er db-contact nodig is.
Dus zo kort mogelijk een open db-verbinding.
Vaak is die dan wel elegant in een functie onder te brengen

if (isLemma('dittum')) [then] doe-iets..
Waarbij in function isLemma() een db-contact nodig is.

Is dat niet goed?
Vertel me aub waarom niet en vooral hoe dan beter kan.

p.s. De voorbeelden zijn de enige twee functies uit een grote class die db-contact hebben en worden onafhankelijk van elkaar aangeroepen en uitgevoerd. Ze bouwen/vullen verschillende datastructuren op. Daarom zijn ze hier opgenomen.

Alvast dank!
De connectie kan je prima een enkele maal aanmaken in de constructor, en koppelen aan een this-> verwijzing.
Dan hoef je hem alleen maar bij in initiëren te gebruiken.
Dank Ariën.

Vroeger zei men:
1. Zo zuinig mogelijk met 'servertijd' want dat is duur en er zijn anderen die er ook gebruik van willen maken.
2. Hoe korter de verbindingstijd hoe minder risico op dataverminking/procesverstoring.

Ik heb weinig kijk op de moderne afwikkeling van connecties, in deze tijd van plenty...

Extreem enerzijds (zuinig) is mijn ouderwetse benadering van deze materie: zo kort mogelijk, dus vaak herhaald.
Extreem anderzijds (gemak) openen aan het begin van een sessie en sluiten als de sessie vernietigd wordt.
Daartussen vele verstandige mogelijkheden.

Om die goed af te wegen ontbreekt me de kennis van de afwikkeling.
Sta me toe dat ik daarom deze vragen opwerp:

1. Blijft in dat (jouw tip) geval de connectie open zolang de instantie bestaat?
2. Hoe wordt de connectie afgesloten?
3. Kan 'mijn' programma(-instantie) 'eindeloos' veel connecties openhouden
4. Hebben anderen gebruikers van het zelfde programma (i.c. dezelfde tabellen) er last van als ik een db/tabel openhoud?

Alvast dank!
Ik zou me geen zorgen maken over de connectie. Die maak je een enkele keer aan, en de resource daarvan kan je gebruiken in je constructors en instances van de classes.

Dit houdt dan in dat je connectie maar een enkele keer gebruikt wordt, maar je kan dan wel alle bijbehorende objecten aanroepen (in het geval van MySQLi). Ook het het procedurele MySQLi heeft de resources van je connectie nodig. Puur vanwege het feit dat hij weet welke verbinding hij moet gebruiken, gezien je ook meerdere connecties en dus resources kan gebruiken.

Tegenwoordig is een 'close' van je database niet nodig. Na de laatste query ruimt hij zijn rommel in het RAM weer netjes op. Hoewel het soms ook wel eens nuttig is om de rotzooi tussendoor op te ruimen, bij draken van queries.

>> 1. Zo zuinig mogelijk met 'servertijd' want dat is duur en er zijn anderen die er ook gebruik van willen maken.
>> 2. Hoe korter de verbindingstijd hoe minder risico op dataverminking/procesverstoring.
Op punt 1 kan ik heel kort zijn, het maken van een databaseverbinding kost onevenredig veel tijd, wat je dus servertijd kost, andere argumenten nog daargelaten. Op punt 2 geldt eigenlijk dat iemand dat uit zijn achterste heeft getrokken. Het hebben van een verbinding zorgt niet voor verminking van je data.

Om nu nog over te gaan op de overige 4 punten:
1. Ja, en dat is helemaal niet erg. Connecties blijven openen en sluiten binnen 1 script is funest voor je performance. Gebruik dus gewoon 1 databaseverbinding en geef die via parameters door aan de rest van je applicatie
2. Bij het eindigen van je script worden verbindingen gesloten
3. Nee, en dat is het probleem ook als je meerdere verbindingen maakt in je script.
4. Ja, maar dat moet ook juist, dit is 1 van de speerpunten voor het hebben van 1 verbinding. Je kunt dan je dataintegriteit garanderen met o.a. transacties. Wanneer je je verbinding constant sluit en opnieuw opent kan dit niet.

Dank Ariën!

Ik ga dat proberen.

p.s. "Tegenwoordig is een 'close' van je database niet nodig."
NetBeans geeft me telkens het advies de php sluittag ?> aan het eind van een script wegens overbodig weg te halen. Het doet mijn Pascalhart pijn....




Reageren