Met een connectiestring 2 (of meer) keren dezelfde database te doorlopen

Dit is mijn connectiestring waarmee in de database (een eerste maal) 'geselecteerd' wordt:

Dim Conn, rs, sql
Set Conn = Server.CreateObject("ADODB.Connection")
Conn.Open "DRIVER={Microsoft Access Driver (*.mdb)}; DBQ=" & Server.MapPath("adres.mdb")
Set rs = Server.CreateObject("ADODB.Recordset")
sql = "SELECT ABC18.* FROM …. ORDER BY JId ASC"
rs.Open sql, Conn
=> Hierna volgt een schermafdruk van de gegevens in tabelvorm.
rs.Close
Dit loopt goed - afdruk is OK - tot hier geen probleem.

Ik wens nu onder de eerste tabel een tweede 'tabel' af te drukken identiek aan de eerste maar met de gegevens uit een andere tabel XYZ - daartoe heb ik de selectiequery in deze 2de doorloop aangepast (velden etc zijn vormelijk gelijk) en kopieerde ik om te beginnen de connectiestring :

'Dim Conn, rs, sql
Set Conn = Server.CreateObject("ADODB.Connection")
Conn.Open "DRIVER={Microsoft Access Driver (*.mdb)}; DBQ=" & Server.MapPath("adres.mdb")
Set rs = Server.CreateObject("ADODB.Recordset")
sql = "SELECT XYZ18.* FROM …. ORDER BY JId ASC"
rs.Open sql, Conn
…
rs.Close

Ik krijg evenwel errormeldingen in de zin van : ADODB.Recordset error '800a0e7d'
The connection cannot be used to perform this operation. It is either closed or invalid in this context.

Ik ga ervan uit dat de gekopieerde connectiestring in deze nieuwe doorloop niet voldoet m.a.w. een conflict geeft met de eerste - de Dim-regel heb ik intussen al weggehaald (') na een eerdere error.
Welke regels in de 2de doorloop dienen eventueel nog aangepast te worden ?
Ik ben niet zo vertrouwd met het gebruik van connectiestrings.

Dank voor tips

Begin eens met je code in PHP of CODE tags te zetten, dan is die wat leesbaarder. Als je twee queries wilt draaien na elkaar, dan kun je daar best dezelfde connectie voor gebruiken, dus dan hoef je die a) niet nog een keer te declareren en b) niet nog een keer in te stellen. Dat heb je immers al een keer gedaan, en dat blijft werken tot je de procedure afsluit. Daarnaast vind ik je string een beetje onhandig neergezet, want wat doen die drie puntjes daar? En als je ze toch bij elkaar wilt hebben, waarom geen UNION gebruikt?


Of, als je toch twee keer een tabel wilt openen:

Dank Octafish voor de duidelijke voorstelling - ik merk dat de beoogde combinaties van connectionstrings gebaseerd zijn op een verschil in 'benamingen'.
Ben uiteraard met de 2de codemogelijkheid aan de slag gegaan maar na onderstaande aanpassingen krijg ik een error vanaf de 2de tabel (de eerste loopt perfect)

Dim Conn, rs1, rs2, sql1, sql2
Set Conn = Server.CreateObject("ADODB.Connection")
Conn.Open "DRIVER={Microsoft Access Driver (*.mdb)}; DBQ=" & Server.MapPath("adres.mdb")

Set rs1 = Server.CreateObject("ADODB.Recordset")
Set rs2 = Server.CreateObject("ADODB.Recordset")
sql1= "SELECT * FROM ABC18 ORDER BY JId ASC"
rs1.Open sql, Conn => heb dit gewijzigd (identieke namen) in rs1.Open sql1, Conn => tabel OK - geen errors

=> Hierna volgt een schermafdruk van de gegevens in tabelvorm.
sql2 = "SELECT * FROM XYZ18 ORDER BY JId ASC"
rs2.Open sql, Conn
=> heb dit dan ook consequent gewijzigd in rs2.Open sql2, Conn => geeft evenwel volgende error voor de 2de tabel
Microsoft OLE DB Provider for ODBC Drivers error '80040e10'
[Microsoft][ODBC Microsoft Access Driver] Too few parameters. Expected 1.

=> Hierna volgt een schermafdruk van de tweede tabel .
rs1.Close
rs2.Close

Welke ontbrekende parameter zou hier de de 2de run/tabel hinderen ?
Graag een tip.

Beste OctaFish, oorzaak van de 2de-tabel-error is onderschept : een foutief gebruikte veldnaam in de 2de select query - sorry dat ik dit niet eerder ontdekte.
Nogmaals dank voor de duidelijke voorstelling/aanbreng - de combinatie(s) zijn mij nu duidelijk en de codes draaien hetgeen ervan verwacht wordt.

De puntjes in mijn eerste bericht 'verwezen' naar de weggelaten codes van de select query die in dit connectieprobleem eerder niet belangrijk waren, vandaar.
Overigens had ik de vraag 'waarom geen union' enigszins verwacht. Ik heb dit probleem tot nog toe niet kunnen oplossen (cfr. mijn vraag/bericht van 29/04/2018 daaromtrent), vandaar de surrogaatoplossing in deze post die nu wél werkt.