Discussion :

[Polack77]

Bonjour,

J'ai un petit souci (probablement de conception, même si dans le font ça me plaisais bien à moi ^^).

Je cherche à créer une table temporaire "connexion".

Mon objectif était de :
- exécuter une procédure stockée d'initialisation / création de cette table "temporaire".
- Modifier les données importées depuis une interface toute simple (en gros des champs texte, numérique, boolean, .... dans un grid-view en read/write).
- À la validation de la fenêtre, appeler une autre procédure stockée qui validera les modifications faites et sauvegardera les données.

Sauf que ça marche pas...

J'utilise (je voudrais utiliser vue que ça marche pas) une table temporaire session "CREATE TABLE #Tmp MaTable ..." sauf qu'une fois la procédure de création / initialisation terminée, la table est détruite (comme si j'utilisais une table variable en fait "DECLARE @VarTbl_MaTable TABLE ...", pas identique non plus bien sûr j'ai fait des tests, mais dans la situation ça réagit un peu pareil q mm).

Ma question est donc, existe-t-il une solution simple à mon problème (autre de créer une vraie table ou un temporaire global) ?

Sachant que :
- Plusieurs connexions simultanées seront faites (donc table temp global "CREATE TABLE ##Tmp MaTable ..." vas nécessité de je prenne en charge la connexion).
- je voudrais voir cette table être drop toute seule à la fermeture de la connexion (si ce n'est pas fait proprement suite à un crash du client par exemple).
- je voudrais une étape de validation des modifications (c'est-à-dire cliquer sur OK avant de faire toute modification en base, donc une vue "WITH SCHEMABINDING" et des TRIGGERS n'est pas bon non plus)

Bref je sais pas quoi utiliser et je cherche un conseil

Merci d'avance

[aieeeuuuuu]

Bonjour,

Une table temporaire est automatiquement détruite à la fin de la connexion ou de la procédure stockée qui l'a créée.
Il faudrait donc créer cette table en dehors de la procédure stockée.

Cependant, pourquoi ne pas simplement stocker les informations coté client et les envoyer à la procédure stockée finale de mise à jour ?

[Polack77]

Bonjour,

Déjà merci de ta réponse (et désolé de ne répondre que aujourd'hui hier après-midi j'étais débordé).

Et oui, la table temporaire est détruite à la fin de la proc, j'avais lu msdn, et c'est bien mon problème ^^ .

Je ne pensais pas stocker les informations coté client car la gestion du cash dans l'appli que je modifie n'est pas ... très stable ... du coup je veux les limiter au maximum (j'aurais dû en parler).

Bon... bah il me reste plus qu'a me tourner vers une table physique/temporaire globale je pense .

Merci quand même

PS :
Si quelqu'un a une solution magique SURTOUT qu'il n’hésite pas à partager son pouvoir

[aieeeuuuuu]

Bon... bah il me reste plus qu'a me tourner vers une table physique/temporaire globale je pense .

ou simplement créer votre table temporaire directement, sans passer par un procédure stockée.

[StringBuilder]

ou simplement créer votre table temporaire directement, sans passer par un procédure stockée.

Attention quand même car si on exploite correctement le pooling de connexion, on est sensé ouvrir et fermer la connexion à la base de données entre chaque traitement (en gros, dans une application, on ouvre la connexion au moment où on charge l'écran, puis on la ferme quand on a toutes les données à l'écran, et on rouvre une connexion quand l'utliisateur clique sur "enregistrer" par exemple, pour relancer des traitements).
Le pooling côté ADO et SGBD se charge de fermer ou non la connexion (en fonction de la charge du serveur).

Donc tout ce qui est objet de session, peut potentiellement être détruit à chaque fois.
Si on détourne le pooling, arrivé à 50 connexion concurrentes, on fout le serveur à genoux même si tout le monde est en pause café/croissant.
Un peu comme les veux logiciels qui font un lock exclusif sur les données chargées à l'écran : un couillon ouvre la fiche d'un dépôt et part en pause clope, et y'a tout le dépôt qui arrête de travailler... (expérience qui parle)

[Polack77]

Hmmmmm si je comprends bien StringBuilder il y a un risque que ma connexion soit fermée puis rouverte par ADO (j’exploite des objets ADO).
Donc potentiellement un comportement différent entre ma dév (où le serveur n'est pas très chargé) et la prod (où le serveur l'est BEAUCOUP plus)...

Bon rien que pour ça, je pense que je vais me détourner des tables temporaires sur ce coup (je les utiliserais quand elles seront vraiment appropriées).

Merci à tous pour vos lumières

[SQLpro]

Si on détourne le pooling, arrivé à 50 connexion concurrentes, on fout le serveur à genoux même si tout le monde est en pause café/croissant.

Bof bof... J'ai des clients qui ont 8 serveurs JBoss ouvert en permanence et connecté à raison de 100 connexion simultanées soit 800 connexion ouvertes... tant que ça fait rien, c'est pas bien grave !

A +