6
votes

MS-Access voit les champs DateTime2 de SQL Server comme texte

Je propose ma candidature à partir de MS-Access Fe et soyez à MS-Access Fe et SQL Server Be. J'ai utilisé l'outil SSMA Access "Upsizing" pour convertir toutes les tables de l'accès à SQL, puis j'ai raccordé les tables SQL dans l'accès Fe à l'aide de ODBC.

Dans ma base de données d'accès, certaines tables ont eu des colonnes DateTime converties dans la colonne DateTime (0) dans SQL Server. Après avoir lié ces tables dans l'accès, l'accès voit les colonnes de Thèses sous forme de colonnes de texte même si elles sont DateTime2 (0) colonnes dans le serveur SQL BE.

Cela cause un problème car les requêtes qui travaillaient avec un format de date ne fonctionnaient pas avec le format de texte. Est-ce qu'il y a de toute façon pour relier les tables de sorte que le champ DateTime (0) soit traité comme des valeurs DateTime par accès?


4 commentaires

Voulez-vous dire par DateTime2 (0)? DateTime devrait fonctionner avec MS Access. J'ai besoin de faire plus de messages pour DateTime2.


@Remou: Oui, je voulais dire DateTime2 (0), je corrigerai la question. Je dois admettre que je ne connais pas la différence entre DateTime et DateTime2. Quel genre de message avez-vous besoin de faire pour travailler avec accès?


Je voulais juste dire que je devais en savoir plus. Selon TechNet.Microsoft.com/en-us/library/cc179181.aspx < / a>, il n'existe que le nouveau type de données, DateTime2. J'irais avec Datatime, si vous le pouvez.


@Remou: OK, je pense que je peux toujours rejouer l'exportation et cette fois, je vais configurer SSMA pour créer des champs DateTime à la place. Il vous formule cela comme une réponse que je l'accepterai.


5 Réponses :


7
votes

Selon TechNet , il n'existe que le nouveau type de données, DateTime2. J'irais avec DateTime, si vous le pouvez.


0 commentaires

-2
votes

Il est généralement nécessaire de vérifier vos dates avant l'assistant de dosage. Les utilisateurs ont tendance à entrer des dates "stupides" acceptées par les champs de date d'accès, mais provoquent une erreur dans SQL Server. Essayez d'interroger vos tables avec des dates à l'extérieur d'une gamme raisonnable comme "entre le 1/1/1930 et le 1/1/2020" et corrigez ces dates avant de redémarrer l'assistant de dosage.
J'ai également trouvé un produit que je n'ai pas utilisé mais qui a l'air bien: http: // www. upsizing.co.uk/features_translate.aspx


2 commentaires

Les limites de date de votre relevé entre Betweeen ne sont pas correctes pour SQL Server. Les références disent que 1/1/1753 est le point de départ. En outre, SQL Server 2008 ajoute un nouveau type de champ de date qui peut revenir à l'année 1.


@David: Bien sûr, ils ne sont pas (ce serait triste pour SQL Server). Je recommandais de faire un chèque sur la plage de date raisonnable (pour ses données), d'éliminer les dates stupides.



1
votes

Le SSMA d'accès convertira n'importe quel champ de date / heure avec des valeurs non valides dans SQL Server au texte. Vous devez exécuter le SSMA pour essayer la conversion et vous indiquerez les problèmes, puis vous pouvez nettoyer les données avant votre conversion actuelle.

Vous devrez ignorer l'assistant SSMA, car il fait le dosage sans prévisualiser les résultats.


0 commentaires

1
votes

J'ai rencontré le même problème qui me conduit à cette page, mais j'ai compris la solution: Problème: Tableaux liés de l'accès à SQL Server Afficher les colonnes DateTime2 sous forme de texte, qui présente de nombreuses implications comme la comparaison de date, de tri, etc.

Solution: Convertissez DateTime2 dans SQL Server à la date de date et l'accès affichera la colonne comme champ de date immédiatement

Notez que, étant donné que les tables ont déjà des données, vous ne pouvez pas simplement modifier les types de données, je prévois d'ajouter de nouvelles colonnes Type DateTime, de copier des données sur, de supprimer la colonne Orig, renommer

Comment vérifier la précision: j'ai créé une table avec 3 colonnes dans SQL Server, DateTime, DateTime2, Date, alors je l'ai liée à partir de l'accès, seule DateTime a montré comme champ de date dans l'accès, les autres 2 montrés sous forme de texte


0 commentaires

8
votes

Numéro similaire: Résolu

J'ai un serveur SQL avec un champ en tant que type de données DateTime2 et je me le connoiez via ODBC en tant que tableau lié à la MS Access sur Win7. P>

lors de la connexion de deux Différentes postes de travail utilisant la même dB, un type de données approprié de "date / heure" et l'autre avait un type de données de "texte court" p>

solution: il s'avère que les tables liées ont été établies en utilisant Deux fichiers DSN différents, l'un avait répertorié "pilote = SQL Server" et l'autre "Client Native Driver = SQL Server 11.0". Afin d'avoir un type de données "date / heure" via la liaison ODBC, je devais utiliser le client 11.0. P>

Pour voir quels pilotes vous avez installés: P>

SQL Server                     6.01.7601.17514
SQL Server Native Client 10.0  2007.100.5500.00
SQL Server Native Client 11.0  2011.110.6020.00


2 commentaires

Merci d'avoir apporté de nouvelles informations à une ancienne question et souhaite la bienvenue au débordement de la pile!


On peut modifier SSMA à UPSIZE à l'ancienne DateTime. Je le recommande si on ne va pas utiliser et adopter les nouveaux pilotes natifs de Native. Le pilote nouveau est préféré, mais nécessite que chaque poste de travail ait installé les nouveaux pilotes. Pour cette raison, j'utilise actuellement le plus ancien pilote SQL installé sur toutes les machines Windows par défaut.