Discussion :

[PMAR]

Bonjour,

D'abord la description initiale de mon contexte et de mes besoins.
Je fais une migration d'une appli "full Access 2007" pour stocker les données dans SQLServer 2005.
Les tables 'normales' sont donc migrées. Il me reste à traiter le cas des tables temporaires. Elles sont actuellement stockées dans les bases de code. De fait, chaque utilisateur a ainsi sa propre copie de cette table et cela permet d'isoler les données.
Beaucoup de formulaires, de requêtes, d'états utilisent ces tables temporaires et on me demande de trouver une solution qui fonctionne avec SQLServer 2005 et qui NE NÉCESSITE PAS D'INTERVENIR SUR LE CODE EXISTANT.

J'ai donc imaginé la soution suivante pour ces tables :
* je considère qu'une table temporaire est une table 'normale' et je la migre directement dans SQLServer 2005 avec un nouveau nom
* je rajoute une colonne 'spid' qui a comme valeur par défaut @@SPID (qui me renvoie le n° de la connexion)
* je crée une vue (avec le même nom que la table dans Access) qui filtre sur cette table avec comme critère 'spid=@@SPID'
* je peux alors 'attacher' la table temporaire vers la vue SQLServer.

Voici un exemple de script dans SQLServer :

Code :

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

1
2
3
4
5
6
7
8
 
CREATE TABLE [dbo].[TableTemp](
	[id] int IDENTITY PRIMARY KEY ,
  [libelle] [varchar](50) NULL,
	[spid] [int] NOT NULL DEFAULT (@@spid)
) ON [PRIMARY]
 
create view vTableTemp as select id, libelle from TableTemp where spid=@@SPID

Sous Access, je peux alors insérer des données depuis la table attachée sur la vue (elles sont bien stockées dans la table) , mais je ne vois pas les données renvoyées par la vue, j'ai des enregistrements #supprimé.

J'ai fait des tests complémentaires, et c'est la clause 'spid=@@SPID' dans la vue qui pose problème. Si je remplace par une valeur en dur, cela fonctionne bien (mais ne me convient pas dans mon cas). J'ai essayé de passer par une UDF, mais toujours le même problème.

Quelqu'un a-t-il une piste ?

Merci par avance pour vos réponses

[Chtulus]

Bonjour,

Dans la table les valeurs pas défault sont donc @@SPID...

Ors si tous tes enregistrements on une valeur "spid", tu n'auras pas dans ta vue de spid = @@SPID.

Il faut savoir qu'au départ le SQL n'est pas dynamique, c'est à dire qu'il à besoin de paramètre en dur pour fonctionner.

Donc dans ta vue tu n'obtient aucun retour positif de @@SPID.

De plus niveau performance, liéer les tables n'ait pas une bonne idée.
Le traitement est totalement différent. Voici une réponse que j'avais reçu a ce sujet :

SELECT * FROM CLIENT WHERE (CLI_NAME like ‘%CLINTON%’)

SGBD fichier : environ 10 001 000 octets ont été véhiculé sur le réseau
SGBD C/S : environ 1 050 octets ont été véhiculés sur le réseau

Dans ce cas, le rapport est de près de 1/10000 en faveur du C/S…

Le fait est qu'en utilisant du SQL Direct les données renvoyées ne correspondent qu'à la table résultat de la requête, et que dans le cas de table logique, il s'agit de toutes les données !!!

Hésite pas si tu as d'autres questions mais je pense que sur le forum SQL tu aurais plus de réponse !

[PMAR]

Bonjour,

J'ai peur que nos amis du forum SQL ne puisse m'aider !
Cela fonctionne parfaitement sous SQLServer.

D'après mes tests, c'est Access qui se comporte bizarrement sur une vue paramétrée par des variables SQLServer

Voilà, si quelqu'un a déjà eu ce soucis...

A bientôt