base access en exe

Salut,
avec les kits de dévelloppement d'Access tu peux créer des Runtime qui ne
nécessitent pas sur l'ordinateur "cible" de posséder Access.
A ma connaissance c'est le seul moyen!

--
@+ Raph.

--------------------------------------------
Merci de répondre sur le NG
Toutes remarques bienvenues !

Pour un contact direct, utiliser:
nospampizza.mpl@tiscali.fr en enlevant nospam.
--------------------------------------------



"jonathan" <supernet18@ENLEVERhotmail.com> a écrit dans le message de news:
18f401c4fff9$a01496e0$a601280a@phx.gbl...
Bonjour,

J'ai plusieurs appli access et on m'a demander de tous
transférer en .exe

Quels sont les moyens pour y arriver. Quels logiciel
utiliser?

Peut'on trnasférer le tout en C++ ou autre....

Merci

Bnsr,

Question récurrente ; déjà, dans les applis Access, il y a du VB (exactement
VBA genre VB6)
rien a voir avec le VB.NET qui lui ressemnle fort à du C++.
Donc, inutile de rever !
Au mieux, on recompilera du Basic !
Le seul outil dont j'ai entendu aprler dans le genre,
c'est un machin nommé ObjectConverter 2000 (ou qq.chose)
qui permet de reprendre les ecrans en VB6, mais il y aurait du taf....

Les etats, c'est faisable (voir une FAQ VB).
Bon courage.....

YanX

"jonathan" <supernet18@ENLEVERhotmail.com> a écrit dans le message de
news:18f401c4fff9$a01496e0$a601280a@phx.gbl...
Bonjour,

J'ai plusieurs appli access et on m'a demander de tous
transférer en .exe

Quels sont les moyens pour y arriver. Quels logiciel
utiliser?

Peut'on trnasférer le tout en C++ ou autre....

Merci

Salut,

"jonathan"

J'ai plusieurs appli access et on m'a demander de tous
transférer en .exe


Dis au demandeur qu'il demande des choses qu'il ne connait pas ;-)


Quels sont les moyens pour y arriver. Quels logiciel utiliser?
Peut'on trnasférer le tout en C++ ou autre....

Tu recommence tout le travail en VB ou autre... (bien le plaisir ;)


J'ai une question :
Faire cela en espérant quoi ???


--
A+
Pierre (3stone) Access MVP
Perso: http://users.skynet.be/accesshome/
Conseils MPFA: http://users.skynet.be/mpfa/
Email : http://www.cerbermail.com/?Xfg61Z3IQw

Je dois mettre le tous sur exe car Access est un
logiciel... donc ça prend une licence et l'employeur n'a
pas de licence pour les multiples ordi présents dans les
bureaux.

....Donc à première vue, je dois tout retapper de A à
Z!!!!!

N'y a t'il pas un moyen ou un logiciel de prog.. (FroxPro
par exemple) qui peut sous-tirer une partie d'une base
access...??? code...form...requêtes...etc?

-----Message d'origine-----
Salut,

"jonathan"

J'ai plusieurs appli access et on m'a demander de tous
transférer en .exe


Dis au demandeur qu'il demande des choses qu'il ne
connait pas ;-)

Quels sont les moyens pour y arriver. Quels logiciel
utiliser?

Peut'on trnasférer le tout en C++ ou autre....

Tu recommence tout le travail en VB ou autre... (bien
le plaisir ;)

J'ai une question :
Faire cela en espérant quoi ???


--
A+
Pierre (3stone) Access MVP
Perso: http://users.skynet.be/accesshome/
Conseils MPFA: http://users.skynet.be/mpfa/
Email : http://www.cerbermail.com/?Xfg61Z3IQw

.

Alors, la bonne solution (cout) : faire une Mise a jour
d'un Access avec un Access RuntIme developer !
librement redistribuable !
voir plus haut la reponse de RaphK34 c'est la meilleure !
http://officesystem.access.free.fr/runtime/index.htm
et si raymond passe par là (c'est l'auteur du site ci-dessus)
il connait par coeur la page de Micro$oft pour te préciser les choses...

