Discussion :

[Bruno21]

Bonjour à tous,

J'essaie d'importer un fichier texte dans une base access.

Code :

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

Using reader As New Microsoft.VisualBasic.FileIO.TextFieldParser(filePath, System.Text.Encoding.Default)

pour parser le fichier

Code :

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

1
2
3
4
5
6
7
8
 Connection = New OleDbConnection("Provider=Microsoft.ACE.OLEDB.12.0;Data Source=" & baseAccess & ";Persist Security Info=False;")
...
requete = "INSERT INTO Etats (Compteur, [DateHeure]) VALUES ('" & Val(Compteur) & "', '" & DateHeure & "')"
 myCommand = New OleDbCommand(requete, Connection)
 retvalue = myCommand.ExecuteNonQuery()
...
 
Dans la base champ DateHeure est au format Date/Heure

pour la partie bdd


Mais la date qui est au format 04/07/2013 17:25:25:053 pose problème.

J'ai une OleDbException "Type de données incompatible dans l'expression du critère."


Si je vire les millièmes de secondes

Code :

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

DateHeure = Microsoft.VisualBasic.Left(DateHeure, 19)

les dates sont bien importées dans Access


J'ai essayé avec le format 04/07/2013 17:25:25.053, c'est pas mieux.


Ma question est donc comment importer les millièmes dans Access ?

Bruno.

[manuly]

Bonjour,

Faire deux champs un pour l'heure l'autre pour la date

il te suffit ensuite de créer un bout de code qui te restitue au bon format quand tu veux consulter ou faire des requêtes

tuto ici
http://access.developpez.com/faq/?pa...es#paramRegion

[DotNetMatt]

Ce qu'il faut surtout faire, c'est utiliser les requêtes paramétrées. Il n'y a que des avantages à les utiliser, même si ça demande quelques lignes de code de plus :
- Sécurité (injection SQL)
- Formats gérés nativement (dates, nombres décimaux...)
- Rapidité d'exécution
- etc.

[Bruno21]

Bonjour,
ou si tu ne veux pas y aller, en résumé ce post conseil de faire deux champs un pour l'heure l'autre pour la date

il te suffit ensuite de créer un bout de code qui te restitue au bon format quand tu veux consulter ou faire des requêtes

Merci, c'est ce que je vais faire.

J'avais pensé aussi faire un "timestamp decimal", mais j'ai lu que ce n'était pas conseillé.

[Bruno21]

Ce qu'il faut surtout faire, c'est utiliser les requêtes paramétrées. Il n'y a que des avantages à les utiliser, même si ça demande quelques lignes de code de plus :

Je vais regarder ça de près.
Mais ça ne résoud pas mon pb.

[callo]

Je vais regarder ça de près.
Mais ça ne résoud pas mon pb.

Comment peux-tu affirmer que ça ne résoud pas ton problème sans avoir essayer de mettre en oeuvre sa solution

[manuly]

bonsoir callo,

je ne connais pas access donc il est possible ( même certain) que mon conseil ne soit pas le meilleur. Je privilégie d'autre SGBDR en fait car je trouve qu'access est trop limité et puis cette histoire de fichier unique .... bref des idées reçues sans doute mais si j'avais un conseil à donner pour tout ceux qui utilisent access se serait de passer sous du sqlserver ou du mysql

bref pas le sujet du post.

En tout cas bruno tiens nous au courant

