Impossible de remplir un fichier excel via ADO

Bonjour

Je cherche pourquoi je ne peux pas mettre à jour mes données dans un fichier Excel via DAO

Le truc qui m'énerve c'est que ça fonctionne en production mais pas en développement ni en recette (c'est le même serveur pour la recette et la production, seul le serveur de développement est différent)

Lorque j'essaie de faire mon INSERT INTO, j'ai le message suivant : "L'opération doit utiliser une requête qui peut être mise à jour"

J'ai vérifié les droits d'écriture sur le dossier où est le fichier Excel, le groupe "Tous le monde" a les droits en lecture/écriture

Sur le serveur de développement, j'ai carrément joué bourrin, j'ai mis les droits en lecture/écriture à tous le monde pour tout le projet et ce n'est pas mieux

Voici ma chaîne de connexion

Code:

---

1 2 3 4

string connString = @"Provider=Microsoft.Jet.OLEDB.4.0;" + @"Data Source=" + Full_XLS_FileName + ";" + @"Extended Properties=""Excel 8.0;HDR=Yes;IMEX=1""";

---

avec Full_XLS_FileName qui est le chemin complet et absolu vers le fichier Excel à remplir

et ma requette INSERT :

Code:

---

1 2	INSERT INTO [DATA$] VALUES (/*mes valeurs*/)

---

Le nombre de valeurs données dans le INSERT correspond bien au nombre de colones définies dans la feuille DATA. Mes codes sont identiques en développement et en production. Mes fichiers Excel modèles sont aussi les mêmes (je copie un modèle dans un répertoire avant de le remplir, et j'ai bien contrôlé les droits du fichier modèle et du fichier copié)

Je parcours google depuis 2 jours pour arriver à comprendre ce qui se passe. mais là je craque :'(

(Au pire, personne ne connais un logiciel qui me permettes de coparer les droits des fichiers/repertoires de 2 dossiers ?)

Merci d'avance pour l'aide que vous pourrez m'apporter (et pour la détente de mes nerfs :mouarf:)

Citation:

---

Envoyé par mioux

Le truc qui m'énerve c'est que ça fonctionne en production mais pas en développement ni en recette (c'est le même serveur pour la recette et la production, seul le serveur de développement est différent)

---

Tu as mis en production quelque chose qui ne fonctionne ni en développement, ni en recette ? :aie:

La connextion ADO, c'est quoi ? ODBC ou OleDb ? Montre-nous un peu plus de code, stp.

Non, quand j'ai fais mon dev, ca fonctionnait ;D

Justement c'est ca le problème, c'est que je n'arrive pas à comprendre pourquoi ça ne fonctionne plus, d'où peut venir le problème... et j'aimerai qu'il ne m'arrive pas en prod suite à une mise à jour :D

Et pour la connexion c'est OleDb (c'est ce que je voulais dire à la place de ADO :D je me confond tout en plus :P)

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19

string connectionString = Get_ExcelConnection(fichier);   DbProviderFactory factory = DbProviderFactories.GetFactory("System.Data.OleDb"); DbConnection oDbConnnection = factory.CreateConnection(); oDbConnnection.ConnectionString = connectionString; DbCommand command = oDbConnnection.CreateCommand();   oDbConnnection.Open();   string EXCEL = @"INSERT INTO [" + excelTable + @"] VALUES (@mot_id, @langue_id, @base_id, @mot_fr, @abrv_fr, @mot_en, @abrv_en, @mot_lng, @abrv_lng, @taille)";   // ici je remplace les "@variable" par des valeurs, les requêtes paramétrées n'étant pas gérées par le moteur.   command.CommandText = EXCEL; command.ExecuteNonQuery();   oDbConnnection.Close();

---

Je plante à la ligne command.ExecuteNonQuery();

Ce n'est probablement pas un problème de droit :
Essaye l'une et/ou les deux propositions suivantes :
- retirer la propriété IMEX=1 de la chaine de connexion
- mettre la clé de registre HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Jet\4.0\Engines\Excel\TypeGuessRows à 0.

Sans le IMEX ca fonctionne merci :D

Maintenant je pars en quête de "A quoi peut servir la propriété IMEX" (parce que là, on avait copié un code tout fait trouvé sur Internet et qui avait le mérite de fonctionner... Du coup on a pas cherché à comprendre à quoi servait IMEX)

Citation:

---

Envoyé par http://www.connectionstrings.com/excel

"IMEX=1;" indique au moteur de toujours lire les colonnes contenant des données mixtes (nombres, dates, chaînes etc) en tant que texte. Remarquez que cette option peut empêcher l'accès en écriture dans une feuille Excel.

---

Oui j'avais trouvé :mrgreen:

Et sur le même site :mouarf: