Demande d'avis avant migration

**kgb1917** · 12/09/2007, 17h45

Bonjour,

J’ai développé une base fractionnée (frontend/backend) pour un usage multi utilisateurs. Je souhaiterai la faire migrer en un projet adp pour le front end et utiliser sqlserver ou mysql pour les données mais avant de me lancer, j’aimerai vos avis sur le point suivant. J’ai lu pas mal de choses sur le sujet (utilisation de ADO au lieu de DAO, que certaines requêtes devront peut être être refaites sous sqlserver ou mysql…). J’ai également lu sur le forum (je ne sais plus où) qu’il était préférable de définir directement dans le code la source des formulaires, zones de liste déroulante, sous formulaires, états… afin d’augmenter la vitesse d’affichage des formulaires ou états. Effectivement, j’ai gagné un peu de temps et personne ne peut voir les requêtes (sécurité oblige).

Cette démarche était-elle pertinente vu que je dois passer à sqlserver ou mysql (j’hésite encore) ? D’autre part, est-il possible de coupler ade (plus d’accès au code) et sqlserver ou mysql afin de maximiser la sécurité ?

Merci par avance pour vos avis

Invité · 12/09/2007, 20h15

Bonjour

As-tu lu ce tuto ? http://argyronet.developpez.com/office/access/mdb2adp/

Starec

**kgb1917** · 13/09/2007, 11h35

Bonjour,

pour le lien du message de Starec, oui, je l'ai lu mais à moins d'avoir loupé quelque chose dans les explications, ça ne répond pas tout à fait aux questions que je me pose.

Merci d'avance en tout cas pour toutes vos remarques sur ce sujet.

**cbleas** · 13/09/2007, 17h28

Bonjour,
Passer en ADP c'est très bien mais cela demande pas mal de travail.

bonne journée.

NB: si je propose mon application à un informaticien il prend automatiquement la version SQL server

**argyronet** · 21/09/2007, 09h31

Bonjour,

Oui, dans ce tuto, j'ai écrit à peu près tout ce qu'il faut pour démarrer mais tout n'est pas traité de façon exhaustive, je pense...

Envoyé par kgb1917

... ça ne répond pas tout à fait aux questions que je me pose...

Et quelles sont-elles ces questions ?

Argy

**kgb1917** · 21/09/2007, 09h53

Bonjour,

@ argyronet :

J’ai également lu sur le forum (je ne sais plus où) qu’il était préférable de définir directement dans le code la source des formulaires, zones de liste déroulante, sous formulaires, états… afin d’augmenter la vitesse d’affichage des formulaires ou états. Effectivement, j’ai gagné un peu de temps et personne ne peut voir les requêtes (sécurité oblige).

Cette démarche était-elle pertinente vu que je dois passer à sqlserver ou mysql (j’hésite encore) ? D’autre part, est-il possible de coupler ade (plus d’accès au code) et sqlserver ou mysql afin de maximiser la sécurité ?

Je viens de relire ton tuto et je ne vois pas si ma démarche de définir directement la source des formulaires, zones de liste déroulante, sous formulaires, états… dans le code est pertinente dans le cas où je fais une migration.
D'autre part, la question de coupler ade et sqlserver ou mysql afin de maximiser la sécurité est crucial pour moi sachant que je dois me donner la possibilité de remanier certains formulaires et états selon les besoins (donc passer en mode création). Il y a peut être un autre moyen d'y parvenir en maximisant la sécurité ?

Merci d'avance

**argyronet** · 21/09/2007, 10h49