(PS les requetes paramétrées peuvent t'aider à résoudre ton problème sisi !!

@callo si je ne m'abuse c'est un peu comme les procédures stockées non ?

[Mario Rousson]

tu as essayé de l'entrer manuellement voir si c'est pas au niveau de la bd si tu as une perte de valeur?

[callo]

(PS les requetes paramétrées peuvent t'aider à résoudre ton problème sisi !!

@callo si je ne m'abuse c'est un peu comme les procédures stockées non ?

On ne peut pas dire que les requêtes paramétrées sont comme les procédures stockés. Les paramètres permettent aux SGBD de retourner des enregistrements correspondants aux critères qui y sont définis. Tu peux donc avoir aussi bien des requêtes sql de type texte pramétrées que des procédures stockés paramétrés.

Pour mieux comprendre leur utilisation et leurs avantages, référez-vous au lien donnée DotNetMatt. Sa version vb.net est accessible ici.

Je voudrais cependant insister sur l'un des avantages mentionnés par DotNetMatt à savoir Formats gérés nativement (dates, nombres décimaux...).
Travailler avec les dates et décimaux dans les environnements multi-linguales peut effectivement devenir une casse-tête. Les requêtes paramétrées délèguent donc la gestion de ces problématiques de cultures au provider .net. Je me permet de reprendre l'exemple donné par sisqo60 dans ce post:
Soit la requête suivante:

Code :

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

select * from matable where monChampDate = '01/02/2013'

Si ton serveur a une culture anglaise tu auras le 2 janvier au lieu du 1 février. Donc, en laissant le provider .net gérer les cultures, tu ne te soucie plus des problèmes de localisation. Donc dans le cas précis de Bruno21, nul besoin de vérifier le format de la date. Avec les requêtes paramétrées, le code de Bruno21 pourraît alors ressembler à ceci:

Code vb.net :

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

1
2
3
4
5
6
7
8
9
10
Connection = New OleDbConnection("Provider=Microsoft.ACE.OLEDB.12.0;Data Source=" & baseAccess & ";Persist Security Info=False;")
...
requete = "INSERT INTO Etats (Compteur, [DateHeure]) VALUES (?ParamCompteur, ?ParamDate)"
 myCommand = New OleDbCommand(requete, Connection)
 myCommand.Parameters.AddWithValue("ParamCompteur", Compteur)
 myCommand.Parameters.AddWithValue("ParamDate", DateHeure)
'Execution de la requête
myCommand.Connection.Open()
myCommand.ExecuteNonQuery()
myCommand.Connection.Close()

Donc, utiliser des requêtes paramétrés est un bonne pratique; assure la sécurité contre les injections SQL et évite bien des soucis. Donc, requêtes paramétrés, requêtes paramétrés et toujours requêtes paramétrés

[manuly]

et bien .... merci pour cette étude de texte !!! je regarderai ça avec attention d'ici quelques minutes

[shayw]

Bonjour Callo

nul besoin de vérifier le format de la date. Avec les requêtes paramétrées

Si le format de ton champ est mm/dd/yyyy on doit enregistrer avec le meme
format non?

aussi quelle différence entre
myCommand.Parameters.AddWithValue("ParamDate", DateHeure)
et

command.Parameters.Add("?ParamDate", OleDbType.DBTimeStamp).Value = DateHeure

[callo]

quelle différence entre
myCommand.Parameters.AddWithValue("ParamDate", DateHeure)
et

myCommand.Parameters.Add("?ParamDate", OleDbType.DBTimeStamp).Value = DateHeure

Merci shayw pour ta remarque/question C'est vrai que je ne m'étais pas jusque là penché sur la différence entre les deux syntaxes. Cet article MSDN explique la différence entre les deux :

AddWithValue remplace la méthode SqlParameterCollection.Add qui prend un String et un Object. La surcharge de Add, qui prend une chaîne et un objet, a été désapprouvée en raison d'une possible ambiguïté avec la surcharge SqlParameterCollection.Add qui prend un String et une valeur d'énumération SqlDbType, où le passage d'un entier avec la chaîne pourrait être interprété comme étant soit la valeur de paramètre soit la valeur SqlDbType correspondante. Utilisez AddWithValue chaque fois que vous voulez ajouter un paramètre en spécifiant son nom et sa valeur.

En un peu, j'ai pu comprendre pas mal de choses. Voici donc ma synthèse:

Parameters.AddWithValue:
- Accepte seulement le nom du paramètre et sa valeur. Pas d'autres attributs comme le type de données, la taille, ParameterDirection (param d’entrée, param de sortie ou encore une valeur de retour). Dans le cas où on ajoute un paramètre et qu'on doive spécifier explicitement la valeur, pas besoin d'utiliser command.Parameters.Add.

La valeur est de type objet. Il n'y a donc pas de vérification de type. Ce qui pourrait potentiellement conduire à des erreurs si on essaye de fournir des valeurs ne correspondant pas au type de données du champ de la base de données cible. On doit donc s'assurer que la valeur est du bon type. Par exemple, si le champ dans la BD est un numérique et que l'utilisateur saisi un nombre dans un control textbox, alors on doit convertir le string dans le type numérique correspondant au type de la BD avant de le passer via AddWithValue.

Parameters.Add
Add requiert la spécification du type du champ de la table. Ce qui servira à réduire des erreurs puisque le type est vérifié avant envoi à la BD. Si on ne spécifie pas de façon explicite la valeur du paramètre, dans ce cas, on doit plutôt utiliser command.Parameters.Add. Ceci est particulièrement vrai quand on créer des DeleteCommand, InsertCommand, UpdateCommand ou DataAdapter.
De plus, pour les scenarios où il faut convertir en DateTime, float, decimal …. il serait plus safe d'utiliser Add pluttot que AddWithValue car la conversion serait plus explicite et plus safe.

Mais même dans le cas de Parameters.Add, il est important de s'assurer que les valeurs transmises sont du bon type. Si par exemple, tu spécifies un paramètre de type boolean mais que tu fournisses à la place un varchar, une exception serait levée.

Pour en revenir donc à notre cas ci: avec « AddWithValue », la date est envoyée comme un string à la BD. Cette dernière pourrait ne pas convertir avant de stocker. Ce qui peut poser problème. Mais si réellement la valeur du paramètre doit être convertie en date, alors la conversion se fera au niveau serveur en se référant à la culture du serveur au lieu de celle de l'application en cours d’exécution.

Donc, il serait plus safe de faire:

Code vb.net :

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

1
2
3
4
5
6
7
8
9
10
11
12
Connection = New OleDbConnection("Provider=Microsoft.ACE.OLEDB.12.0;Data Source=" & baseAccess & ";Persist Security Info=False;")
...
requete = "INSERT INTO Etats (Compteur, [DateHeure]) VALUES (?ParamCompteur, ?ParamDate)"
 myCommand = New OleDbCommand(requete, Connection)
myCommand.Parameters.Add(New OleDbParameter ("?ParamCompteur", OleDbType.VarWChar))
myCommand.Parameters("?ParamCompteur").Value = Compteur 
myCommand.Parameters.Add(New OleDbParameter ("?ParamDate", OleDbType.DBTimeStamp))
myCommand.Parameters("?ParamDate").Value = DateHeure 
'Execution de la requête
myCommand.Connection.Open()
myCommand.ExecuteNonQuery()
myCommand.Connection.Close()

Donc, je rectifie cette phrase

nul besoin de vérifier le format de la date.

. Il est judicieux de s'assurer qu'on passe le bon type.