lurig loop i loop

' ## LOOP THRUOGH TITLES
SQL1 = "SELECT [x_ID], [x_name] FROM [agenda_titles] WHERE [x_view] = TRUE ORDER BY [x_sortfield];"
set mySQL1 = Conn.Execute(SQL1)
on error resume next

DO UNTIL mySQL1.EOF
' ## SELECT TITLE ID
my_titleID = CInt(mySQL1("x_ID"))
' ## PRINT TITLE NAME + TITLE ID
response.write mySQL1("x_name") & " ID:" & mySQL1("x_ID")

' ## LOOP THROUGH POSTS PER TITLE
SQL = "SELECT [x_text] FROM [agenda_notes] WHERE [x_titleID] = " & my_titleID & ";"
response.write SQL
set mySQL = Conn.Execute(SQL)
on error resume next

DO UNTIL mySQL.EOF
-- ' ## PRINT POSTS PER TITLE
-- x_text = mySQL("x_text")
-- response.write x_text
-- response.write mySQL("x_text")
x_text = ""
mySQL.MoveNext
LOOP

response.write "<BR>"
mySQL1.MoveNext
LOOP

Jag gör en almanacka där det finns olika rubriker, 8:00, 9:00, 10:00 osv. Till varje rubrik finns texten som man skriver in i agendan. Givetvis finns det datum med i bilden också men ovanstående är endast vital utvecklingskod.

Jag har testat massor av varianter av ovanstående med den genemsamma nämnaren att det inte fungerar. Looparna fungerar bra var för sig, men inte tillsammans.

Ser ni någon uppenbar miss, please let me know!

------------------
"Never underestimate your opponents." - Name the movie.

ser inte direkt vad felet är.

skulle det inte funka att plocka ut all information med en left join i SQL1 och på det viset slippa skapandet av nya recordsets hela tiden inne i loop så att säga. Det tar kraft från servern och segar ned sidan rejält att ha det som du nu har det.

testa denna sql sats och fimpa den inre loopen:

' ## LOOP THRUOGH TITLES
SQL1 = "SELECT at.[x_ID], at.[x_name], " & _
	"an.[x_text] " & _
	"FROM [agenda_titles] As at " & _
	"LEFT JOIN [agenda_notes] As an " & _
	"ON an.[x_titleID] = at.[x_ID] " & _
	"WHERE at.[x_view] = TRUE " & _
	"ORDER BY at.[x_sortfield];"

kan ju inte testa den ... men blir det någe fel så e det ju bara att posta igen =P

cya,
PatrikB

------------------
*Det tar sig sa han som hade eld i håret*

"ser inte direkt vad felet är."
- He... det kan bero på att det inte är något fel! :-)

Fan, värsta amatörtabben!!! x_titleID var av typen text i stället för tal och det tog mig två dagar att komma på...

---
Tack för ditt kodtips. I just detta sammanhanget är det massa tabeller och annat som ska skrivas till skärmen så jag tror inte JOIN passar. Men i en AvantGo variant kanske det skulle passa bättre.

Jag har för övrigt inte riktigt kommit till JOIN i min SQL bok.

Vad gäller hastigheten är det helt okej, vi har snabba grejer. Jag värdesätter mer kod och där med bättre dokumenterad före slimmad, odokumentera kod.

Det är iofs en smaksak men jag brukar tacka mig själv för de extra raderna när jag scrollar igenom avslutade projekt och fortfarande fattar vad som händer.

------------------
"Never underestimate your opponents." - Name the movie.

Finns ju inget mer frustrerande än tabbar av det slaget, vet av egna erfarenheter själv hur det är...

------------------
http://www.hutters.net

he, he ... ja, den tabben känner man ju igen *ler*

Vad gäller hastigheten är det helt okej, vi har snabba grejer. Jag värdesätter mer kod och där med bättre dokumenterad före slimmad, odokumentera kod

Även fast du slimmar koden kan du ju fortfarande skriva in förklaringar och få en självdokumenterad kod och därmed en bättre applikation.

Tycker inte att det är berättigat, spelar ingen roll vilken hårdvara man kör med, att EN användare ska lägga beslag på SÅ!! mycket maskinkraft för att hämta ut lite info från db som det gör när man lägger skapandet av nya recordsets inne i en loop.
Även om det endast är en användare som kör på ett intranet med 100 mb nät så kommer du att se en jäkla skillnad om du endast använder dig av ett enda recordset, eller 2 st och hämta med metoden GetRows.

cya,
PatrikB

------------------
*Det tar sig sa han som hade eld i håret*

Tack för getRows! Jo, det känns bekant. Ska kolla det.

Jag håller med dig, man ska inte köpa sunkiga lösningar.

------------------
"Never underestimate your opponents." - Name the movie.