Je vais créer une base Access et la mettre en réseau grace au runtime, mais
j'aimerais avoir certains renseignements en plus.
Tout d'abord, je n'arrive pas à savoir comment se connecte l'utilisateur à
la base Access en réseau.(si c'est runtime -> access ->utilisateur ou
utilisateur ->runtime ->access ou autres?? en fait, j'aimerais bien avoir un
petit schéma récapitulatif.)Puis, la facon dont s'enregistre ce que
l'utilisateur saisie ?(sur son ordinateurou sur la table en réseau ou peut
etre les 2)
de plus, quand 2 utilisateurs se connectent en meme temps a la base, est-ce
que ca fonctionne en meme temps ou y a-t-il un ordre de priorité?
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire
Veuillez sélectionner un problème
Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
Sweety
Dans le message news:, pikipiki écrivait :
Je vais créer une base Access et la mettre en réseau grace au runtime, mais j'aimerais avoir certains renseignements en plus.
Tout d'abord, je n'arrive pas à savoir comment se connecte l'utilisateur à la base Access en réseau.(si c'est runtime -> access ->utilisateur ou utilisateur ->runtime ->access ou autres?? en fait, j'aimerais bien avoir un petit schéma récapitulatif.)Puis, la facon dont s'enregistre ce que l'utilisateur saisie ?(sur son ordinateurou sur la table en réseau ou peut etre les 2)
de plus, quand 2 utilisateurs se connectent en meme temps a la base, est-ce que ca fonctionne en meme temps ou y a-t-il un ordre de priorité?
-- merci de me répondre piki
Bonjour La présence du Runtime Access revient au même que la présence d'Access sur le PC client. La différence est qu'il ne peut ni modifier, ni créer quoique ce soit. Simplement exécuter une application. Que la base se trouve sur un serveur ou en local ne changera rien. Concernant le nombre d'utilisateurs simultanés, ça dépend comment l'application a été développée. (verrouillage des enregistrements etc....)
--
Michel H. (Sweety) [Microsoft MVP] - Windows Shell/User Toutes les réponses à vos questions sur le Portail de Sweety : http://sweety.mvps.org/
Dans le message news:F61DF691-4219-4DE4-814D-D04FCF1E9D2F@microsoft.com,
pikipiki <pikipiki@discussions.microsoft.com> écrivait :
Je vais créer une base Access et la mettre en réseau grace au
runtime, mais j'aimerais avoir certains renseignements en plus.
Tout d'abord, je n'arrive pas à savoir comment se connecte
l'utilisateur à la base Access en réseau.(si c'est runtime -> access
->utilisateur ou utilisateur ->runtime ->access ou autres?? en fait,
j'aimerais bien avoir un petit schéma récapitulatif.)Puis, la facon
dont s'enregistre ce que l'utilisateur saisie ?(sur son ordinateurou
sur la table en réseau ou peut etre les 2)
de plus, quand 2 utilisateurs se connectent en meme temps a la base,
est-ce que ca fonctionne en meme temps ou y a-t-il un ordre de
priorité?
--
merci de me répondre
piki
Bonjour
La présence du Runtime Access revient au même que la présence d'Access sur
le PC client.
La différence est qu'il ne peut ni modifier, ni créer quoique ce soit.
Simplement exécuter une application.
Que la base se trouve sur un serveur ou en local ne changera rien.
Concernant le nombre d'utilisateurs simultanés, ça dépend comment
l'application a été développée.
(verrouillage des enregistrements etc....)
--
Michel H. (Sweety) [Microsoft MVP] - Windows Shell/User
Toutes les réponses à vos questions sur le Portail de Sweety :
http://sweety.mvps.org/
Je vais créer une base Access et la mettre en réseau grace au runtime, mais j'aimerais avoir certains renseignements en plus.
Tout d'abord, je n'arrive pas à savoir comment se connecte l'utilisateur à la base Access en réseau.(si c'est runtime -> access ->utilisateur ou utilisateur ->runtime ->access ou autres?? en fait, j'aimerais bien avoir un petit schéma récapitulatif.)Puis, la facon dont s'enregistre ce que l'utilisateur saisie ?(sur son ordinateurou sur la table en réseau ou peut etre les 2)
de plus, quand 2 utilisateurs se connectent en meme temps a la base, est-ce que ca fonctionne en meme temps ou y a-t-il un ordre de priorité?
-- merci de me répondre piki
Bonjour La présence du Runtime Access revient au même que la présence d'Access sur le PC client. La différence est qu'il ne peut ni modifier, ni créer quoique ce soit. Simplement exécuter une application. Que la base se trouve sur un serveur ou en local ne changera rien. Concernant le nombre d'utilisateurs simultanés, ça dépend comment l'application a été développée. (verrouillage des enregistrements etc....)
--
Michel H. (Sweety) [Microsoft MVP] - Windows Shell/User Toutes les réponses à vos questions sur le Portail de Sweety : http://sweety.mvps.org/
pikipiki
ne connaissant absolument rien au runtime, j'ai fait des recherches sur internet et j'ai bien compris que l'utilisateur ne pouvait modifier les codes mais c'est plutot la facon dont se connecte le runtime a la base access en réseau que je ne compren pas?
de plus comment faut-il dévellopé l'application pour quel soit accessible à plusieurs utilisateurs en meme temps?
-- merci d'avance piki
Bonjour La présence du Runtime Access revient au même que la présence d'Access sur le PC client. La différence est qu'il ne peut ni modifier, ni créer quoique ce soit. Simplement exécuter une application. Que la base se trouve sur un serveur ou en local ne changera rien. Concernant le nombre d'utilisateurs simultanés, ça dépend comment l'application a été développée. (verrouillage des enregistrements etc....)
--
Michel H. (Sweety) [Microsoft MVP] - Windows Shell/User Toutes les réponses à vos questions sur le Portail de Sweety : http://sweety.mvps.org/
ne connaissant absolument rien au runtime, j'ai fait des recherches sur
internet et j'ai bien compris que l'utilisateur ne pouvait modifier les codes
mais c'est plutot la facon dont se connecte le runtime a la base access en
réseau que je ne compren pas?
de plus comment faut-il dévellopé l'application pour quel soit accessible à
plusieurs utilisateurs en meme temps?
--
merci d'avance
piki
Bonjour
La présence du Runtime Access revient au même que la présence d'Access sur
le PC client.
La différence est qu'il ne peut ni modifier, ni créer quoique ce soit.
Simplement exécuter une application.
Que la base se trouve sur un serveur ou en local ne changera rien.
Concernant le nombre d'utilisateurs simultanés, ça dépend comment
l'application a été développée.
(verrouillage des enregistrements etc....)
--
Michel H. (Sweety) [Microsoft MVP] - Windows Shell/User
Toutes les réponses à vos questions sur le Portail de Sweety :
http://sweety.mvps.org/
ne connaissant absolument rien au runtime, j'ai fait des recherches sur internet et j'ai bien compris que l'utilisateur ne pouvait modifier les codes mais c'est plutot la facon dont se connecte le runtime a la base access en réseau que je ne compren pas?
de plus comment faut-il dévellopé l'application pour quel soit accessible à plusieurs utilisateurs en meme temps?
-- merci d'avance piki
Bonjour La présence du Runtime Access revient au même que la présence d'Access sur le PC client. La différence est qu'il ne peut ni modifier, ni créer quoique ce soit. Simplement exécuter une application. Que la base se trouve sur un serveur ou en local ne changera rien. Concernant le nombre d'utilisateurs simultanés, ça dépend comment l'application a été développée. (verrouillage des enregistrements etc....)
--
Michel H. (Sweety) [Microsoft MVP] - Windows Shell/User Toutes les réponses à vos questions sur le Portail de Sweety : http://sweety.mvps.org/
Tisane
Bonjour piki,
ne connaissant absolument rien au runtime, j'ai fait des recherches sur internet et j'ai bien compris que l'utilisateur ne pouvait modifier les codes mais c'est plutot la facon dont se connecte le runtime a la base access en réseau que je ne compren pas?
Il est difficile de faire plus clair que Sweety : 1 Runtime = 1 Access mais "bridé". Si tu sais accéder à ta base en réseau avec Access, tu sais obligatoirement le faire avec le runtime car il n'y a pas de différence. Le runtime doit être installé sur les postes qui n'ont pas Access. Si tu as Access complet, tu peux simuler le fonctionnement d'un runtime en ajoutant /r à ta ligne de commande dans le raccourci qui lance ta base.
de plus comment faut-il dévellopé l'application pour quel soit accessible à plusieurs utilisateurs en meme temps?
Pour faire simple, on va dire que, par défaut, la base est multi-utilisateurs. Donc, tu n'as pas à t'en préoccuper au moins dans un premier temps. Il ne faut simplement pas l'ouvrir en mode exclusif sur un poste, mais cela ne se fait pas par défaut non plus. Microsoft annonce 255 utilisateurs simultanés. En pratique, tout dépend de ta base et de ton réseau (voir réponse de Sweety). Une dizaine d'utilisateurs passe sans problème. J'ai quelques expériences réussies avec 30 utilisateurs sur des bases assez lourdes, mais je ne m'engagerai pas pour davantage. Access gère les priorités. Plusieurs utilisateurs peuvent donc saisir "simultanément". Il faut parfois affiner cette gestion, mais si tu débutes, ta base devrait supporter le fonctionnement par défaut, d'autant que tu parles de 2 utilisateurs.
L'idéal est de fractionner la base en 2 : - une base frontale qui contient le "code" (tout sauf les tables) et qui devrait être placée sur chaque poste - une base dorsale qui contient uniquement les tables à placer sur le serveur.
-- Tisane
Bonjour La présence du Runtime Access revient au même que la présence d'Access sur le PC client. La différence est qu'il ne peut ni modifier, ni créer quoique ce soit. Simplement exécuter une application. Que la base se trouve sur un serveur ou en local ne changera rien. Concernant le nombre d'utilisateurs simultanés, ça dépend comment l'application a été développée. (verrouillage des enregistrements etc....) --
Michel H. (Sweety) [Microsoft MVP] - Windows Shell/User Toutes les réponses à vos questions sur le Portail de Sweety : http://sweety.mvps.org/
Bonjour piki,
ne connaissant absolument rien au runtime, j'ai fait des recherches sur
internet et j'ai bien compris que l'utilisateur ne pouvait modifier les
codes
mais c'est plutot la facon dont se connecte le runtime a la base access en
réseau que je ne compren pas?
Il est difficile de faire plus clair que Sweety :
1 Runtime = 1 Access mais "bridé".
Si tu sais accéder à ta base en réseau avec Access, tu sais obligatoirement
le faire avec le runtime car il n'y a pas de différence.
Le runtime doit être installé sur les postes qui n'ont pas Access.
Si tu as Access complet, tu peux simuler le fonctionnement d'un runtime en
ajoutant /r à ta ligne de commande dans le raccourci qui lance ta base.
de plus comment faut-il dévellopé l'application pour quel soit accessible
à
plusieurs utilisateurs en meme temps?
Pour faire simple, on va dire que, par défaut, la base est
multi-utilisateurs.
Donc, tu n'as pas à t'en préoccuper au moins dans un premier temps.
Il ne faut simplement pas l'ouvrir en mode exclusif sur un poste, mais cela
ne se fait pas par défaut non plus.
Microsoft annonce 255 utilisateurs simultanés. En pratique, tout dépend de
ta base et de ton réseau (voir réponse de Sweety).
Une dizaine d'utilisateurs passe sans problème. J'ai quelques expériences
réussies avec 30 utilisateurs sur des bases assez lourdes, mais je ne
m'engagerai pas pour davantage.
Access gère les priorités. Plusieurs utilisateurs peuvent donc saisir
"simultanément". Il faut parfois affiner cette gestion, mais si tu débutes,
ta base devrait supporter le fonctionnement par défaut, d'autant que tu
parles de 2 utilisateurs.
L'idéal est de fractionner la base en 2 :
- une base frontale qui contient le "code" (tout sauf les tables) et qui
devrait être placée sur chaque poste
- une base dorsale qui contient uniquement les tables à placer sur le
serveur.
--
Tisane
Bonjour
La présence du Runtime Access revient au même que la présence d'Access
sur
le PC client.
La différence est qu'il ne peut ni modifier, ni créer quoique ce soit.
Simplement exécuter une application.
Que la base se trouve sur un serveur ou en local ne changera rien.
Concernant le nombre d'utilisateurs simultanés, ça dépend comment
l'application a été développée.
(verrouillage des enregistrements etc....)
--
Michel H. (Sweety) [Microsoft MVP] - Windows Shell/User
Toutes les réponses à vos questions sur le Portail de Sweety :
http://sweety.mvps.org/
ne connaissant absolument rien au runtime, j'ai fait des recherches sur internet et j'ai bien compris que l'utilisateur ne pouvait modifier les codes mais c'est plutot la facon dont se connecte le runtime a la base access en réseau que je ne compren pas?
Il est difficile de faire plus clair que Sweety : 1 Runtime = 1 Access mais "bridé". Si tu sais accéder à ta base en réseau avec Access, tu sais obligatoirement le faire avec le runtime car il n'y a pas de différence. Le runtime doit être installé sur les postes qui n'ont pas Access. Si tu as Access complet, tu peux simuler le fonctionnement d'un runtime en ajoutant /r à ta ligne de commande dans le raccourci qui lance ta base.
de plus comment faut-il dévellopé l'application pour quel soit accessible à plusieurs utilisateurs en meme temps?
Pour faire simple, on va dire que, par défaut, la base est multi-utilisateurs. Donc, tu n'as pas à t'en préoccuper au moins dans un premier temps. Il ne faut simplement pas l'ouvrir en mode exclusif sur un poste, mais cela ne se fait pas par défaut non plus. Microsoft annonce 255 utilisateurs simultanés. En pratique, tout dépend de ta base et de ton réseau (voir réponse de Sweety). Une dizaine d'utilisateurs passe sans problème. J'ai quelques expériences réussies avec 30 utilisateurs sur des bases assez lourdes, mais je ne m'engagerai pas pour davantage. Access gère les priorités. Plusieurs utilisateurs peuvent donc saisir "simultanément". Il faut parfois affiner cette gestion, mais si tu débutes, ta base devrait supporter le fonctionnement par défaut, d'autant que tu parles de 2 utilisateurs.
L'idéal est de fractionner la base en 2 : - une base frontale qui contient le "code" (tout sauf les tables) et qui devrait être placée sur chaque poste - une base dorsale qui contient uniquement les tables à placer sur le serveur.
-- Tisane
Bonjour La présence du Runtime Access revient au même que la présence d'Access sur le PC client. La différence est qu'il ne peut ni modifier, ni créer quoique ce soit. Simplement exécuter une application. Que la base se trouve sur un serveur ou en local ne changera rien. Concernant le nombre d'utilisateurs simultanés, ça dépend comment l'application a été développée. (verrouillage des enregistrements etc....) --
Michel H. (Sweety) [Microsoft MVP] - Windows Shell/User Toutes les réponses à vos questions sur le Portail de Sweety : http://sweety.mvps.org/
Sweety
Dans le message news:%, Tisane écrivait :
Bonjour piki,
ne connaissant absolument rien au runtime, j'ai fait des recherches sur internet et j'ai bien compris que l'utilisateur ne pouvait modifier les codes mais c'est plutot la facon dont se connecte le runtime a la base access en réseau que je ne compren pas?
Il est difficile de faire plus clair que Sweety : 1 Runtime = 1 Access mais "bridé". Si tu sais accéder à ta base en réseau avec Access, tu sais obligatoirement le faire avec le runtime car il n'y a pas de différence. Le runtime doit être installé sur les postes qui n'ont pas Access. Si tu as Access complet, tu peux simuler le fonctionnement d'un runtime en ajoutant /r à ta ligne de commande dans le raccourci qui lance ta base.
de plus comment faut-il dévellopé l'application pour quel soit accessible à plusieurs utilisateurs en meme temps?
Pour faire simple, on va dire que, par défaut, la base est multi-utilisateurs. Donc, tu n'as pas à t'en préoccuper au moins dans un premier temps. Il ne faut simplement pas l'ouvrir en mode exclusif sur un poste, mais cela ne se fait pas par défaut non plus. Microsoft annonce 255 utilisateurs simultanés. En pratique, tout dépend de ta base et de ton réseau (voir réponse de Sweety). Une dizaine d'utilisateurs passe sans problème. J'ai quelques expériences réussies avec 30 utilisateurs sur des bases assez lourdes, mais je ne m'engagerai pas pour davantage. Access gère les priorités. Plusieurs utilisateurs peuvent donc saisir "simultanément". Il faut parfois affiner cette gestion, mais si tu débutes, ta base devrait supporter le fonctionnement par défaut, d'autant que tu parles de 2 utilisateurs.
L'idéal est de fractionner la base en 2 : - une base frontale qui contient le "code" (tout sauf les tables) et qui devrait être placée sur chaque poste - une base dorsale qui contient uniquement les tables à placer sur le serveur.
-- Tisane Et je ne peux qu'encourager la "solution" de Tisane qui consiste à placer
les tables sur le serveur et l'application proprement dite sur les PC clients avec Access complet OU le runtime. Solution utilisée sans aucun problème avec un maximum de 20 utilisateurs simultanés au boulot. Au delà il risque d'y avoir des ralentissements gênants et il faudra alors penser à une solution SQL server ou équivalent.
Précision : pour utiliser le runtime d'Access de manière illimitée, il faut un licence Access Developer Edition.
--
Michel H. (Sweety) [Microsoft MVP] - Windows Shell/User Toutes les réponses à vos questions sur le Portail de Sweety : http://sweety.mvps.org/
Dans le message news:%23rMOEzTiGHA.3780@TK2MSFTNGP03.phx.gbl,
Tisane <b.tisane@laposte.net> écrivait :
Bonjour piki,
ne connaissant absolument rien au runtime, j'ai fait des recherches
sur internet et j'ai bien compris que l'utilisateur ne pouvait
modifier les codes
mais c'est plutot la facon dont se connecte le runtime a la base
access en réseau que je ne compren pas?
Il est difficile de faire plus clair que Sweety :
1 Runtime = 1 Access mais "bridé".
Si tu sais accéder à ta base en réseau avec Access, tu sais
obligatoirement le faire avec le runtime car il n'y a pas de
différence.
Le runtime doit être installé sur les postes qui n'ont pas Access.
Si tu as Access complet, tu peux simuler le fonctionnement d'un
runtime en ajoutant /r à ta ligne de commande dans le raccourci qui
lance ta base.
de plus comment faut-il dévellopé l'application pour quel soit
accessible à
plusieurs utilisateurs en meme temps?
Pour faire simple, on va dire que, par défaut, la base est
multi-utilisateurs.
Donc, tu n'as pas à t'en préoccuper au moins dans un premier temps.
Il ne faut simplement pas l'ouvrir en mode exclusif sur un poste,
mais cela ne se fait pas par défaut non plus.
Microsoft annonce 255 utilisateurs simultanés. En pratique, tout
dépend de ta base et de ton réseau (voir réponse de Sweety).
Une dizaine d'utilisateurs passe sans problème. J'ai quelques
expériences réussies avec 30 utilisateurs sur des bases assez
lourdes, mais je ne m'engagerai pas pour davantage.
Access gère les priorités. Plusieurs utilisateurs peuvent donc saisir
"simultanément". Il faut parfois affiner cette gestion, mais si tu
débutes, ta base devrait supporter le fonctionnement par défaut,
d'autant que tu parles de 2 utilisateurs.
L'idéal est de fractionner la base en 2 :
- une base frontale qui contient le "code" (tout sauf les tables) et
qui devrait être placée sur chaque poste
- une base dorsale qui contient uniquement les tables à placer sur le
serveur.
--
Tisane
Et je ne peux qu'encourager la "solution" de Tisane qui consiste à placer
les tables sur le serveur et l'application proprement dite sur les PC
clients avec Access complet OU le runtime.
Solution utilisée sans aucun problème avec un maximum de 20 utilisateurs
simultanés au boulot.
Au delà il risque d'y avoir des ralentissements gênants et il faudra alors
penser à une solution SQL server ou équivalent.
Précision : pour utiliser le runtime d'Access de manière illimitée, il faut
un licence Access Developer Edition.
--
Michel H. (Sweety) [Microsoft MVP] - Windows Shell/User
Toutes les réponses à vos questions sur le Portail de Sweety :
http://sweety.mvps.org/
ne connaissant absolument rien au runtime, j'ai fait des recherches sur internet et j'ai bien compris que l'utilisateur ne pouvait modifier les codes mais c'est plutot la facon dont se connecte le runtime a la base access en réseau que je ne compren pas?
Il est difficile de faire plus clair que Sweety : 1 Runtime = 1 Access mais "bridé". Si tu sais accéder à ta base en réseau avec Access, tu sais obligatoirement le faire avec le runtime car il n'y a pas de différence. Le runtime doit être installé sur les postes qui n'ont pas Access. Si tu as Access complet, tu peux simuler le fonctionnement d'un runtime en ajoutant /r à ta ligne de commande dans le raccourci qui lance ta base.
de plus comment faut-il dévellopé l'application pour quel soit accessible à plusieurs utilisateurs en meme temps?
Pour faire simple, on va dire que, par défaut, la base est multi-utilisateurs. Donc, tu n'as pas à t'en préoccuper au moins dans un premier temps. Il ne faut simplement pas l'ouvrir en mode exclusif sur un poste, mais cela ne se fait pas par défaut non plus. Microsoft annonce 255 utilisateurs simultanés. En pratique, tout dépend de ta base et de ton réseau (voir réponse de Sweety). Une dizaine d'utilisateurs passe sans problème. J'ai quelques expériences réussies avec 30 utilisateurs sur des bases assez lourdes, mais je ne m'engagerai pas pour davantage. Access gère les priorités. Plusieurs utilisateurs peuvent donc saisir "simultanément". Il faut parfois affiner cette gestion, mais si tu débutes, ta base devrait supporter le fonctionnement par défaut, d'autant que tu parles de 2 utilisateurs.
L'idéal est de fractionner la base en 2 : - une base frontale qui contient le "code" (tout sauf les tables) et qui devrait être placée sur chaque poste - une base dorsale qui contient uniquement les tables à placer sur le serveur.
-- Tisane Et je ne peux qu'encourager la "solution" de Tisane qui consiste à placer
les tables sur le serveur et l'application proprement dite sur les PC clients avec Access complet OU le runtime. Solution utilisée sans aucun problème avec un maximum de 20 utilisateurs simultanés au boulot. Au delà il risque d'y avoir des ralentissements gênants et il faudra alors penser à une solution SQL server ou équivalent.
Précision : pour utiliser le runtime d'Access de manière illimitée, il faut un licence Access Developer Edition.
--
Michel H. (Sweety) [Microsoft MVP] - Windows Shell/User Toutes les réponses à vos questions sur le Portail de Sweety : http://sweety.mvps.org/
