Bonjour
Ma question comporte 2 volets : témoignage et références:
J'ai une appli développée sous Access et je voudrais la faire tourner sur
SQL serveur (que je ne connais absolument pas)
J'ai cru comprendre qu'il était possible d'utiliser les formulaires,
requetes, etats d'ACCESS
et d'etre relié aux tables SQL Seveur.
Témoignages: Quels sont les principales difficultés pour "transférer" une
appli ?
Quels sont les différents mode de fonctionnement
possibles ? (et leurs limitations)
(j'ai commencé à lire ce quelques articles sur le
site support de microsoft
mais je suis encore dans le brouillard)
Références : quels sont les ouvrages clés de référence qui abordent bien
le
problème ?
Bref : 2 question courtes qui entrainent des réponses très longues
merci de votre feed back
Xantia
Bonjour
Ma question comporte 2 volets : témoignage et références:
J'ai une appli développée sous Access et je voudrais la faire tourner sur
SQL serveur (que je ne connais absolument pas)
J'ai cru comprendre qu'il était possible d'utiliser les formulaires,
requetes, etats d'ACCESS
et d'etre relié aux tables SQL Seveur.
Témoignages: Quels sont les principales difficultés pour "transférer" une
appli ?
Quels sont les différents mode de fonctionnement
possibles ? (et leurs limitations)
(j'ai commencé à lire ce quelques articles sur le
site support de microsoft
mais je suis encore dans le brouillard)
Références : quels sont les ouvrages clés de référence qui abordent bien
le
problème ?
Bref : 2 question courtes qui entrainent des réponses très longues
merci de votre feed back
Xantia
Bonjour
Ma question comporte 2 volets : témoignage et références:
J'ai une appli développée sous Access et je voudrais la faire tourner sur
SQL serveur (que je ne connais absolument pas)
J'ai cru comprendre qu'il était possible d'utiliser les formulaires,
requetes, etats d'ACCESS
et d'etre relié aux tables SQL Seveur.
Témoignages: Quels sont les principales difficultés pour "transférer" une
appli ?
Quels sont les différents mode de fonctionnement
possibles ? (et leurs limitations)
(j'ai commencé à lire ce quelques articles sur le
site support de microsoft
mais je suis encore dans le brouillard)
Références : quels sont les ouvrages clés de référence qui abordent bien
le
problème ?
Bref : 2 question courtes qui entrainent des réponses très longues
merci de votre feed back
Xantia
Bonjour Alain!
Petites questions et vaste domaine de reponse, en effet. La grosse
question
de depart est de savoir comment a ete developpee l'application Access des
le
debut. Si c'est une application tout a fait classique, en fichier .mdb,
avec
des formulaires semblables aux formulaires generes par les assistants
d'Access, alors il y a la solution "rapide" (ce que fait de facon
pratiquement automatique l'assistant de migration, le "upsize wizard") qui
est de creer une structure de tables sur SQL Server qui soit identique a
celle qui se trouvait dans Access, et de lier ces tables sur la base
Access.
Le travail de migration en est reduit a quelques minutes, mais il y a le
revers de la medaille: c'est encore Jet qui est le moteur de la nouvelle
base de donnees. Le serveur SQL est traite comme un vulgaire repositoire
de
donnees, et on n'utilisera pas ses performances pour faire les requetes. I
l
y a de grandes chances pour qu'une amelioration des performance (en droit
d'etre attendue) ne se materialise pas. Le seul avantage de suivre cette
demarche est sa rapidite (surout pour quelqu'un qui ne connait pas SQL
Server), et le fait d'avoir un serveur "industriel" (qui permet de vraies
sauvegardes) ou sont stockees les donnees. Au niveau de la
confidentialite,
il est plus facile de mettre en oeuvre un systeme "blinde" sur SQL que sur
Access.
Enfin, cela permet d'avoir les donnees bien au chaud pendant qu'on refait
l'application "comme-y-faut", probablement avec des outils autres que
Access: il n'y a que le cas particulier du passage par le format de projet
.adp d'Access ou on peut peut-etre s'appuyer sur ce que fait Access pour
demarrer.
Voila, juste une opinion, formee apres quelques annees de developpment
Access/SQL Server...
--
Daniel :-)
Computing Technologies International - www.computing-tech.com - We
provide solutions...
"Xantia" wrote in message
news:Bonjour
Ma question comporte 2 volets : témoignage et références:
J'ai une appli développée sous Access et je voudrais la faire tourner
sur
SQL serveur (que je ne connais absolument pas)
J'ai cru comprendre qu'il était possible d'utiliser les formulaires,
requetes, etats d'ACCESS
et d'etre relié aux tables SQL Seveur.
Témoignages: Quels sont les principales difficultés pour "transférer"
une
appli ?
Quels sont les différents mode de fonctionnement
possibles ? (et leurs limitations)
(j'ai commencé à lire ce quelques articles sur le
site support de microsoft
mais je suis encore dans le brouillard)
Références : quels sont les ouvrages clés de référence qui abordent bien
leproblème ?
Bref : 2 question courtes qui entrainent des réponses très longues
merci de votre feed back
Xantia
Bonjour Alain!
Petites questions et vaste domaine de reponse, en effet. La grosse
question
de depart est de savoir comment a ete developpee l'application Access des
le
debut. Si c'est une application tout a fait classique, en fichier .mdb,
avec
des formulaires semblables aux formulaires generes par les assistants
d'Access, alors il y a la solution "rapide" (ce que fait de facon
pratiquement automatique l'assistant de migration, le "upsize wizard") qui
est de creer une structure de tables sur SQL Server qui soit identique a
celle qui se trouvait dans Access, et de lier ces tables sur la base
Access.
Le travail de migration en est reduit a quelques minutes, mais il y a le
revers de la medaille: c'est encore Jet qui est le moteur de la nouvelle
base de donnees. Le serveur SQL est traite comme un vulgaire repositoire
de
donnees, et on n'utilisera pas ses performances pour faire les requetes. I
l
y a de grandes chances pour qu'une amelioration des performance (en droit
d'etre attendue) ne se materialise pas. Le seul avantage de suivre cette
demarche est sa rapidite (surout pour quelqu'un qui ne connait pas SQL
Server), et le fait d'avoir un serveur "industriel" (qui permet de vraies
sauvegardes) ou sont stockees les donnees. Au niveau de la
confidentialite,
il est plus facile de mettre en oeuvre un systeme "blinde" sur SQL que sur
Access.
Enfin, cela permet d'avoir les donnees bien au chaud pendant qu'on refait
l'application "comme-y-faut", probablement avec des outils autres que
Access: il n'y a que le cas particulier du passage par le format de projet
.adp d'Access ou on peut peut-etre s'appuyer sur ce que fait Access pour
demarrer.
Voila, juste une opinion, formee apres quelques annees de developpment
Access/SQL Server...
--
Daniel :-)
Computing Technologies International - www.computing-tech.com - We
provide solutions...
"Xantia" <alain.teyssedre-NoSpam@libertysurf.fr> wrote in message
news:usQ81m77DHA.2540@TK2MSFTNGP11.phx.gbl...
Bonjour
Ma question comporte 2 volets : témoignage et références:
J'ai une appli développée sous Access et je voudrais la faire tourner
sur
SQL serveur (que je ne connais absolument pas)
J'ai cru comprendre qu'il était possible d'utiliser les formulaires,
requetes, etats d'ACCESS
et d'etre relié aux tables SQL Seveur.
Témoignages: Quels sont les principales difficultés pour "transférer"
une
appli ?
Quels sont les différents mode de fonctionnement
possibles ? (et leurs limitations)
(j'ai commencé à lire ce quelques articles sur le
site support de microsoft
mais je suis encore dans le brouillard)
Références : quels sont les ouvrages clés de référence qui abordent bien
le
problème ?
Bref : 2 question courtes qui entrainent des réponses très longues
merci de votre feed back
Xantia
Bonjour Alain!
Petites questions et vaste domaine de reponse, en effet. La grosse
question
de depart est de savoir comment a ete developpee l'application Access des
le
debut. Si c'est une application tout a fait classique, en fichier .mdb,
avec
des formulaires semblables aux formulaires generes par les assistants
d'Access, alors il y a la solution "rapide" (ce que fait de facon
pratiquement automatique l'assistant de migration, le "upsize wizard") qui
est de creer une structure de tables sur SQL Server qui soit identique a
celle qui se trouvait dans Access, et de lier ces tables sur la base
Access.
Le travail de migration en est reduit a quelques minutes, mais il y a le
revers de la medaille: c'est encore Jet qui est le moteur de la nouvelle
base de donnees. Le serveur SQL est traite comme un vulgaire repositoire
de
donnees, et on n'utilisera pas ses performances pour faire les requetes. I
l
y a de grandes chances pour qu'une amelioration des performance (en droit
d'etre attendue) ne se materialise pas. Le seul avantage de suivre cette
demarche est sa rapidite (surout pour quelqu'un qui ne connait pas SQL
Server), et le fait d'avoir un serveur "industriel" (qui permet de vraies
sauvegardes) ou sont stockees les donnees. Au niveau de la
confidentialite,
il est plus facile de mettre en oeuvre un systeme "blinde" sur SQL que sur
Access.
Enfin, cela permet d'avoir les donnees bien au chaud pendant qu'on refait
l'application "comme-y-faut", probablement avec des outils autres que
Access: il n'y a que le cas particulier du passage par le format de projet
.adp d'Access ou on peut peut-etre s'appuyer sur ce que fait Access pour
demarrer.
Voila, juste une opinion, formee apres quelques annees de developpment
Access/SQL Server...
--
Daniel :-)
Computing Technologies International - www.computing-tech.com - We
provide solutions...
"Xantia" wrote in message
news:Bonjour
Ma question comporte 2 volets : témoignage et références:
J'ai une appli développée sous Access et je voudrais la faire tourner
sur
SQL serveur (que je ne connais absolument pas)
J'ai cru comprendre qu'il était possible d'utiliser les formulaires,
requetes, etats d'ACCESS
et d'etre relié aux tables SQL Seveur.
Témoignages: Quels sont les principales difficultés pour "transférer"
une
appli ?
Quels sont les différents mode de fonctionnement
possibles ? (et leurs limitations)
(j'ai commencé à lire ce quelques articles sur le
site support de microsoft
mais je suis encore dans le brouillard)
Références : quels sont les ouvrages clés de référence qui abordent bien
leproblème ?
Bref : 2 question courtes qui entrainent des réponses très longues
merci de votre feed back
Xantia
Bonjour Daniel
Merci pour ton avis qui m'est précieux. car j'y ressent du vécu.
D'après ce que tu dis, je pense être bon pour tout redévelopper si je veux
"porter mon appli" sur SQL.
En effet, il ne s'agit pas d'une application classique, j'utilise des
formulaires
assez compliqués avec du code DAO, des accés à des appli Office, ...
J'imaginais plutot passer par le projet ADP access en me disant qu'il
existait
peut etre des "moulinettes" pour remplacer le code qui ne passait pas.
Actuellement je ne dispose pas de SQL serveur, je travaille avec Access
2000.
Est il possible de tester / developper son projet ADP sans avoir SQL
serveur
?
(version légère de SQL à télécharger, ou je développe mon projet ADP avec
Jet et
automatiquement il sera valable pour SQL2000 ?
Est ce que je peux facilement à partir de mon appli Access mdb créer un
projet ;adp
(ex: j'importe tout, ???)
Bon j'arrete la car le sujet est vaste
@+
Alain
Bonjour Daniel
Merci pour ton avis qui m'est précieux. car j'y ressent du vécu.
D'après ce que tu dis, je pense être bon pour tout redévelopper si je veux
"porter mon appli" sur SQL.
En effet, il ne s'agit pas d'une application classique, j'utilise des
formulaires
assez compliqués avec du code DAO, des accés à des appli Office, ...
J'imaginais plutot passer par le projet ADP access en me disant qu'il
existait
peut etre des "moulinettes" pour remplacer le code qui ne passait pas.
Actuellement je ne dispose pas de SQL serveur, je travaille avec Access
2000.
Est il possible de tester / developper son projet ADP sans avoir SQL
serveur
?
(version légère de SQL à télécharger, ou je développe mon projet ADP avec
Jet et
automatiquement il sera valable pour SQL2000 ?
Est ce que je peux facilement à partir de mon appli Access mdb créer un
projet ;adp
(ex: j'importe tout, ???)
Bon j'arrete la car le sujet est vaste
@+
Alain
Bonjour Daniel
Merci pour ton avis qui m'est précieux. car j'y ressent du vécu.
D'après ce que tu dis, je pense être bon pour tout redévelopper si je veux
"porter mon appli" sur SQL.
En effet, il ne s'agit pas d'une application classique, j'utilise des
formulaires
assez compliqués avec du code DAO, des accés à des appli Office, ...
J'imaginais plutot passer par le projet ADP access en me disant qu'il
existait
peut etre des "moulinettes" pour remplacer le code qui ne passait pas.
Actuellement je ne dispose pas de SQL serveur, je travaille avec Access
2000.
Est il possible de tester / developper son projet ADP sans avoir SQL
serveur
?
(version légère de SQL à télécharger, ou je développe mon projet ADP avec
Jet et
automatiquement il sera valable pour SQL2000 ?
Est ce que je peux facilement à partir de mon appli Access mdb créer un
projet ;adp
(ex: j'importe tout, ???)
Bon j'arrete la car le sujet est vaste
@+
Alain
Bonsoir Alain!
S'il y a du code DAO et une utilisation intensive de recordset, alors il
sera probablement plus sage d'envisager un redeveloppement complet, en
effet.
Il est *possible* d'importer une base mdb en projet adp. Ceci dit, j'ai
toujours trouve le resultat de cette operation tellement emmmm...betant
que
je prefere partir a zero.
Pour vous "faire la main" sur SQL, utilisez MSDE, qui offre la majorite de
la fonctionalite de SQL Server, et qui est livre avec Access. Cela vous
permettra aussi de mettre en place un projet de test en adp.
Ma philosophie de developpement est devenue: prototype en Access (format
adp, avec stockage des donnees en MSDE si besoin), et version finale en
.Net
(la plupart du temps VB.NET et ASP.NET) avec donnees en MSDE ou SQL
Server,
suivant les cas.
Bonne continuation,
--
Daniel :-)
Computing Technologies International - www.computing-tech.com - We
provide solutions...
"Xantia" wrote in message
news:Bonjour Daniel
Merci pour ton avis qui m'est précieux. car j'y ressent du vécu.
D'après ce que tu dis, je pense être bon pour tout redévelopper si je
veux
"porter mon appli" sur SQL.
En effet, il ne s'agit pas d'une application classique, j'utilise des
formulaires
assez compliqués avec du code DAO, des accés à des appli Office, ...
J'imaginais plutot passer par le projet ADP access en me disant qu'il
existait
peut etre des "moulinettes" pour remplacer le code qui ne passait pas.
Actuellement je ne dispose pas de SQL serveur, je travaille avec Access
2000.
Est il possible de tester / developper son projet ADP sans avoir SQL
serveur?
(version légère de SQL à télécharger, ou je développe mon projet ADP
avec
Jet et
automatiquement il sera valable pour SQL2000 ?
Est ce que je peux facilement à partir de mon appli Access mdb créer un
projet ;adp
(ex: j'importe tout, ???)
Bon j'arrete la car le sujet est vaste
@+
Alain
Bonsoir Alain!
S'il y a du code DAO et une utilisation intensive de recordset, alors il
sera probablement plus sage d'envisager un redeveloppement complet, en
effet.
Il est *possible* d'importer une base mdb en projet adp. Ceci dit, j'ai
toujours trouve le resultat de cette operation tellement emmmm...betant
que
je prefere partir a zero.
Pour vous "faire la main" sur SQL, utilisez MSDE, qui offre la majorite de
la fonctionalite de SQL Server, et qui est livre avec Access. Cela vous
permettra aussi de mettre en place un projet de test en adp.
Ma philosophie de developpement est devenue: prototype en Access (format
adp, avec stockage des donnees en MSDE si besoin), et version finale en
.Net
(la plupart du temps VB.NET et ASP.NET) avec donnees en MSDE ou SQL
Server,
suivant les cas.
Bonne continuation,
--
Daniel :-)
Computing Technologies International - www.computing-tech.com - We
provide solutions...
"Xantia" <alain.teyssedre-NoSpam@libertysurf.fr> wrote in message
news:uuhnkY97DHA.2472@TK2MSFTNGP10.phx.gbl...
Bonjour Daniel
Merci pour ton avis qui m'est précieux. car j'y ressent du vécu.
D'après ce que tu dis, je pense être bon pour tout redévelopper si je
veux
"porter mon appli" sur SQL.
En effet, il ne s'agit pas d'une application classique, j'utilise des
formulaires
assez compliqués avec du code DAO, des accés à des appli Office, ...
J'imaginais plutot passer par le projet ADP access en me disant qu'il
existait
peut etre des "moulinettes" pour remplacer le code qui ne passait pas.
Actuellement je ne dispose pas de SQL serveur, je travaille avec Access
2000.
Est il possible de tester / developper son projet ADP sans avoir SQL
serveur
?
(version légère de SQL à télécharger, ou je développe mon projet ADP
avec
Jet et
automatiquement il sera valable pour SQL2000 ?
Est ce que je peux facilement à partir de mon appli Access mdb créer un
projet ;adp
(ex: j'importe tout, ???)
Bon j'arrete la car le sujet est vaste
@+
Alain
Bonsoir Alain!
S'il y a du code DAO et une utilisation intensive de recordset, alors il
sera probablement plus sage d'envisager un redeveloppement complet, en
effet.
Il est *possible* d'importer une base mdb en projet adp. Ceci dit, j'ai
toujours trouve le resultat de cette operation tellement emmmm...betant
que
je prefere partir a zero.
Pour vous "faire la main" sur SQL, utilisez MSDE, qui offre la majorite de
la fonctionalite de SQL Server, et qui est livre avec Access. Cela vous
permettra aussi de mettre en place un projet de test en adp.
Ma philosophie de developpement est devenue: prototype en Access (format
adp, avec stockage des donnees en MSDE si besoin), et version finale en
.Net
(la plupart du temps VB.NET et ASP.NET) avec donnees en MSDE ou SQL
Server,
suivant les cas.
Bonne continuation,
--
Daniel :-)
Computing Technologies International - www.computing-tech.com - We
provide solutions...
"Xantia" wrote in message
news:Bonjour Daniel
Merci pour ton avis qui m'est précieux. car j'y ressent du vécu.
D'après ce que tu dis, je pense être bon pour tout redévelopper si je
veux
"porter mon appli" sur SQL.
En effet, il ne s'agit pas d'une application classique, j'utilise des
formulaires
assez compliqués avec du code DAO, des accés à des appli Office, ...
J'imaginais plutot passer par le projet ADP access en me disant qu'il
existait
peut etre des "moulinettes" pour remplacer le code qui ne passait pas.
Actuellement je ne dispose pas de SQL serveur, je travaille avec Access
2000.
Est il possible de tester / developper son projet ADP sans avoir SQL
serveur?
(version légère de SQL à télécharger, ou je développe mon projet ADP
avec
Jet et
automatiquement il sera valable pour SQL2000 ?
Est ce que je peux facilement à partir de mon appli Access mdb créer un
projet ;adp
(ex: j'importe tout, ???)
Bon j'arrete la car le sujet est vaste
@+
Alain