Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

'#supprimé' apparait dans mes tables, impossible de modifier les enregistrements ....

598 views
Skip to first unread message

Denis

unread,
Feb 9, 2006, 12:45:46 PM2/9/06
to
Bonsoir à tous !
Je suis face à un problème qui me fait tourner en rond !!!! :-(
Contexte:
-Un serveur Windows 2000 SP4 qui héberge SQL serveur 2000,
-une "appli" sous Access qui possède des tables, toutes liées à partir de
SQL server et exécuté à partir d'un XP SP2.

Dans l'appli, à un moment donné, je crée une table avec la requête suivante:
-----------------8<----------------------------8<---------
CREATE TABLE T_Log_" & str_ID_serveur & " (
[ID_Log] [bigint] IDENTITY (1, 1) NOT NULL ,
[ID_Admin] [int] NULL ,
[WMI_Event_Type] [nvarchar] (1) COLLATE French_CI_AS NULL ,
[WMI_Time_Written] [nvarchar] (14) COLLATE French_CI_AS NULL ,
[WMI_Source_Name] [nvarchar] (50) COLLATE French_CI_AS NULL ,
[WMI_event_log] [nvarchar] (3) COLLATE French_CI_AS NULL ,
[WMI_Categorie] [nvarchar] (50) COLLATE French_CI_AS NULL ,
[WMI_Event_Code] [int] NULL ,[WMI_RecordNumber] [int] NULL ,
[WMI_User_Context] [nvarchar] (50) COLLATE French_CI_AS NULL ,
[WMI_Message] [nvarchar] (1500) COLLATE French_CI_AS NULL ,
[Solution_proposee] [nvarchar] (1500) COLLATE French_CI_AS NULL ,
[Mise_en_pratique] [nvarchar] (1500) COLLATE French_CI_AS NULL ,
[Conclusion] [nvarchar] (1500) COLLATE French_CI_AS NULL ,
CONSTRAINT [PK_T_Log_" & str_ID_serveur & "]
PRIMARY KEY CLUSTERED([ID_Log]) ON [PRIMARY])
ON [PRIMARY]
-----------------8<----------------------------8<---------

La requette fonctionne sans aucuns soucis.

Ensuite, je crée dynamiquement la liaison de cette table vers Access avec ce
code, qui fonctionne également sans aucuns soucis:
-----------------8<----------------------------8<---------
'créer la liaison dans Access vers la nouvelle table créée
DoCmd.TransferDatabase acLink, "Base de données ODBC", "ODBC;DRIVER={SQL
Server};SERVER=APP\TP;DATABASE=LOGs_DCs_WINNG;", acTable, "T_Log_" &
str_ID_serveur, "dbo.T_Log_" & str_ID_serveur, 0, True

-----------------8<----------------------------8<---------


Pour continuer, naturellement, j'en viens à insérer des données dans cette
table .... là, déjà, un truc louche apparaît:
si je consulte le contenu de la table sur le serveur SQL, je vois tous les
enregistrements correctement. Par contre, si j'ouvre la table sous Access,
je vois systématiquement "#Supprimé" dans tous les champs ...

Soit, à première vue ce n'est pas contraignant, même si ça me parait
anormal...

Là où ça me pose réellement soucis, c'est lorsque je veux supprimer un
enregistrement à partir d'une requête exécutée à partir d'acces: rien ne se
passe !!!
Si je l'exécute sur le serveur, tout se passe correctement ....

En fouinant sur le Net, je n'ais trouvé que cette page
:http://mysql.ifrance.com/showthread.php?t=229
Mais bon, après avoir vérifié que Microsoft MDAC, Microsoft Jet 4.0 étaient
à jour, testé l'histoire des INT, du champ en plus TIMESTAMP, je ne sais
plus quoi faire !!!!

Si vous auriez une idée ....

Merci d'avance !

Denis


Gafish

unread,
Feb 10, 2006, 5:10:13 PM2/10/06
to

"Denis" <dni...@free.fr> a écrit dans le message de news:
eEagqCaL...@TK2MSFTNGP09.phx.gbl...
> Bonsoir à tous !

Bonsoir

> si je consulte le contenu de la table sur le serveur SQL, je vois tous les
> enregistrements correctement. Par contre, si j'ouvre la table sous Access,
> je vois systématiquement "#Supprimé" dans tous les champs ...
>
> Soit, à première vue ce n'est pas contraignant, même si ça me parait
> anormal...
>
> Là où ça me pose réellement soucis, c'est lorsque je veux supprimer un
> enregistrement à partir d'une requête exécutée à partir d'acces: rien ne
se
> passe !!!
> Si je l'exécute sur le serveur, tout se passe correctement ....

Cela vient de ta liaison odbc. Si tu fais tout "à la main" pour voir, ca
marche ?
Sinon crée toi un dns en modifiant les différents paramètres, notamment le
timeout.

Arnaud
--
Charte du forum : http://www.mpfa.info/
Recherche dans les archives :
http://groups.google.fr/group/microsoft.public.fr.access?hl=fr


Denis

unread,
Feb 11, 2006, 7:20:40 PM2/11/06
to
Ben en fait, j'ai quasiment tout essayé !!!! y compris créer sur le serveur
SQL puis lier ...
Ca ne fonctionne toujours pas!
J'ai cependant constaté que le problème venait peut être du fait que la clef
primaire de ces tables n'est pas vue depuis ACCESS... c'est étrange, puisque
je travaille depuis longtemps avec une 40 aine de tables liées sur ce
serveur SQl, et c'est la première fois que j'ais ce problème !!!
Sinon, je n'ais pas trouvé où modifier le time out .... si tu veux bien
m'éclairer ...

