Exécution de procédures stockées avec des paramètres de date: objet de commande et objet de connexion

Question

Lorsque vous fournissez des dates à une procédure stockée via un paramètre, je ne sais trop quel format utiliser pour les dates. Ma syntaxe VBA d'origine utilisait l'objet ADO Connection pour exécuter la procédure stockée:

Set SentDetailRS = Me.ADOConnectionToIntegrity.Execute("dbo.s_SelectAggregatedSentDetailList '" & fCSQLDate(EffectiveDate) & "'", , adCmdText)

Cela fonctionne très bien pour moi en utilisant la syntaxe de date aaaa-mm-jj , mais lorsqu'un autre utilisateur exécute le code, il reçoit l'erreur suivante: 13 'Type Mismatch'.

Après quelques expériences, j'ai constaté que la fourniture de la date au format jj / mm / aaaa corrige cette erreur pour l'utilisateur mais me renvoie maintenant l'erreur!

L'exécution de la procédure stockée à l'aide d'un objet de commande avec des paramètres fonctionne quel que soit le format de la date (je suppose que ADO prend en charge le formatage en arrière-plan). Je pensais que l’utilisation du format aaaa-mm-jj fonctionnerait universellement avec SQL Server?

Je suis également perplexe quant à pourquoi ce problème semble être spécifique à l'utilisateur? J'ai remarqué que ma langue par défaut sur SQL Server est "Anglais", tandis que la langue par défaut de l'autre utilisateur est "Anglais britannique", est-ce que cela pourrait poser problème?

J'utilise ADO 2.8 avec Access 2003 et SQL Server 2000, la connexion à SQL Server s'effectue via la sécurité intégrée de Windows.

Answer 1

Faites attention et ne croyez pas que ADO s’occupe du problème. Le format de date universel SQL est 'AAAAMMJJ', alors que SQL et ACCESS sont tous deux influencés par les paramètres régionaux de la machine dans la manière dont ils affichent les dates et les convertissent en chaînes de caractères.

N'oubliez pas que le séparateur de date est # dans Access, alors qu'il est 'en SQL

Mon meilleur conseil sera de convertir systématiquement votre numéro d’accès MM-JJ-AAAA (ou similaire) en "AAAAMMJJ" avant d’envoyer l’instruction à votre serveur. Vous pouvez créer une petite fonction telle que:

Public function SQLdateFormat(x_date) as string

SQLDateFormat = _
   trim(str(datePart("yyyy",x_date))) & _
   right(str(datePart("m",date)),2) & _
   right(str(datePart("d",date)),2)

   ''be carefull, you might get something like '2008 9 3'
SQLDateFormat = replace(functionSQLDateFormat," ","0")
   '' you will have the expected '20080903'

End function

Si vous ne construisez pas votre chaîne INSERT / UPDATE par programme avant de l'envoyer au serveur, je vous conseillerai alors de transformer les paramètres régionaux de toutes les machines en paramètres régionaux de la machine hébergeant SQL. Vous devrez peut-être également vérifier s’il existe un format de date spécifique sur votre serveur SQL (je ne suis pas sûr). Personnellement, j’ai résolu ce type de problèmes de localisation (cela se produit également lorsque le coma est utilisé comme séparateur décimal en français) ou des problèmes de caractères spécifiques à SQL (lorsque des guillemets ou des doubles guillemets sont dans une chaîne) en retirant les instructions SQL avant de les envoyer à la bibliothèque. serveur.

Answer 2

Je suppose que la fonction fCSQLDate est spécifique à la culture - c’est-à-dire qu’elle analysera la date en fonction des paramètres régionaux de l’utilisateur. C’est pourquoi vous voyez le problème.

Quoi qu’il en soit, utiliser des requêtes avec des chaînes concaténées est toujours une mauvaise idée (attaques par injection). Vous êtes mieux si vous utilisez des paramètres.

Answer 3

Access utilise # comme délimiteur de champ de date. Le format doit être # mm / jj / aaaa # probablement le # mm-jj-aaaa # fonctionnera également très bien.

Answer 4

Désolé, je ne connais pas mysql, mais avec oracle, je voudrais toujours indiquer explicitement le format auquel je m'attendais, par exemple: 'JJ-MM-AAAA', pour éviter les problèmes de format de date (régional)

Answer 5

Pourquoi ne pas utiliser le format

dd mmm yyyy

Il n'y a qu'une seule façon de l'interpréter.

Answer 6

Vous pouvez utiliser la fonction Date () pour renvoyer une date universelle basée sur les paramètres de date et heure de la machine. Les paramètres de région de la machine détermineront le formatage de celle-ci chez le client. Si vous laissez le champ comme strictoiment un champ DateTime, les paramètres de région cleint peuvent formater la date.

Entrer dans le serveur en utilisant la fonction Date () devrait également fonctionner (renvoyer une valeur de date universelle).

Utilisez également un objet de commande et des paramètres dans votre requête lorsque vous les transmettez pour éviter les attaques par injection SQL sur les champs de chaîne.