<anonymous@discussions.microsoft.com> a écrit danse le message de
news:157401c50002$e48ede30$a401280a@phx.gbl...
Je dois mettre le tous sur exe car Access est un
logiciel... donc ça prend une licence et l'employeur n'a
pas de licence pour les multiples ordi présents dans les
bureaux.

....Donc à première vue, je dois tout retapper de A à
Z!!!!!

N'y a t'il pas un moyen ou un logiciel de prog.. (FroxPro
par exemple) qui peut sous-tirer une partie d'une base
access...??? code...form...requêtes...etc?

-----Message d'origine-----
Salut,

"jonathan"

J'ai plusieurs appli access et on m'a demander de tous
transférer en .exe


Dis au demandeur qu'il demande des choses qu'il ne
connait pas ;-)

Quels sont les moyens pour y arriver. Quels logiciel
utiliser?

Peut'on trnasférer le tout en C++ ou autre....

Tu recommence tout le travail en VB ou autre... (bien
le plaisir ;)

J'ai une question :
Faire cela en espérant quoi ???


--
A+
Pierre (3stone) Access MVP
Perso: http://users.skynet.be/accesshome/
Conseils MPFA: http://users.skynet.be/mpfa/
Email : http://www.cerbermail.com/?Xfg61Z3IQw

.

Je dois mettre le tous sur exe car Access est un
logiciel... donc ça prend une licence et l'employeur n'a
pas de licence pour les multiples ordi présents dans les
bureaux.

Des licences... mais pas tant que cela...

A moins que l'application soit un "monstre", ce que je ne pense pas,
car demander à "une" personne de transférer un montre en .exe est un travail
de titan, voir impossible !!

Il y a donc la solution de l'achat *d'une seule* licence devellopeur
et d'utiliser la version bridée (Runtime) d'Access que tu peut placer
sur autant de postes que tu le souhaite sans débourser un cents...



....Donc à première vue, je dois tout retapper de A à Z!!!!!

N'y a t'il pas un moyen ou un logiciel de prog.. (FroxPro
par exemple) qui peut sous-tirer une partie d'une base
access...??? code...form...requêtes...etc?

Si tu connait Access, tu sais que l'on peut s'adresser à la base
(au données) de facon simple par d'autres manières... DAO, ADO...
Mais, créer une interface *très* fonctionnelle aussi simplement
qu'on le fait avec Access... pas évident !
Access EST le créateur et gestionnaire des interfaces qui te permet
d'utiliser JET si un peut nombre de poste, voir MSDE.

En tout cas, ne pas utiliser Access pour raison de licence n'est pas un argument!
Je n'ose imaginer que sur chaque poste on fait du "dévellopement"...

Mais je reconnais qu'il peut exister d'autres arguments ;-)

--
A+
Pierre (3stone) Access MVP
Perso: http://users.skynet.be/accesshome/
Conseils MPFA: http://users.skynet.be/mpfa/
Email : http://www.cerbermail.com/?Xfg61Z3IQw

Salut.

Mais je reconnais qu'il peut exister d'autres arguments ;-)

jai déjà connu cette situation et c'est le seul argument pour faire barrage
à autre chose que Jonathan ne connait peut-être pas lui-même. Je n'ai jamais
vu un patron parler de .exe, il n'a même pas idée que ça existe et on lui a
soufflé le mot entre deux portes. Si c'est le responsable informatique qui
le désire c'est qu'il veut liquider tout l'existant pour le remplacer par
"son existant" . Si c'est le responsable administratif et financier qui
parle de ça, alors là, tout a déjà été décidé et tout va être remplacé par
des logiciels standards du type Sage car c'est tout ce qu'il connait et il
veut avoir la main mise sur la filière de l'achat jusqu'au développement et
surtout que l'informatique soit sous sa coupe et non un service d'électrons
libres.
Quand tu as compris ça, tu vois beaucoup plus clair et le prix d'une
extension developer est à 100 lieux des préoccupations de celui qui réclame
le .exe.
--
@+
Raymond Access MVP
http://OfficeSystem.Access.free.fr/
http://OfficeSystem.Access.free.fr/runtime/
http://users.skynet.be/mpfa/ pour débuter sur le forum