En attendant, la solution palliative consiste à effectuer mes suppressions
en créant une connexion ... un peu comme si la table n'était pas liée :-(

-----------------8<----------------------------8<---------
Set obj_connection = CreateObject("ADODB.connection")
Set obj_commande = CreateObject("ADODB.Command")
obj_connection.ConnectionString = "Provider=SQLOLEDB.1;Integrated
Security=SSPI;Persist Security Info=False;Initial
Catalog=LOGs_DCs_WINNG;Data Source=APP\TP"
obj_connection.Open
obj_commande.ActiveConnection = obj_connection
obj_commande.CommandText = "DELETE FROM dbo.T_Log_37 WHERE blablabla"
-----------------8<----------------------------8<---------

Merci pour ton intervention ;-)

DNI

"Gafish" <---g...@free.fr----nospam> a écrit dans le message de news:
%23mUMf5o...@TK2MSFTNGP09.phx.gbl...

Gafish

unread,
Feb 13, 2006, 3:26:18 AM2/13/06
to
Denis wrote:
> Ben en fait, j'ai quasiment tout essayé !!!! y compris créer sur le
> serveur SQL puis lier ...
> Ca ne fonctionne toujours pas!
> J'ai cependant constaté que le problème venait peut être du fait que
> la clef primaire de ces tables n'est pas vue depuis ACCESS... c'est
> étrange, puisque je travaille depuis longtemps avec une 40 aine de
> tables liées sur ce serveur SQl, et c'est la première fois que j'ais
> ce problème !!! Sinon, je n'ais pas trouvé où modifier le time out .... si
> tu veux
> bien m'éclairer ...
>
> En attendant, la solution palliative consiste à effectuer mes
> suppressions en créant une connexion ... un peu comme si la table
> n'était pas liée :-(

Essaie de jour avec les options avancées d'Access (outils...options, onglet
avancé) voir si ca améliore quelque chose.

Denis

unread,
Feb 16, 2006, 3:07:11 PM2/16/06
to
Ben comme tu me l'as proposé, j'ais regardé ces options, mais sans aucuns
changement .... :-(

Sinon, en regardant de plus près, j'ais constaté que le champs désigné en
clef primaire n'est pas identifié en tant que tel sous acces ...
Naturellement, si il ne voit pas la clef primaire, comment pourrait il faire
pour identifier les champs ....

Bref, j'en reste au même point :-(

DNI.

"Gafish" <---g...@free.fr----nospam> a écrit dans le message de news:

OiQkbbHM...@TK2MSFTNGP10.phx.gbl...

Gafish

unread,
Feb 21, 2006, 3:39:56 AM2/21/06
to
Denis wrote:
> Ben comme tu me l'as proposé, j'ais regardé ces options, mais sans
> aucuns changement .... :-(
>
> Sinon, en regardant de plus près, j'ais constaté que le champs
> désigné en clef primaire n'est pas identifié en tant que tel sous
> acces ... Naturellement, si il ne voit pas la clef primaire, comment
> pourrait il faire pour identifier les champs ....
>
> Bref, j'en reste au même point :-(

Quand tu fais le lien de tes tables odbc, il te demande justement de
selectionner les champs qui permettront de définir l'unicité d'un
enregistrement, as-tu choisi les bons champs à ce moment là ? Essaie peut
être de refaire le lien de tes tables odbc ?

Denis

unread,
Feb 22, 2006, 5:57:50 AM2/22/06
to
Trop content de voir une réponse supplémentaire ... mais sans changement à
l'arrivé:
Donc, j'ais essayé de faire le lien manuellement -> à aucun moment il me
demande de sélectionner un champ pour définir l'unicité :-(
Par contre, j'ai essayé d'importer la table par curiosité:
- là je voie bien les enregistrements,
- pas de clef primaire de définit contrairement à la table originale ...

Toujours est il que je stagne encore et encore !!!

Merci tout de même pour ton idée ;-)

DNI.


"Gafish" <---g...@free.fr----nospam> a écrit dans le message de news:

OV9aTIsN...@TK2MSFTNGP10.phx.gbl...

Jeffrey

unread,
May 19, 2006, 8:22:01 AM5/19/06
to
J'ai le même problème.

En regardant un peu mes autres tables, j'ai aperçu que la clé primaire était
en bigint sur le serveur SQL.

Drolement, dans Access, la clé primaire est déclaré comme texte. Étrange !!

Je continue à rechercher.

"Denis" a écrit :

Jeffrey

unread,
May 19, 2006, 8:31:01 AM5/19/06
to
Dans l'aide de de Access, il a un tableau de conversion pour les variables
SQL et Access.

Voici un extrait :

Type de données Microsoft Access | Type de données SQL Server

Numérique (Octet) tynyint
Numérique (Entier) small int
Numérique (Entier Long) int
Numérique (Réel simple) real
(pas d'équivalent) bigint
Numérique (Réel double) float

C'est donc pourquoi Access convertit un bigint en texte. Il faudra
peut-être convertir la clé primaire sur SQL en real ou int.

J'espère que ceci a pu répondre à la question.

"Jeffrey" a écrit :

acroac

unread,
Nov 15, 2016, 3:37:17 PM11/15/16
to
Le jeudi 09 Février 2006 à 18:45 par Denis :
Bonjour Denis .

enfait le probléme vient du fait que la clé ( type ou format sur la table Sql )
est Insupporté sur Access

s'il s'agit d'un ID (Numéro auto )

il faut redéfinir la clé sur la table Sql en mentionant que c'est un clé unique


bon courage
0 new messages