Migrer l'application de database Access 2007 vers SQL Server 2005 à l'aide de SSMA – Problèmes

J'ai réussi à faire fonctionner SQL Server 2005 Express sur mon ordinateur Ok afin de faire quelques tests avant de l'essayer dans le "monde réel".

J'ai une assez grande application de database MS Access 2007 J'ai besoin de migrer vers SQL Server en conservant le "Front End" comme interface user. (L'application 'est déjà une database "split" avec un Front et Back end ….)

J'ai effectué quelques tests initiaux sur l'utilisation de SSMA pour migrer ma database Access vers SQL Server Express.

Clairement je ne comprends pas certaines choses et j'ai pensé que je verrais si quelqu'un a des idées.

Conceptuellement je pensais que ce qui devait arriver était que le Back End de la database qui réside sur le server devait être migré vers le server SQL et que le Front End soit lié aux tables (maintenant liées à SQL) dans le Back End.

Quand je fais cela en utilisant SSMA, je me retrouve avec des tables renommées dans le file Back End Access qui ressemblent à quelque chose comme "SSMA $ myTableNameHere $ local". Je reçois également les noms de table d'origine en dessous montrant les tables liées ODBC.

Jusqu'ici tout va bien.

MAIS …. Quand je vais rétablir les tables liées à partir du FRONT END (l'interface user) tout ce que je peux voir est les noms "SSMA $ myTableNameHere $ local" PAS les noms de table d'origine. (Maintenant lié via ODBC) Je peux lier aux tables "SSMA ,,,," mais cela signifierait changer les noms de chaque table dans chaque requête et sur chaque formulaire et dans tout le code sur le Front End! Pas quelque chose que je veux vraiment faire.

ALORS….

J'ai pensé que j'essaierais de migrer le FRONT END et de voir ce qui se passe.

Ce que j'ai fini avec est une situation où, fondamentalement cela fonctionne (il y a quelques erreurs sérieuses et problèmes que je n'ai même pas regardé encore … comme des données manquantes etc. !!!!) et je reçois toujours le "SSMA" $ myTableNameHere $ local "tables et les tables liées ODBC avec les noms d'origine.

J'essaie de comprendre …… Est-ce que cela veut dire que nous ferions la migration sur le Front End et que nous copyrions le même file sur l'ordinateur de chaque user?