"3stone" <spam@spam> a écrit dans le message de news:
OEABsWAAFHA.3596@TK2MSFTNGP12.phx.gbl...

Salut ;O)

Transformer une application Access en EXE stand-alone est un beau rêve que
tout programmeur Access a tenté de toucher un jour...
Mais hélas la réalité nous rattrape toujours et nous barre affreusement la
route. Et je sais de quoi je parle.

Access vers VB6 ou .NET n'est pas une chose qui va de soit parceque le code
est du VBA de chez Microsoft...
Access est très différent par rapport à VB, surtout au niveau de
l'interface. Les formulaires et contrôles d'Access sont en tout point
incomparables, même si l'approche pratique reste la même.

On n'aborde pas VB de la même façon qu'Access. Il sera très facile de créer
un programme de dessin en VB alors qu'avec Access cela risque d'être une
entreprise périlleuse car celui-ci est inadapté. Pour preuve, Access ne
sait pas ce qu'est un Hdc (Handle Device Context) au niveau de ses
formulaires, information indispensable pour utiliser les API's de GDI32 pour
le graphisme. Bien entendu, l'on peut connaître le Hdc d'un formulaire
Access grâce aux API's, mais cela devient lourd et le comportement parfois
aléatoire. Cela pour dire qu'Access reste orienté base de données et que
VB, le grand frère si l'on peut dire ainsi, peut être programmé à des fins
très larges.

Seule la syntaxe VB reste similaire. Un IF reste un IF et un WHILE reste un
WHILE. A part cela pas grand chose d'autre. Un programmeur Access n'ayant
jamais mis les pieds dans VB6 aura quelques peines à refaire à l'identique
ce qu'il a fait auparavant dans Access. Il sera même très frustré !
Surtout au niverau des états (dans mon cas). Bien entendu, les contrôles VB
peuvent être étendus avec d'autres contrôles commerciaux, mais ceux-ci ont
un coût non négligeable. L'on peut ausi créer nos propres contrôles, ce qui
est fastidieux si celui-ci est complexe et créer un contrôle demande des
connaissances supplémentaires.

Aussi, Access utilise ses propres librairies que VB ne connaît pas en mode
natif. Et là où ca fait aussi très mal, les contrôles standards de VB sont
relativement rudimentaires point de vue base de données. Access et bien
plus costaud de ce point de vue là. Et les états ? N'en parlons pas... VB
intègre le DataReport qui est très simpliste comparé aux états d'Access. De
frustration en frustration...

Donc, vouloir passer de l'un à l'autre sans difficulté est un voeu pieux !
Tout refaire est la seule solution, en récupérant le code pouvant être
récupéré. Croisons les doigts pour que celui-ci n'utilise pas trop de
commandes propres à Access...

Ceci dit et comme explicité dans les autres réponses, Access est
distribuable en runtime sans royaltie. Faut-il encore avoir la version
Developpeur pour pouvoir créer un package de ce genre.
Donc, la personne qui te demande la transformation en EXE de tes
applications Access est un doux rêveur où une personne ne sachant pas de
quoi elle parle (certainemens un manager-financier). Mieux vaut investir
dans la version Developpeur que de tout redévelopper... Le temps c'est de
l'argent.

Dernière chose : une bonne application Access bien ficelée (avec quelques
API histoire d'aller plus loin) distribuée avec un runtime Access, peut
passer inaperçue auprès de l'utilisateur lambda. Je veux dire par là,
celui-ci pourrait très bien ne jamais constater que c'est le moteur Access
qui tourne en dessous de tout cela. Je parle en connaissance de cause ;O)

Bonne chance !

Guy

"jonathan" <supernet18@ENLEVERhotmail.com> a écrit dans le message de
news:18f401c4fff9$a01496e0$a601280a@phx.gbl...
Bonjour,

J'ai plusieurs appli access et on m'a demander de tous
transférer en .exe