C'est expliqué dans le tuto...
En aucun cas, même sans parler de migration, tu ne dois avoir une chaîne SQL en guise de source d'un formulaire ou d'un état... En revanche, elle peut être le nom d'une table.
Pourquoi ?
Tout simplement parce que la maintenance n'en est que plus difficile.
Par ailleurs, pour la migration, tu devrais en vérifier la syntaxe pour chacun d'eux...
Exemple :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
SELECT [N° commande], [N° employé], [Date commande] _
FROM Commandes _
WHERE (((Commandes.[Date commande])=#7/4/1996#));

Cette clause est incompatible à cause des # (et aussi du nom des champs).
Avoir la source par code s'avère plus facile (selon moi) à maintenir si et seulement si ton code est propre et conventionnellement écrit.

Coté sécurité, MySQL est sécurisé, performant et gratuit.
Tu n'as pas besoin de migrer pour faire du MySQL.

Argy

**cbleas** · 21/09/2007, 10h56

Bonjour,
Avec SQL server il est normalement préférable de définir les requètes dans SQL car la requete est traitée directement avec le moteur et non ODBC.
Maintenant pour ce qui est de la sécurité il y a tout ce qu'il faut dans SQL server.
C'est pas pour autant que je ne traite pas certaine requêtes en directe car contrairement à ACCESS la requète n'est pas dans la front mais dans le moteur. Cela veut dire que si tu modifies à la volée des requêtes c'est l'ensemble des utilisateurs qui seront affectés.
Pour ce qui est de Ade et sql server cela marche parfaitement. Le problème que je rencontrontre est alors que le traitement des bugs à distance est impossible.
Une seule solution reste alors de mettre un mot de passe sur le code mais il est possible assez facilement de les casser d'après ce que j'ai pu lire.
Meme si cela n'est pas très pratique mettre le minimum de commentaire rendra inutilisable facilement ton code.
Et enfin il y a l' APP qui protège ton code et surtout ira attaquer si des entreprises utilises illicitement ton code. du moins en France.

**cbleas** · 21/09/2007, 11h02

Bonjour Argyronet,
J'ai une petite question (ce n'est pas un piège)

Tu n'as pas besoin de migrer pour faire du MySQL.

lorsqu'on utilise My SQl ou oracle en liaison ODBC comment cela ce passe au niveau des requètes. Est ce qu'ACCESS rapatrie l'ensemble des table comme cela est fait en MDB ou l'information demandée comme dans ADE?
merci

**argyronet** · 21/09/2007, 15h31

Humm disons qu'il y a moult façons de voir les choses avec MySQL
Tu peux par exemple via ODBC couplé à D.A.O. (et éventuellement,{mais recommandé} avec PHPMyAdmin en // pour l'admin) affecter à tes formulaires et tes états les requêtes souhaitées via des Recordsets. Ca marche bien...
Tout est bien évidemment dans ce cas en code.
Il n'y a plus alors ni tables, ni requêtes physiques dans la base...

Argy

**cbleas** · 21/09/2007, 16h44

merci Argy,
cela éclaire ma lanterne.
Bon WE

**kgb1917** · 13/12/2007, 11h38

Bonjour,

J'en suis toujours à me questionner sur le choix entre sql server express ou mysql. Je reviendrais probablement alimenter cette discussion à ce sujet.

Dans mes recherches et lectures, je suis tombé sur ceci. ça a l'air intéressant pour contourner ADO sous sql server (sachant que toute ma base a été faite avec DAO). Est-ce que quelqu'un a déjà utilisé ce module ?

Merci pour vos réponses

**argyronet** · 13/12/2007, 13h06

Tu peux (sans utiliser ce module) utiliser DAO avec SQL Server.
Il n'y a pas de contournement à prévoir...
Mais sincèrement, je te le déconseille vivement car tu vas à la catastrophe coté performances.
Qu'est-ce qui te gêne tant avec ADO ?
De reprendre ton code ?

Parfois, c'est une bonne chose.

Argy

**kgb1917** · 13/12/2007, 17h27

Bonsoir,

C’est pas tant de reprendre mon code qui me pose pb mais savoir comment fonctionne la (les) relations entre un projet .adp et sql server.

Par rapport à ce que j’ai pu lire sur le net, il me semblait qu’il n’y avait plus de tables dans un projet adp. Je me suis surement trompé quelque part ou je n’ai peut être pas bien lu mais j’ai fait un test à partir d’une base exemple éprouvée fournie sur le forum : la recherche multi critères de Caféine.

Tout se passe bien avec l’assistant migration (en suivant le tuto d’Argy) mais, c’est là que j’ai dû louper quelque chose, la table média est toujours dans le projet. Sans parler du code de refreshquery qui ne passe pas mais je crois que là, c’est normal.

Sur mon projet perso, j’aimerai reproduire cette base mdb en adp avec la table sur le serveur (donc au moins liée dans le projet), les requêtes exécutées sur le serveur… pour qu’il n’y ait qu’un minimum dans l’appli. Ici s’arrêtent mes connaissances. Est-ce que je dois faire appel à un driver odbc pour cela ?

Serait-il possible d’avoir un exemple de ce que pourrait être le code à mettre dans refreshquery sur par exemple :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
If Not Me.chkAuteur Then
    SQL = SQL & "And Medias!Auteur like '*" & Me.txtRechAuteur & "*' "
End If
SQLWhere = Trim(Right(SQL, Len(SQL) - InStr(SQL, "Where ") - Len("Where ") + 1))
SQL = SQL & ";"
Me.lblStats.Caption = DCount("*", "Medias", SQLWhere) & " / " & DCount("*", "Medias")

Merci pour votre aide et vos conseils

**=JBO=** · 13/12/2007, 17h27

Bonjour à tous,

Envoyé par argyronet

Tu n'as pas besoin de migrer pour faire du MySQL.

Je crois qu'il faut être encore plus clair:

Un projet ADP permet de travailler avec SQL Server exclusivement.
Avec MySQL pas de projet ADP.

Pour utiliser MySQL il faut continuer à utiliser une application MDB contenant des tables liées qui accèdent aux tables et vues MySQL via ODBC.
(d'autres techniques sont bien évidemment possibles).

Tant pis si j'ai enfoncé le clou pour rien.

Bon courage !
_

**argyronet** · 13/12/2007, 17h57

Envoyé par =JBO=

Pour utiliser MySQL il faut continuer à utiliser une application MDB contenant des tables liées qui accèdent aux tables et vues MySQL via ODBC.

Oui, c'est exact encore que lier des tables MySQL reste la version qui permet d'avoir une vue design des tables ce qui rend plus souple l'accès.

Envoyé par =JBO=

d'autres techniques sont bien évidemment possibles

Celle bien évidement de travailler qu'avec du code.

Argy

**argyronet** · 13/12/2007, 18h05

Envoyé par kgb1917

Serait-il possible d’avoir un exemple de ce que pourrait être le code à mettre dans refreshquery sur par exemple :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
If Not Me.chkAuteur Then
    SQL = SQL & "And Medias!Auteur like '*" & Me.txtRechAuteur & "*' "
End If
SQLWhere = Trim(Right(SQL, Len(SQL) - InStr(SQL, "Where ") - Len("Where ") + 1))
SQL = SQL & ";"
Me.lblStats.Caption = DCount("*", "Medias", SQLWhere) & " / " & DCount("*", "Medias")

Merci pour votre aide et vos conseils

Cet exemple n'est pas parlant.
D'où vient-il (module, class de formulaire?) ?, comment est-il appelé (Bouton, procédure auto.)
Oui, je sais, je suis tatillon mais c'est bien de le savoir.
En réalité, ce code n'est pas tip-top si je peux me permettre...
Là, comme ça, l'usage d'un objet Recordset serait ici à prévoir... et quelques variables aussi.

Argy

**kgb1917** · 13/12/2007, 20h56

Re,

J’ai pris cet exemple pour plusieurs raisons :
- dans mes recherches, je m’aperçois qu’on est nombreux à vouloir migrer. Si Argy a fait un tuto pour la faire en douceur, il y a peu d’infos sur la suite (de DAO vers ADO, les moyens pour se connecter, les procédures stockées vs requêtes directes, quelques nfos sur les différences entre les 2 syntaxes, la sécurité…). J’ai un bouquin de MS sur Access2000 au quotidien où la partie sur MSDE ne fait qu’une 20aines de pages (soit rien). Où trouver ces infos ? J'ai vu que Maxence préparait quelque chose sur le sujet. Ce sera peut être dedans...

- J’ai pris cet exemple parce que cette base est disponible sur le forum (donc tout le monde peut savoir de quoi il retourne), et que la sub refreshquery est centrale dans ma base. Et qu'il faut bien commencer quelque part aussi.

Autrement, concernant l’exemple sous access, j’ai cherché comment paramétrer un recordset. C’est dans la faq et il y a aussi un post qui en parle mais…, quelque chose doit m'échapper.
Si vous pouviez m’éclairer sur :

l'usage d'un objet Recordset serait ici à prévoir... et quelques variables aussi.

PS : je suis sous access2002 et sql server express 2005 avec sql server management studio express

Merci pour votre aide et vos conseils

**argyronet** · 14/12/2007, 00h15

Disons que l'usage des fonctions de domaine est pour moi à bannir même si elles rendent bien service.
Ici, tu va exécuter une requête qui compte tout à travers une fonction de domaine pour simplement afficher un ratio danas un label ! Dans l'absolu, c'est tout à fait correct mais dans l'idéal, c'est pas génial...

De ce que j'ai pu analyser de ton bout de code, il semble que tu récupères le RecordSource de ton formulaire pour en extraire que la partie SELECT et d'y greffer un WHERE sur le pouce en fonction d'une case à cocher. Est-ce exacte ?
Si oui, cela tendrait à dire que ton formulaire possède une chaine SQL en guise de RecordSource. Eh bien ça, c'est pas bon car c'est pas maintenable facilement, chose que j'explique dans mon tuto.

Si tu veux faire du code "propre", tu peux écrire des fonctions génériques qui exploitent DAO et qui te calculent ce que tu veux.
En procédant ainsi, tu pourras migrer en douceur.
Je n'ai pas eu l'impression de ne pas avoir donné d'exemples de passage de code DAO vers ADO, le tuto en est bien pourvu.
Je suis conscient qu'il n'a rien d'exhaustif mais de mon point de vue, il me semble que tu ne maîtrises pas les Recordsets et donc par déduction, pas DAO non plus.
De ce fait, je comprends pourquoi ADO t'effraies un peu.
En fait l'un et l'autre sont similaires. Même si je privilégie le confort d'utilisation et de souplesse de rédaction de procédure avec DAO, il n'en est pas moins inférieur à ADO sur bien des points.

Le sujet est vaste et il n'y a malheureusement pas de solution miracle.

Ma façon perseonnelle de coder est de faire ce que l'on appelle du réutilisable à gogo. Je ne me pose pas de questions lorsqu'il s'agit d'ajouter, de supprimer, de mettre à jour un champ, un jeu de champs, un enregistrement, un jeu d'enregistrements, un comptage, une existence de valeur selon ou non un cas précis etc...
Je développe toutes mes fonctions d'accès aux données dans une classe dédiée et je dispose alors à ma disposition un jeu de fonctions en permanence ce qui évite le plus souvent de concevoir des applications programmée comme un plats de spaghettis ainsi que le permet Visual Basic....
Que j'ai souligné le coté pas "tip-top" de ton exemple, j'ai surtout voulu te faire prendre conscience que si toute ton application est codée ainsi, tu vas avoir un monstrueux travail de réflexion quant à l aamigration de ton projet.

Argy

**kgb1917** · 14/12/2007, 00h40

A vue de nez, j’ai l’impression que l’info est ton métier (en tout cas pas loin), ce qui n’est pas du tout mon cas. J’ai pu faire mon appli grâce aux tutos et conseils des différents membres de dvp.com. Ce qui veut dire que maîtriser la conception en amont tel que tu l’as présenté

Je développe toutes mes fonctions d'accès aux données dans une classe dédiée et je dispose alors à ma disposition un jeu de fonctions en permanence

, ben faut avoir le temps ou les connaissance de bases nécessaires (ce qui n’était pas mon cas il y a plusieurs mois).

Je ne peux pas dire que je maîtrise DAO mais le tuto de warin est aussi franchement bien pour apprendre ce type de recordset.

Il y a bien une partie de l’appli qui est codée ainsi mais puisqu’il faut que je migre (à cause de la lenteur de ce code en l’occurrence, surtout pour les pc connectés au serveur), je me dis que ça en vaut peut être la peine (et j’aurais appris d’autres choses par la même occase).

En tous cas :

un monstrueux travail de réflexion quant à la migration de ton projet

ça, c’est certain

Pour info, le sql est en rowsource d’une zone de liste (c'est le tuto de caféine).

Merci pour tes conseils