Discussion :

[Pol63]

bonjour

(code simplifié pour mettre en évidence le problème)

dans une même connexion, j'exécute 2 requêtes, la première créé une table temporaire #
la 2ème lit cette même table #
(tant que la connexion à sql server n'est pas fermée, une table temporaire reste accessible, enfin en théorie)

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
 
Dim co As New System.Data.SqlClient.SqlConnection
co.ConnectionString = "ma chaine de connexion"
co.Open()
 
Dim cmd As New System.Data.SqlClient.SqlCommand
cmd.Connection = co
 
cmd.Parameters.Add("@test", SqlDbType.BigInt).Value = 1   ' ajout d'un parameter
 
cmd.CommandText = "CREATE TABLE #TOTO (a int)"
cmd.ExecuteNonQuery()
 
cmd.CommandText = "SELECT * FROM #TOTO"
cmd.ExecuteReader()

si je n'ajoute pas de parameter aucun soucis


par contre si j'ajoute un parameter à mon sqlcommand, l'executenonquery passe et l'executereader plante

SQL Exception : nom d'objet #TOTO non valide

je ne comprends pas en quoi ca plante, je pencherais même pour un bug du framework, je ne vois pas pourquoi à cause d'un parameter ma table # serait supprimée !?

si quelqu'un peut m'expliquer pourquoi ce comportement je suis preneur

merci

[Geo2A]

Bonjour,

Je n'aurai pas la prétention de vous expliquer, trop novice sur SQL Server.

Néanmoins, je ne comprends pas votre code, à quoi sert le paramètre ? Il intervient dans une clause WHERE de votre SELECT * #TOTO que vous n'avez pas mentionné en simplifiant votre code ?

Si c'est le cas, le fait d'affecter le paramètre après la création de la table ne change t-il pas qq chose ?

D'autre part en consultant la doc sur le CREATE TABLE de System.Data.SqlClient :
il y a 3 tonnes de doc où l'on parle entre autre de nom de table temporaire qui passe hors de portée, y a t-il qq chose à chercher en ce sens ?

[Pol63]

(code simplifié pour mettre en évidence le problème)

mon code au final est plus complexe certes
ce code ne sert à rien, il sert à juste à pointer le problème
il y a surement une raison logique, le framework doit être peu buggé, mais je ne vois pas laquelle ...

je veux bien le liens dont tu parles, mais en théorie ma table devrait encore être accessible, d'ailleurs sans paramètre elle l'est encore !

[Geo2A]

Bonjour,

Je me suis mal exprimé, j'avais bien lu votre remarque sur la simplification, c'était juste pour savoir sur quoi portait le paramètre.

Pour le lien, la aussi j'ai écris un peu vite c'est pas System.data.sqlclient, mais la doc Transact-SQL

http://technet.microsoft.com/fr-fr/l...9(SQL.90).aspx

[Pol63]

pour la petite histoire c'est un composant qui ne connait pas à l'avance la requete, qui peut comporter des paramètres
je modifie la requete de base pour y ajouter une jointure sur une table temporaire, que je créé et rempli


concertant la portée des tables # oui j'étais bien au courant de ce que dit msdn
m'enfin ici il n'y a pas de fermeture de connexion

[Geo2A]

Bonsoir

Ce qui m'a fait réagir dans le lien MS technet

# Une table temporaire locale créée dans une procédure stockée est supprimée automatiquement lorsque la procédure stockée est terminée. La table peut être référencée par des procédures stockées imbriquées exécutées par la procédure stockée qui a créé la table. La table ne peut pas être référencée par le processus qui a appelé la procédure stockée ayant créé la table.
# Toutes les autres tables temporaires locales sont supprimées automatiquement à la fin de la session en cours.
# Les tables temporaires globales sont supprimées automatiquement lorsque la session qui a créé la table se termine, et que toutes les autres tâches n'y font plus référence. L'association entre une tâche et une table n'est assurée que pendant la durée d'une seule instruction Transact-SQL. Cela signifie qu'une table temporaire globale est supprimée à la fin de la dernière instruction Transact-SQL qui faisait activement référence à la table lorsque la session de création s'est terminée.

Comment fonctionne réellement le connecteur provider ADO.Net pour SQL ?
Se trouve t-on réellement dans le cas #2 ?

[Pol63]

oui
sqlconnexion.open démarre la session
sqlconnexion.close la ferme
toutes les requetes exécutées tant que la connexion n'est pas fermée sont dans la même session