Quels sont les moyens pour y arriver. Quels logiciel
utiliser?

Peut'on trnasférer le tout en C++ ou autre....

Merci

Voilà une réponse qu'elle est complète !!!

Et pourtant, je ne partage pas pleinement ton avis.
D'abord, le VB reste le VB.
Il utilise d'ailleurs (va jeter un oeil dans les références...) le VBA comme
bibliothèque principale ;)
D'autre part, le langage repose également sur le principe des bibliothèque.
Rien ne t'empèche d'ajouter les bibliothèques Access, DAO, ADO, etc. etc.
Maintenant, il est vrai que si tu as parfaitement compris le contexte dans
lequel tu évolues, le passage d'Access à VB ne pose AUCUN problème, en ce
qui concerne le code.
Par contre, là où je te rejoins pleinement, c'est le côté interface.
Il est vrai que les formulaire et états Access sont spécifiques au produit.
-=-=-=-=-
Dans le temps, pour ma part, j'avais essayer un produit qui s'appelait
AccessToVB je crois (c'est vieux !!!) et, je dois avouer que le résultat,
même s'il n'était 'pas mal', était loin de l'objectif que je m'étais fixé !
--
=================================================== Maxence Hubiche
Microsoft Access MVP
Responsable Rubrique Access sur http://www.developpez.com
La FAQ Access (503 Q/R) http://access.developpez.com/faq
Mon site perso : http://www.access-maxence.com
====================================================

Salut ;O)

Voilà une réponse qu'elle est complète !!!
On fait de notre mieux ;O)

Et pourtant, je ne partage pas pleinement ton avis.
Si on était tous d'accord, que le monde serait beau ;O)

D'abord, le VB reste le VB.
Hautement philosophique ;O) Access reste Access...

Il utilise d'ailleurs (va jeter un oeil dans les références...) le VBA
comme

bibliothèque principale ;)
Pour ton information, VB6 n'utilise pas du tout la même bibliothèque

qu'Access, même si le nom est identique.
VB6 : MSVBVM60.DLL (Microsoft Visual Basic Virtual Machine 6.0) qui se
trouve dans %WINDIR%SYSTEM32
Access : VBA332.DLL qui se trouve dans %Program Files%Fichiers
communsMicrosoft SharedVBA

La bibliothèque VBA se trouvant dans Microsoft Shared est partagée par
toutes les applications Office.
VB6 ne connait pas cette bibliothèque.
Il y a erreur dans ta connaissance ! Supprime cette bibliothèque, VB6 n'en
sera pas affecté.

D'autre part, le langage repose également sur le principe des bibliothèque.
Je n'ai jamais dit le contraire.

Rien ne t'empèche d'ajouter les bibliothèques Access, DAO, ADO, etc. etc.
DAO et ADO Ok ! Pas Access, cela impose la présence de celui-ci sur la

machine cible.
A n'utiliser qu'en cas de besoin d'Access et détection de sa présence au
préalable.

Maintenant, il est vrai que si tu as parfaitement compris le contexte dans
lequel tu évolues, le passage d'Access à VB ne pose AUCUN problème, en ce
qui concerne le code.
A moitié d'accord. Transposer un code VBA Access en VB n'est pas chose

simple surtout si le code VBA est accompagné de multiples DoCmd, ce qui est
le cas de toute manière. Et même si l'on connait parfaitement les 2
contextes, la mission est parfois très longue pour retranscrire en VB6 ce
qui est faisable par une seule commande en VBA. Je pense par exemple la
prorpiété Dirty d'un formulaire. Chose "chiante', si j'ose le dire, à faire
en VB6.

