Discussion :

[micniv]

Bonjour,
Je voudrais migrer une appli vers SQLSERVER xxx.
Ainsi j'essaie vers SQLSERVER 2005 Exprerss Edition
(je m'inspire du tuto de J-P Ambrosino qui, il est vrai,est validé pour MSDE)

Donc avec un Sqlserver 2005, fraichement installé, qui tourne par defaut, je lance assistant de migration depuis mon Access 2000 / Outils

j'ai un nom d'utilsateur (groupe Admin) avec un mot de passe

Et là toujours la même erreur :

Echec lors de la connection
Etat SQL : 01000
Erreur Sql Server : 2
[Microsoft][ODBC SQL Server Driver][Shared memory]ConnectionOpen(Connect())
Echec lors de la connection :
Etat SQL : 08001
Erreur SQL server : 17
[Microsoft][ODBC SQL Server Driver][Shared memory] ce serveur n'existe pas ou son accès est refusé

Alors est ce possible de migrer de cette manière vers Server express 2005 ?
Autre question : est ce possible de migrer Access vers Server express 2008 ?
(en upgradant à Access 200x si besoin ...)

Si quelqu'un peut m'aider ; merci !

[=JBO=]

Bonjour micniv,

Je m'étais penché sur la question d'un projet ADP Access 2000 avec SQL Server 2005: Access 2000 et SQL Server 2005 Express Edition

Il en ressortait que Access 2000:
* ne peut se connecter qu'à l'instance par défaut,
* ne peut qu'utiliser les objets SQL Server 2005 et n'a pas la possibilité d'en créer de nouveaux.
A la place d'Access, on utilise SQL Server Management Studio Express pour développer et gérer la BD.

Je ne sais pas comment fonctionne l'assistant de migration depuis Access 2000 vis à vis de SQL Server, mais il est probable qu'il s'appuie sur les fonctionnalités d'Access 2000 qui sont bridées pour la création d'objets.

Je pense que ça a changé à partir d'Access 2003 ou 2007 et que l'assistant de migration fonctionne correctement pour SQL Server 2005 ( à vérifier).

Ce serait très sympa si un utilisateur/développeur Access 2007/SQL Server 2005 qui nous lit en profitait pour nous confier son expérience en particulier pour une migration de données vers une BD SQL Server

Cependant, ton message d'erreur fait penser à un problème de droits d'accès.
Avec quel compte essaies-tu de te connecter à SQL Server ?
Tu arrives à utiliser SQL Server Management Studio pour créer une BD, puis à créer le projet ADP qui exploite cette BD ?
_

[micniv]

Merci de ta réponse , JBO.

J'ai réinstallé cette fois Sql Server 2005 Express Advanced (le package d'install de 235 mo) et maintenant je dispose du MS SQL Management Studio Express.

D'autre part j'ai trouvé chez MS un assistant qui doit pouvoir faire le job : "SSMA 2005 for Access v4"

Je vous tiens au courant ... en attendant mieux

[cbleas]

bonjour,
es tu administrateur sur ton PC?
as tu utilisé la sécurité mixte ou la sécurité windows sur sql server?
Lorsque tu as installé sql server 2005 as tu selectionné la sécurité miste en mettant 1 mot de passe?

[micniv]

"SSMA 2005 for Access v4" a bien rempli bien son rôle.

Ma base est migrée, 0 erreurs mais 41 warnings et 120 infos pour une vingtaine de tables.

J'ai commencé le projet ADP : pour une quarantaine de form, il y a du taf !
d'autant plus que dans plusieurs de mes requêtes il y avait des champs calculés ou des fonctions (il va me falloir creuser pour pouvoir les remplacer ! ) Est-ce là, l'opportunité d'utiliser le Transac SQL ?

[cbleas]

Bonjour,
il y a pas beaucoup plus de taf à passer en adp, il faut surtout passer en ado avoir des requètes sans liaisons aux forlmulaire. pour ma part cela m'a pris une semaine pour migrer 400 formulires et sous formulaires et autant de requètes.
mais je ne reviendrai plus en arrière.
bon courage

[=JBO=]

Bonsoir micniv et cbleas !

J'ai réinstallé cette fois Sql Server 2005 Express Advanced (le package d'install de 235 mo) et maintenant je dispose du MS SQL Management Studio Express.

D'autre part j'ai trouvé chez MS un assistant qui doit pouvoir faire le job : "SSMA 2005 for Access v4"

"SSMA 2005 for Access v4" a bien rempli bien son rôle.

Ma base est migrée, 0 erreurs mais 41 warnings et 120 infos pour une vingtaine de tables.

Merci de nous avoir tenus informés !

J'ai commencé le projet ADP : pour une quarantaine de form, il y a du taf !
d'autant plus que dans plusieurs de mes requêtes il y avait des champs calculés ou des fonctions (il va me falloir creuser pour pouvoir les remplacer ! ) Est-ce là, l'opportunité d'utiliser le Transac SQL ?

Pour remplacer tes fonctions VBA tu vas devoir programmer en Transact-SQL des "fonctions définies par l'utilisateur".

Le point de départ est ici: Fonctions définies par l'utilisateur

Il y avait une discussion sur ce sujet dans le forum Access.

Amuse-toi bien !
_

[cbleas]

bonjour,
Pour ma part je n'est pas fait le moindre Transac SQL le traitement est fait en VBA.
et oui si on réutilise du transac SQL on repart sur l'incompatibilité si on souhaite passer sous oracle par exemple.
Par contre il est possible que j'y passe lorsque mon application sera totalement passée en web 2.0 mais c'st pas pour aujourd'hui.
Bonne journée

[micniv]

Me voila informé et rassuré !
Merci à vous.
Au taf now.

[=JBO=]

Bonjour à tous,

Pour ma part je n'est pas fait le moindre Transac SQL le traitement est fait en VBA.
et oui si on réutilise du transac SQL on repart sur l'incompatibilité si on souhaite passer sous oracle par exemple.

Eh bien, je crois que le souci de la compatibilité des SGBD est illusoire, à moins de n'avoir que des requêtes élémentaires et des besoins simplissimes.
Entre les ténors des SGBD, c'est bien souvent une question de choix de notre dépendance vis à vis d'un éditeur.

Pour revenir à la migration de micniv:

Considérant une application Access MDB dont certaines requêtes utilisent des fonctions utilisateurs VBA, notamment pour des critères de sélection.
Si on migre l'appli MDB vers un projet ADP SQL Server, je ne vois pas comment il sera possible de se passer d'un portage de ces fonctions en UDF SQL Server afin de les utiliser dans les vues et requêtes.

Ne pas porter les fonctions utilisateurs serait prendre le risque d'une régression.
Maintenant, si on n'utilise jamais de fonctions utilisateurs dans les requêtes Access, alors évidemment la question ne se pose pas pour leur migration.
_

[micniv]

Merci à vous pour ces infos supplémentaires

certaines requêtes utilisent des fonctions utilisateurs VBA

En effet, pouvoir utiliser des fonctions VBA dans les requetes est très puissant et reste convivial. Une fois qu'on y a gouté, on n'a du mal à s'en passer... (typiquement, pour un module de préparation de salaires BTP à partir de pointages, dans la requete qui prépare l'état final les 3/4 de mes champs sont des fonctions (jours ouvrés, heures supp, tickets restos, différentes primes d'outillage, de déplacement ...) avec tout cela des perf très acceptables.

Ce sont ces fonctionnalités que je ne veux pas perdre mais plutôt étendre.