Erreur de mise à niveau de la base de données MS-Access

Je travaille sur la migration d'une base de données MS-Access d'Access 2010 à MS-SQL 2008 (10.0.1600). Lorsque j'exécute l'Assistant de migration, toutes les tables sont déplacées, sauf une ...

La table qui n'est pas déplacée contient environ 18 000 enregistrements et de nombreux noms de colonnes contiennent des espaces. Je ne sais pas comment savoir pourquoi la table ne bouge pas. L'erreur que je reçois me dit seulement que "Tabulation a été ignorée ou l'exportation a échoué". Je ne sais pas comment obtenir Access pour me fournir une erreur plus utile que cela.

Jusqu'à présent, j'ai confirmé que l'erreur n'était pas causée par:

• Types de données invalides (oui / non, date, etc.)
• Espaces dans les noms de colonne

L'assistant de migration fourni avec Access est toujours derrière la courbe, car il ne peut gérer que les anciennes versions de SQL Server.

L’outil approprié pour la migration est l’Assistant de migration SQL Server pour Access. Il est beaucoup plus souple et plus intelligent en ce qui concerne ce qu’il peut faire. Il est également mis à jour pour refléter la dernière version de SQL Server.

Avec elle, vous pouvez prévisualiser ce que l'opération d'upizing va faire et corriger les problèmes s'il y en a. La seule chose que j'ai trouvée qu'elle ne puisse pas faire est d'interpréter correctement certains types de règles de validation au niveau du champ. Sinon, c’est très bien de signaler les problèmes et d’identifier exactement ce qui doit être changé.

J'ai rencontré un problème similaire. Il s'est avéré que j'avais un champ configuré pour l'incrémentation automatique en tant que champ d'identité. La structure de la table a été transférée sur SQL Server mais aucune donnée n'a été importée. Je n'ai pas encore eu la chance d'aller jusque-là, mais mon objectif est de définir la propriété d'identité sur "NON", puis de fractionner la base de données avec succès, de rétablir la propriété sur "OUI". Ce n'est probablement qu'une des nombreuses possibilités.

Est-ce que certaines de vos autres tables ont des espaces dans leurs noms de colonnes? Si ce n'est pas le cas, vous pouvez essayer de renommer les colonnes en modifiant les espaces comme des traits de soulignement ("_"), puis en utilisant les commandes SQL "ALTER TABLE" sur la console du serveur MS-SQL pour rétablir les colonnes (si elle est prise en charge).

Toutefois, l'utilisation d'espaces dans vos noms de colonne n'est pas recommandée car elle peut entraîner toutes sortes de complications (notamment citer des portions de commandes SQL et empêcher les attaques par injection, etc.) et des problèmes, en particulier lorsque davantage de développeurs sont impliqués. Je vous recommande également de passer aux caractères de soulignement et de mettre à jour votre code en conséquence.

pour grins (il devrait être rapide d'essayer de résoudre les problèmes / vérification de la santé mentale) lancer une requête make-table contenant tous les champs mais avec des noms très courts dans les champs de sortie (ex: fname: [Nom de l'utilisateur]), tout en conformité , bref, un mot. Vous obtiendrez alors une table en double et vous pourrez jouer avec les mises à jour de types de données, etc., lorsque vous modifierez la table et tenterez de la migrer.

J'espère que quelqu'un ajoutera les vraies limites techniques que vous rencontrez, mais quand je rencontre ce genre de choses, je trouve qu'il est préférable d'arriver à des structures vraiment basiques et de progresser jusqu'à ce que je veux faire - petites étapes, un changement chez un temps - votre droit de douter de l'exactitude des messages d'erreur - j'ai reçu de tels messages trompeurs de la part de SQL, et un accès spécifique - pas seulement vague, mais clairement trompeur, faux que le message d'erreur et le problème soient si communs et spécifiques que la réponse est partout dans les 5 premières pages de résultats Google ou c'est tellement mauvais, je reviens à la base et je reviens à la chose complexe que je suis après