Retranscris-moi cela en VB (et ce n'est que 0,5 % d'un code d'une
application que j'ai développé), vois les commentaires :

If Me.NewRecord Then ' -> VB connait pas NewRecord
Me.lblDelete.ForeColor = 9868950 '-> VB connait ForeColor
Call fSetImgGrayScale(Me.imgDelete) '-> c'est une procédure donc,
éventuellement récupérable
If FlagCompo Then DoCmd.Close acForm, strSubFrm ' -> VB connait pas
DoCmd
Me.imgArrow.Visible = False '-> VB connait Visible
Else
Me.lblDelete.ForeColor = 0 '-> VB connait ForeColor
Call fGetImage("imgDelete", Me.Form, "Delete16") '-> c'est une
procédure donc, éventuellement récupérable
If Me.imgArrow.Visible = False Then Me.imgArrow.Visible = True '->
VB connait Visible
If FlagCompo And Not fIsLoaded(strSubFrm) Then '-> éventuellement
récupérable
DoCmd.OpenForm strSubFrm ' -> VB connait pas DoCmd
Call sReplaceForm '-> c'est une procédure donc, éventuellement
récupérable
ElseIf fIsLoaded(strSubFrm) Then '-> c'est une procédure donc,
éventuellement récupérable
Forms(strSubFrm).Form.RecordSource = "SELECT
tblCompositionUnique_Item.* " _
& "FROM
tblCompositionUnique_Item " _
& "WHERE
(((tblCompositionUnique_Item.combItem_Comb_Num)=" & Me!comb_Num.Value & "))"
'-> mieux vaut même pas y penser
End If
Call sShowNbrRecord '-> c'est une procédure donc, éventuellement
récupérable
End If

If Me.RecordsetClone.RecordCount <= 0 Then '-> mieux vaut même pas y
penser
Me.ScrollBars = 0 ' -> VB connait pas ScrollBars
Else
Me.ScrollBars = 2 ' -> VB connait pas ScrollBars
End If

Tu comprendras qu'un copier-coller ne pourrait suffir ;O)

Par contre, là où je te rejoins pleinement, c'est le côté interface.
Ouf ! On est au moins 2.

Il est vrai que les formulaire et états Access sont spécifiques au
produit.

Les contrôles Access ne sont pas de vrais contrôles mais un sous-classement
d'Access. Pour preuve, ils n'ont pas de handle. Ils n'ont un Handle que
quand ils ont le focus. Pas évident à les manipuler par API's dans ce cas.
J'ai déjà eu bcp de fil à retordre avec Access.

Dans le temps, pour ma part, j'avais essayer un produit qui s'appelait
AccessToVB je crois (c'est vieux !!!) et, je dois avouer que le résultat,
même s'il n'était 'pas mal', était loin de l'objectif que je m'étais fixé
!

Je ne connaissais pas. Mais le résultat ne m'étonne pas.
Ceci dit, Access reste un outil formidable aux capacités suprenantes.
Et malheureusement très mal connu de ses détracteurs.

Guy



"Maxence HUBICHE [MVP Access]" <mh.webmaster@club-internet.fr> a écrit dans
le message de news:OaXubqLAFHA.600@TK2MSFTNGP09.phx.gbl...

Voilà une réponse qu'elle est complète !!!

Et pourtant, je ne partage pas pleinement ton avis.
D'abord, le VB reste le VB.
Il utilise d'ailleurs (va jeter un oeil dans les références...) le VBA
comme

bibliothèque principale ;)
D'autre part, le langage repose également sur le principe des
bibliothèque.

Rien ne t'empèche d'ajouter les bibliothèques Access, DAO, ADO, etc. etc.
Maintenant, il est vrai que si tu as parfaitement compris le contexte dans
lequel tu évolues, le passage d'Access à VB ne pose AUCUN problème, en ce
qui concerne le code.
Par contre, là où je te rejoins pleinement, c'est le côté interface.
Il est vrai que les formulaire et états Access sont spécifiques au
produit.

-=-=-=-=-
Dans le temps, pour ma part, j'avais essayer un produit qui s'appelait
AccessToVB je crois (c'est vieux !!!) et, je dois avouer que le résultat,
même s'il n'était 'pas mal', était loin de l'objectif que je m'étais fixé
!

--
=================================================== > Maxence Hubiche
Microsoft Access MVP
Responsable Rubrique Access sur http://www.developpez.com
La FAQ Access (503 Q/R) http://access.developpez.com/faq
Mon site perso : http://www.access-maxence.com
=================================================== >