Bon, alors, reprenons...
Dans "AjoutTheme" y'a quoi ? C'est une liste reçue via un formulaire ? Si oui, c'est mort, il faut passer par la boucle que tu as écrite.
Si c'est des informations issures d'une requête, alors tu peux faire ça :
Mettons que "AjoutTheme" soit allimentée par la requête :
"select id from theme"
A ce moment, tu peux faire ça :
INSERT INTO liens_themes (id_lien, id_theme) values(select "&new_id&", id from theme)"
Ceci dit je pense que c'est plutôt la première solution.
Si tu redoutes des données incohérentes, il te faut passer par une transaction afin de garantir que toutes les lignes seront créées, ou aucune :
listeIdTheme = Split(AjoutTheme,"," )
i=0
dim cnx
set cnx = Server.CreateOject("ADODB.Connection" )
cnx.Open MM_liens_gret_STRING
cnx.begintrans
on error resmue next
lastErr = 0
for i = lbound(listeIdTheme) to UBound(listeIdTheme)
SQL = "INSERT INTO liens_themes (id_lien, id_theme) values("&new_id&","&listeIdTheme(i)&" )"
cnx.Execute SQL
if err <> 0 then
lastError = err.number
exit for
end if
next
on error goto 0
if lastError <> 0 then
cnx.rollback
Resonse.Write "Une erreur s'est produite lors du traîtement de la requête " & SQL & "<br>Annulation de la transation en court et fin en urgence du traîtement."
cnx.Close
set cnx = Nothing
Response.End
else
cnx.committrans
end if
cnx.Close
set cnx = Nothing
PS: je sais plus si c'est .rollback ou .rollbacktrans
En tout ça, avec ce code (légèrement plus propre, t'as pas besoin d'instancier un RS pour faire un INSERT, et un While qui part de 0 avec une incrémentation manuelle quand on peut faire un for borné par les limites du tableau c'est pas terrible ) te permettre d'insérer les lignes d'un coup et de garantir qu'elles sont toutes insérées ou toutes annulées en cas d'erreur. En plus de ça, si une personne tente de lire la table pendant l'insertion des données, sa requête sera mise en file d'attente jusqu'à la fin de la boucle, afin d'assurer la lecture de toutes ou aucune données insérée, afin d'être certain de ne pas afficher n'importe quoi.
PS²: Les transactions c'est un outils extrêment puissant qui permet de garantir à tout instant une version "propre" de la base. Par contre, c'est êtrêment consommateur, et peut sérieusement ralentir une application partagée, à cause de la présence de lock en écriture ET en lecture sur l'intégralité des données (ou tables avec certains SGBD tels que SQL Server) pendant toute la durée de la transaction.
Message édité par Arjuna le 05-07-2004 à 22:39:30