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
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
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...
Essaie de jour avec les options avancées d'Access (outils...options, onglet
avancé) voir si ca améliore quelque chose.
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...
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 ?
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...
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 :
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 :