Un autre sujet que je suis un peu confus est que je ne peux pas relier via ODBC à SQL Server Express sur la machine locale (c'est-à-dire mon ordinateur), donc je ne peux pas tester la migration vers le backend. Fin comme je l'ai fait dans le passé dans une situation plus client / server.

En supposant que SSMA remplace les tables de votre back-end par des liens vers SQL Server, tout ce que vous devez faire est de supprimer les liens de table d'origine dans votre frontal et d'importer les liens de table nouvellement créés à partir du backend . Vous pouvez ensuite rejeter l'extrémité arrière, car il n'est plus utilisé pour rien du tout.

J'ai transféré toutes mes tables une par une à SQL Server 2005 pour Access DB back-end en utilisant ODBC.Instruction: Open Access DB (back-end) Cliquez avec le button droit sur la table, vous devez transférer Faites défiler la list déroulante et select Cliquez sur le button "Nouveau" Créer une nouvelle boîte de dialog de source de données ouverte. Faites défiler vers le bas et select SQL Server, puis click Suivant pour atsortingbuer le nom à votre source de données, click Suivant, click Terminer. Donner une discription OU laisser vide, tapez Nom de votre server SQL (vous l'avez nommé, lors de l'installation de SQL Server sur votre machine) Cliquez sur Suivant, click Suivant, cochez la checkbox Sélectionner la database par défaut. , Cliquez sur Terminer REMARQUE: Vous devez créer une nouvelle database (vide) sur SQL Server, avant de faire tout ceci: Cliquez avec le button droit sur une table, select Exporter, select dans la list déroulante ODBC, dans la window Sources de données select votre source de données, Vous avez créé, click OK Utiliser SQL Server avec SQL Management Studio Express. Toutes les dates doivent avoir un masque de saisie. Tout le text et la note doivent avoir Allow Zero Length = Yes Après tout, déconnectez tous les liens d'Access back-end, et établissez des liens à partir de SQL.RENAME toutes les tables nouvellement reliées aux anciens noms. Utilisez l'interface user Fron-End, jusqu'à en faire de nouvelles.

Pardonnez mon manque de connaissance de Acronym Soup, mais je suppose que SSMA est l'assistant de données d'import SQL Server 2005 ou l'assistant dans Access pour envoyer datatables à SQL Server. Il semble que vous avez envoyé datatables à SQL Server à partir d'Access – quelque chose que vous ne voulez pas faire. Vous voulez utiliser le DTS dans SQL Server (maintenant appelé SSIS ou quelque chose?) Pour importer datatables dans SQL Server. Ensuite, vous aurez vos tables dans SQL Server. Ensuite, créez simplement votre input DSN pour le server SQL et reliez vos tables. Tout devrait bien se passer.

Dans l'set, la règle générale consiste à importer des tables Access à l'aide de SQL Server au lieu d'utiliser Access pour envoyer datatables à SQL Server.

Je mordre la balle et renommer les tables du côté de SQLServer aux noms amicaux que vous aviez dans la database originale. Vous aurez probablement less de problèmes. Surtout si vous avez un code embedded du côté MS Access.

En ce qui concerne la façon dont vous allez déployer le côté MS Access maintenant, il devrait créer à peu près le lien ODBC sur le post de travail de l'user et copyr le file MS Access sur son bureau (même si vous voulez créer un MDE ) pour les empêcher de le casser accidentellement).

Franchement, maintenant que vous avez migré, vous devez regarder la design de vos tables. C'est mon expérience que les assistants pour la migration d'Access font un mauvais travail de sélection du type de données correct. Par exemple, si vous aviez un champ mémo, vous pourriez facilement sortir avec un champ varchar à la place, mais le dernier assistant que j'ai utilisé (une version antérieure) les a toujours convertis en champs de text. Maintenant, il serait également time de considérer certaines corrections telles que la date fileds datetime à la place du caractère basé si vous avez eu cette erreur dans le passé.

Je ne penserais jamais à utiliser à nouveau un assistant pour faire la migration de données moi-même ayant expérimenté à quel point ils peuvent le faire.

Vous findez également que la simple conversion des données vers SQL Server n'est souvent pas très utile pour get des performances optimales. Vous aurez besoin de tester toutes les requêtes et de considérer si vous pouvez les convertir en proc stockées à la place si elles sont lentes. L'élimination de la traduction de Jet SQL vers T-sql peut améliorer les performances. De plus, il existe de nombreuses fonctionnalités de t-sql qui peuvent améliorer les performances sans équivalent Access. L'access n'est pas très important pour l'optimization des performances, mais pour tirer parti de l'optimization des performances avec un backend SQL Server, vous devez écrire des requêtes spécifiques à SQL Server. INdexing doit être pris en count si les tables Access n'ont pas été indexées correctement.

L'utilisation de SSMA est différente lorsque vous utilisez odbc. Si vous avez une application utilisant un access complet (back end et front end). Vous pouvez manipuler facilement des objects en utilisant DAO, etc .. sans problème, puis quand vous devez migrer la database vers le server sql vous pouvez utiliser directement odbc (en reliant vous-même les tables au server sql), ssma, … le problème principal comment conserver les formulaires délimités, les requêtes, le code dans le client. Si vous utilisez directement odbc vous devez relier vous-même tous les objects et changer de code mais si vous utilisez ssma, vous n'avez rien à faire, vous continuerez à travailler comme avant. Le problème avec SSMA est comment déployer le front end aux clients si vous avez développé le côté client à l'autre endroit en utilisant un autre server sql?