join via PHP anzichè SQL

[lordzoster]

Ciao
sto usando questa soluzione per effettuare delle self join
con una query recupero l'elenco completo usato come chiave primaria
rs1=select distinct pk from table
con un'altra seleziono i dati aggregati che mi interessano
rs2,3,4=select pk, count(*) as conteggio from table where criterio

poi attraverso il recordset rs1

while (!rs1->EOF) {
  echo rs1[pk]
  se rs1[pk] = rs2[pk] {
    echo rs2[conteggio]
    rs2->MoveNext();
  } //e lo stesso per rs3 e rs4
}

risultato

rs1  rs2  rs3  rs4
001  33    41 
002   6         12
003        55   22

Il problema è che arrivato ad un certo punto (record 980 su 5969) rs1 continua tranquillamente e rs2,rs3,rs4 si fermano inspiegabilmente.
Any idea?

[Darkhorizont]

Perchè
rs2->MoveNext() ????

[lordzoster]

perchè altrimenti al successivo confronto avrei sempre lo stesso record:
rs2 ha struttura pk|valore, e non tutti i record di rs1 sono in rs2, ovvero in rs2 manacano alcuni valori pk che invece sono presenti in rs1.
Considera che il ciclo while attraversa solo rs1, gli altri rs vanno attraversati a mano.

[Darkhorizont]

Quanto ti danno rs1->numRows() rs2->numRows() rs3->numRows() e rs4->numRows()?

[lordzoster]

recordCOunt() = -1 ma è probabilmente collegato al fatto che $ADODB_COUNTRECS è false (solo che qs variabile compare in un sacco di posti e non so quale mettere true)

Ho visto che ADOdb implementa anche dei metodi per delle join via PHP, mò ne provo

[lordzoster]

gnente da fà
qualche idea?

[lordzoster]

il confronto dev'essere case-sensitive (es. strtoupper)

Qualcuno dirà: ma se stavi confrontando dati uguali della stessa colonna?
Invece no: erano dati inseriti da più utenti, alcuni con iniziali maiuscole, altri tutti minuscolo ecc.
Per cui a seconda del tipo di raggruppamento (Es. rs1 usava un DISTINCT, rs2-3-4 un GROUP per necessità pratiche) il valore di pk era effettivamente diverso.
CIAO!

P.S.: oltretutto mi sono accorto di aver fatto un po' di confusione fra PHP-ODBC e ADODb.. alla fine ho ripulito tutto e optato per un bel ADODb DSN-Less con OLEDB (praticamente l'interfaccia nativa per Access). Adesso ci mette meno di 500msec, mentre prima ci metteva 6,5sec per 6000 record